Tag: AzureAD

Azure AD – Keep it clean and tidy

There are several reasons for keeping your Azure AD nice and tidy. Locking down features, removing unused objects and applications and so on – all this keep the the attack surface of your environment lower and makes it easier for you to manage your Azure AD, do access reviews on access groups, roles and so on. So for making it a bit more easy for you I will list out 5 tips for getting a more tidy and clean Azure AD.

First tips – M365 Groups

Lock down who can make “Microsoft 365 Groups”. By doing this you block users from creating houndreds of testing group and often (almost never) they don`t delete groups again.

This need`s to be done within Powershell, but in short notes we create a security group in Azure AD that contains the super users who is allowed to create M365 groups. Then we run a short PowerShell script for locking it down

See learn.microsoft.com for full guide/documentation for this process

Connect-AzureAD

$GroupName = "<GroupName>"
$AllowGroupCreation = $False

Connect-AzureAD

$settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value "Group.Unified" -EQ).id
if(!$settingsObjectID)
{
    $template = Get-AzureADDirectorySettingTemplate | Where-object {$_.displayname -eq "group.unified"}
    $settingsCopy = $template.CreateDirectorySetting()
    New-AzureADDirectorySetting -DirectorySetting $settingsCopy
    $settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value "Group.Unified" -EQ).id
}

$settingsCopy = Get-AzureADDirectorySetting -Id $settingsObjectID
$settingsCopy["EnableGroupCreation"] = $AllowGroupCreation

if($GroupName)
{
  $settingsCopy["GroupCreationAllowedGroupId"] = (Get-AzureADGroup -SearchString $GroupName).objectid
} else {
$settingsCopy["GroupCreationAllowedGroupId"] = $GroupName
}
Set-AzureADDirectorySetting -Id $settingsObjectID -DirectorySetting $settingsCopy

(Get-AzureADDirectorySetting -Id $settingsObjectID).Values

Second tips – Naming convention M365

Since we already have locked down creation of groups we can aim to do the naming convention in two ways. We can create a provisioning solution where users can order their groups and from there we are setting names, members and having approval process for ordering.

We can also create namin convention rules in Azure AD where we can set a prefix and or suffix. This can be set by a attribute from the user object creating the group or by a fixed string.

Within this feature there is also a “Blocked words” list. This is a list that you can upload with blocked words so that users cannot creat or use words that you put on that list. A maximum of 5000 words can be added to this list.

Learn more about naming conventions here at learn.microsoft.com

All settings are foud under “Azure AD – > Groups -> Settings”

Third tips – User attributes

Maybe not a tidy up and clean Azure AD tips – but I like to have good data quality in Azure AD so that many attributes can be used when creating dynamic groups, homemade scripts and so on. This tips is closely attached to the next tip for User provisioning. So please add as much information as possible on all user objects.

All of these attriutes must also match the organization in that manner so that we are not ending up with 1000 different departments that actually are the same.

Fourth tips – User provisioning

To make it easier for the entire organization and specially the IT department who are creating users, then the need of a easy user provisioning system is always there! Based on a provisioning system we can add more attributes without having users to type all of it.

An super easy user provisioning can just be a SharePoint Lists list in a company wide Teams Team called onboarding. Power Automate that creates a user disabled and based on “Employee Hire Date” we can user “Lifecycle workflows” within Identity Governance to do tasks a few days before users are starting in the company. In the pictures below we see how we can add input for user creation, and a Power Automate that created the user in Azure AD with all attributes added (and keeps it disabled). The last part is where the Lifecycle workflow`s runs and enable the user, add license and sends out a Temporarly Access Pass so that users can sign-in and setup the security for their account.

SharePoint list for onboarding
Power Automate for creating a user and keeping it disabled in Azure AD
Pre-hire tasks runned on user prior to hire date based on the SharePoint list input

Fifth tips – Enterprise applications

This tips is to keep good governance and security posture for applications that are connected to Azure AD. This is applications that connects to Azure AD to exstract information about signed in users and also can claim access for services that the end-user have access to – this can be mailbox for the user, Onedrive for business or sharepoint sites.

Malicious applications can therefore gain access to information and documents that they should not have access to when the end-user them self can approve the application access.

So we start with blocking for User concent for everyone.
head into “Azure AD -> Enterprise Applications -> Consent and permissions” and set both settings to “Do not allow user Consent” / “Do not allow group owner consent”

After we have done this we need to be sure that a administrator is getting notifications when users are trying to get consent for a application.
This can we do here – “Azure AD -> Enterprise Applications -> User settings” and set the settings like this.

The official documentation is at learn.microsoft.com

Monitor sensitive accounts

Pre-requisites

A pre-requisites for monitoring sensitive accounts in Azure AD is to have setup a Log Analytics Workspace and your Azure AD logs sent to Log Analytics. If you want to know how that`s done then have a look at this blog post to se how easy it is to enable in your tenant “Monitor Azure AD”

