Category Archives: Entra ID

Locking down Azure Active Directory

Posted on by
Reply

Azure Active Directory has excellent security with conditional access being one of the most widely used tool to protect Azure Active Active Directory.

The sceen shot below shows the default settings for an Azure AD Premium Plan 2 tenant.

The information tab on the user consent to apps accessing company data on their behalf reads like this:

If this option is set to yes, then users may consent to allow applications which are not published by Microsoft to access your organization’s data, if the user also has access to the data. This also means that the users will see these apps on their Access Panels.
If this option is set to no, then admins must consent to these applications before users may use them.

So in the scenario where a phishing email slipped through the cracks and an end user grants access to a non Microsoft application to their organizations’s data. We do not want that to happen!!!!

The correct setting is listed below
Application administrators should be granted the application administrator role in Azure Active Directory , Then the next time an and user wants to add an application, the application administrator will receive an email and can approve from his\her Outlook client.

The next time an end user or IT staff member wants to add an application to Azure AD, Do not just simply grant the global administrator role.

User Azure Privileged Identity Management and Application Administrator Roles!

Quest Migration Manager for AD – UPN change mid project

Posted on by
Reply

I recently encountered a unique scenario when using Quest Migration Manager for Active Directory. I was in the process of migrating 3 AD Forests into a new AD Forest. I had already migrated 1200 users into the new AD Forest and at the time of migration the UPN’s were contoso.com.

My customer then decided to change all UPN’s and primary smtp domains to @fabrikam.com in the middle of the project. This caused a big problem when computer accounts were being migrated. After the computer account had completed migration to the new domain, the user’s UPN was @contoso.com. Which meant the user had to change their UPN to login instead of just simply entering their existing AD password that they were previously using.

So how do we resolve this issue.Right click on the properties of the domain pair as per image below
Next change target domain to contoso.com or a fqdn of a domain controller in contoso.com

Next modify the security settings and set the domain suffix to fabrikam.com
Finally stop and start the synchronization task.

Once this has been completed, when computer accounts are migrated the correct UPN will be populated and users simply need to enter their existing AD password.

Azure AD Connect 1.4.38.0 authentication error

Posted on by
Reply

I started to notice that Azure AD connect was failing and had a look in the console and seen the error message in the console displayed in the image below

Then when I tried to run the command Start-ADSyncSyncCycle -PolicyType delta ,  I received a long list of authentication errors.

To resolved the issue browse into properties of the Azure Active Directory account and copy the account name onto the clipboard.

Next add this account in as an excluded account from conditional access policies the same way a break glass cloud identity admin account would be excluded from conditional access policies.

As soon as the sync account has been added to the exclusions , syncs will resume

AD Connect – Sync-rule-error-function-triggered

Posted on by
Reply

I recently worked on a project that had the following scope.

  • Migrate 6 Office365 tenants into a new single Office365 tenant
  • Migrate all users, sidhistory and computer accounts into a new AD Forest using Quest Migration Manager for Active Directory from 10 source Active Directory Forests to a new Windows Server 2019 Active Directory Forest.

14 user objects could not sync changes like adding aliases. If I extract the affected user’s immutable from the source office365 tenant it was different to the corresponding users immutableid in the new tenant.

So where is the problem? Why wont the changes sync?

When further analyzing the errors in AD Connect, I could see that the cloudanchor attribute in my new tenant had the same immutable ID as the source tenant.

So how do we fix this?

  1. Exclude the following two attributes from Quest Migration Manager for Active Directory migrations and synchronization tasks ‘mS-DS-ConsistencyGuid’ & ‘msDS-ExternalDirectoryObjectId’
  2. Then run this powershell command to export all destination  site immutable IDs

    get-aduser -filter * -SearchBase “OU=Contoso” | select samaccountname,mail,userprincipalname,objectguid,@{label=”ImmutableID”;expression={[System.Convert]::ToBase64String($_.objectguid.ToByteArray())}} | export-csv CSV LOCATION

  3. Then run the following command and replace the immutable id from the exported csv in step3 in the bold text below to convert the immuttableid to HEX format
    [system.convert]::FromBase64String(“rk4ZgeI/l0OpdRr5PiwU1g==“) | %{$a += [System.String]::Format(“{0:X}”, $_) + ” “};$result = $null;$result = $a.trimend();$result
  4. The output of this command will convert the immutable ID from the CSV to a Hex value like AE 4E 19 81 E2 3F 97 43 A9 75 1A F9 3E 2C 14 D6
  5. Next step is to populate the ‘mS-DS-ConsistencyGuid’ attribute with the hex value from step 4 and replicate domain controllers.
  6. Run a delta or initial sync on AD Connect and the issue will be resolved.

Reference Article: https://docs.microsoft.com/en-us/archive/blogs/latam/using-the-consistencyguid

 

Conditional Access and Azure Active Directory License Management

Posted on by
Reply

Azure AD group based license assignment was made generally available in Feb 2018. It really is a superb way of managing and assigning licenses for services like Office365.

Quite often on projects that I deliver ,  I will work with my customer to build a profile which could be for example standard user, power user , exec user and these groups can assign some or all of the M365 suite of services.

So this means we would have 3 security groups to match each user profile and each organisation can modify their new starter process to add new users into their relevant security group or use Identity Management tools like Microsoft Identity Manager 2016 SP1 to manage the user life cycle.

One of the quickest and most powerful conditional access policy is as follows

  • Assignment : All users , except license groups and break glass admin account
  • Cloud Apps :  All Apps
  • Conditions : Default , NO CHANGE
  • Access Controls \ Grant : BLOCK

So the assignment to all users is the key , If a new user is not setup properly and follows the new user creation process then they cannot access the organisation’s cloud apps that are integrated with Azure AD.

This is a policy to block all unlicensed users.

All licensed users would expect to have the following items configured as a minimum requirement.

  • MFA
  • SSPR
  • Combined SSPR & MFA registration
  • Azure Password Protection Service
  • Microsoft Advanced Threat Protection integration with CASB
  • Azure AD P2 license , Identity Protection policies enabled
  • Azure AD Hybrid joined machines
  • Intune managed bitlocker encrypted devices
  • Intune managed devices with security baselines