Query

So to be able to monitor sensitive accounts we first need to locate/determine what accounts that you want to monitor. I always recommend to monitor the Break-the-glass administrator account so that you or your team is alerted whenever the account is used.

So in the Log Analytics query below here you see that we are searching the “SigninLogs” for a specific UserPrincipalName and we are only looking at ResultType 0. (ResultType 0 is equal for Success).

SigninLogs 
| where UserPrincipalName == "julian.rasmussen@idefix365.no"
| where ResultType == "0"

So with that in mind let`s create a Alert Rule from this query so that we are notified every time “julian.rasmussen@idefix365.no” doing a successful signin.

Log Analytics Workspace with query for a specific username and success login

So when clicking the “New Alert Rule” button we are headed into a new page with several settings. here I have changed only two tings;
Operator: Greater than or equal to
Threshold value: 1

Click Next to go to “Actions”

Action Group

An action group is how and who is getting notified when the alert is fired.
So we create a new action group for this scenario and setup a email warning to an administrator.

You can choose to also send a payload to a Azure Function, Webhook and more within the Action pane of the Action group – in this scenario we are only using the notification part so let`s skip to the “review and create” part and create the Action Group

Alert

We then give the alert a “Alert rule name” and a description. This is what`s in the email notification sent to the user or users in the Action group

Jump over to “Review + create” and create the Alert rule.

Conclusion and result

  • We have gained monitoring and notification by doing a Query in Log Analytics.
  • From the Logs pane we can easily create a new Alert rule
  • We created a Action Group where we spesified who and how to get notified

And the result looks like this when there is a sign-in from that account and the Alert rule is fired!

Monitor Azure AD

Main goal

Main goal for this blogpost is to gain more knowledge on how to collect logs from Azure AD. By default you`ll get 30 days audit and sign-in logs stored within Azure AD. To be able to interact / automate on the logs we need to move the logs to a Log Analytics Workspace. So by doing so we gain these and much more features on our log data:

  • Ability to automate actions based on logs
  • Increase retention time on logs
  • Connect Microsoft Sentinel

Speaking of retention time you can choose from 30, 31, 60, 90, 120, 180, 270, 365, 550, and 730 days within the Azure Portal on the Log Analytics Workspace.

Log Analytics

First of all you need to create a Log Analytics Workspace and to do that you need to have a Azure Subscription in place (and you need Contributor access to it).
– Create a “Resource Group”
– Create a “Log Analytics Workspace

Here i have created a Resource group and added a Log Analytics Workspace to that group named “idefix-sentinel-log-analytics”

Azure AD configuration

When the LAW (Log Analytics Workspace) is ready then you can configure Azure AD to send log`s directly to it.
Head into Azure AD and navigate to “Audit Logs” or “Sign-in logs” and from there click the “Export Data Settings”

Azure AD -> Audit Logs -> Export Data Settings

Here you click on “Add Diagnostics Settings” and give it a name, point it to the log analytics you created and choose what to store into that LAW.

Choose all categories you want to store

After you save it you should wait about 15-20 minutes before trying to query the logs, just to be sure that new log`s have been streaming into LAW.

Test query in Log Analytics

To query your data you need to navigate to your Log Analytics Workspace and head into the “Logs” pane and from there you can add a Query to search the log`s with.

Log Analytics Workspace -> Logs

This query gets all login entries for users whose name contains Julian

SigninLogs
| where Identity contains "Julian"

To be more specific, use UserPrincipalName:

SigninLogs
| where UserPrincipalName == "julian.rasmussen@idefix365.no"

All sign-ins for Julian in the last 30 days

SigninLogs
| where UserPrincipalName == "julian.rasmussen@idefix365.no"
| where TimeGenerated > ago(30d)

New MFA capabilities in Azure AD

So these day`s we all uses MFA right? But not all MFA methods are as good as we think.

There have been several cases where “SIM Swapping” or “SIM Hijacking” has been the case and therefor – can we trust using SMS for Multi-Factor Authentication?

In short notes this is how SIM Swapping is done.

  1. You loose personal information.
  2. Your information is used to gain trust at the mobile carrier to convice them to switch from current to new SIM card (the new SIM is already in the hands of the bad guy)
  3. With controll of mobile number the bad guy log`s onto your services with one-time password or completing MFA challenge.
  4. Your account is compromised

With that said, you should disable SMS as an authentication method.
See my other blog post on how that`s done!

Since you now uses Microsoft Authenticator as your primary MFA factor you get a push notification with “Allow” or “Block” access whenever the authentication is done.
At this point the bad guy start using a method called “MFA Fatigue attacks” and blasts lot`s of authentications against you, and somethimes a user clicks on “Allow” and thinks; “It`s most likely my phone or tablet or something…”.

But with the new capabilities from Microsoft within using Azure MFA you can now add “Number matching” and “additional context” to the signin (both features are in preview at the momemt (04.05.2022).

OK – so here`s how it looks!

So you see that when ever the authentication is done a number is shown and it needs to be matched on your Microsoft Authenticatior application. In addition we also see a map and location of where the authentication is getting from!

Here`s how you can configure it!

  1. Head over to portal.azure.com
  2. Navigate to Azure AD -> Security -> Authentication methods and click on “Microsoft Authenticator”
  3. Hit “Add users and Groups” and add a group or user to test with and click “Select”
  4. Then open the settings of the group and “Require number matching” and “Show additional context in notifications”

There you have it!
Next time you authenticate with a user that`s configured to this setting you will get a number matching 🙂

List all users and their manager

Sometime we need to gain a list of all users and their managers so the managers can get a review of “their” staff!

An easy oneliner within PowerShell using AzureAD ps module is this one. this takes the first 4000 users and export them to CSV


Get-AzureADUser -Top 4000 | select UserPrincipalName,@{n="Manager";e={(Get-AzureADUser -ObjectId (Get-AzureADUserManager -ObjectId $_.ObjectId).ObjectId).UserPrincipalName}} | Export-Csv C:\Temp\YOURUSERS_usr_with_manager.csv -Encoding UTF8

Enterprise application – Admin consent workflow

The new built-in admin consent workflow within AzureAD Enterprise Application is amazing!

This feature will give you the control that you need to take care of your companies sensitive information like user id`s, files, email accounts etc.

Did you know that malicious applications is often a start of a sophisticated phising attack?

If a malicious application get`s the right permissions it could be a bad situation for your company!

Just have a look at this random application and what that app can retreive, other also gives a complete user list of all the employees back to the app developers.

In this case ALL files that this user has access to does this app now have access to read – meaning that`s there is no secrets anymore.. 

So to be able to block and and have controll over the applications that get`s granted to your AzureAD tenant you should use the new “Admin Consent Workflow” within AzureAD. This feature is in preview at the moment but I highly recomend using it.

It takes two minute to configure and after it`s configured the users see`s this when trying to connect a thirdparty application to your tenant

Admin consent user request and justification

After this request is sent – the admin that is configured within the workflow get`s an approval email and can easlly approve consents 🙂

The configuration looks like this:

Please have a look at the official documentation and enable it for your deployment!

https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/configure-admin-consent-workflow#enable-the-admin-consent-workflow

S for Security in EMS – Advanced Threat Analytics

So in this fourth blog post in my series S for Security in EMS we will og deeper in Advanced Threat Analytics included within EMS.

So what is Advanced Threat Analytics?

Well, it`s an on-premises platform that helps protect your enterprise from multiple types of advanced targeted cyber attacks and insider threats.

Why is this a important toolset to have on your hybrid environment?

Well, since you have an hybrid environment you are lacking a system to detect abnormal behavour like password sharing, lateral movements and so on and Malicious attacks like Pass-the-Ticket, Pass-the-Hash and several other attack vectors.

Advanced threat analytics uses machine learning and user usage analytics discover abnorman activities and suspicious activities.

Within Advanced Threat Analytics we can also get insights on Security Issues and risk within our on-premises environment like broke trust between machines and domain controlelrs, weak protocols used by our users and systems and much more!

All these actions and insights can be viewed from the Advanced Threat Analytics Dashboard

This is just a smal insight on what ATA can do for you!

S for Security in EMS – Overview
Part 1 – S for Security in EMS – Azure AD Premium
Part 2 – S for Security in EMS – Information Protection
Part 3 – S for Security in EMS – Microsoft Intune
Part 4 – S for Security in EMS – Advanced Threat Analytics
Part 5 – S for Security in EMS – Cloud App Security

S for Security in EMS – AAD Premium

Let`s start off with the EMS E3 package and that will give you access and user rights to use Azure AD Premium P1 features.

So do you need it?

Well, Azure AD Premium P1 gives you capabilities for your hybrid users to access both on-prem and cloud resources. The synchronization also provides write-back capabilities so self-service password reset for on-prem users can be achieved. Along with advanced features as Dynamic groups, self-service group management and “Microsoft Identity Manager” (on-prem identity and access management).

And one more important feature which is one of the most powerfull regarding securing your cloud services is “Conditional Access”. Yes we have “Security Defaults” witch is a free service but if you need to do some exclutions you need to upgrade to Azure AD Premium P1 to gain “Conditional Access” features.

Over to EMS E5 – that gives you several additions to the P1 license with all the Azure AD P2 features.

Those features are at the time “Azure Identity Protection” and “Priviledged Identity Management”

When going to P2 i will say that PIM is the feature you want to configure right the way as this gives you access management in a whole new level. Users who have been givven additional roles within your AzureAD does not have the role active at all time lowering the attack vector for users. When users need to use their priviledge roles they have to activate it and by adding a second factor to the activation your priviledge roles are more secure! Hey, you can also add approvers to roles so that a second person need to approve the request.

Many options on this part as you see!

As this blogg post is in a series of several posts please stay tuned for the next service within EMS and this blog post series “S for security in EMS”

S for Security in EMS – Overview
Part 1 – S for Security in EMS – Azure AD Premium
Part 2 – S for Security in EMS – Information Protection
Part 3 – S for Security in EMS – Microsoft Intune
Part 4 – S for Security in EMS – Advanced Threat Analytics
Part 5 – S for Security in EMS – Cloud App Security

Security Defaults – a lifesaver for some and a little pain for others

So lets talk about “Security Defaults” a bit, this new feature in AzureAD who replaces “Baseline policies: ” in the Conditional Access pane within Security in AzureAD.

First of all – the baseline policies where in preview and could be changed before the feature went GA so we cant blame anyone of the service changing before production.

The Baseline policies gave us remediaton of MFA and and blocking of legacy authentication within 4 policies that everyone could use within Conditional Access, these four policies where free so no cost and that sweet!

  • Baseline Policy: Require MFA for admins (Preview)
    • Enabled MFA to all administrator roles within AzureAD
  • Baseline Policy: End user protection (Preview)
    • Enabled MFA registration to all users and required MFA for users with leaked password or other risky signins.
  • Baseline Policy: Require MFA for Service Management (Preview)
    • Require MFA for accessing the Azure Portal, Azure PowerShell modules or Azure CLI
  • Baseline Policy: Block legacy authentication (Preview)
    • Blocked the usage of legacy authentication on all services (such as pop, IMAP, native android clients etc.

For a good time now we cound enabled one or more of those 4 baseline rules – but that ends! At February 29th 2020 Microsoft will discontinue the use of Baseline policies so if you are using some of them you need to enable Security Defaults in AzureAD.

Head into portal.azure.com -> Properties -> Security Defaults and enable it.

Please not that if you have license for using Conditional Access (Azure AD Premium P1) you cannot a Conditional Accessrule without disabling Security Defaults.

And if you have Azure AD Premium P1 you should be creating the Conditional Access rules manually and that gived you several advantages such as exclude users, pinpoint to some cloud apps or exclude them and set other requiremets aswel.

Best practice says that you should always have a “Break the glass administrator” account who is excluded from all the Requirements – but please note! That account need to be monitored and high security alerts should be raised every time the account is used.

Azure AD Connect sync issues

Now and then we get errors in our Azure AD Connect syncronization, or that said – my customers get errors.

And every now and then there is a error wich are not easy to spot what can be wrong.

In this case the sollution was not that easy – but when you think of it, it makes kind of sense sort of.

So this is the Error i got.

Other Error 
onmicrosoft.com 
Description 
Error Details 
pro perty 
Error Type 
Last Attem pted At 
Related Articles: 
Attribute 
o 
x 
The object failed synchronization. For more information, please see the error details. If the problem continues and 
cannot be fixed, please contact Microsoft Support. 
Value 
WorkflowException 
12/17/2019, PM 
1. Azure AD Connect: Troubleshooting Synchronization Errors 
user Principal Name 
Object GUID 
Synchronization Status 
Details 
Attribute Value 
0625<71 
On premises AD only 
52fde7d7eab1

Looking into Azure AD Connect it throwed a error on syncronization.

After some investigation back and forth i with the GUID who did not match the Azure AD Sync error – i found out that a deleted group was configured as a licensing group within Azure AD. Therefor when it was deleted from On-prem AD it could not be deleted in Azure AD since it still was in use.

By removing it from the license sku it removed it self on next sync.