How to secure your AzureAD in easy steps

Hi! I will participate in the Spanish track of the GlobalAzure event, I will talk about security, AzureAD and best practices. If you want to knowmore, check out the agenda: https://globalazure.es/#schedule

Advertisement

Duplicated users in AzureAD

Sometimes it happens, users syncronized from OnPrem to AzureAD, are not being soft matched, and it’s necessary to do a hard match, in this post I will explain the basic steps to do it:

1. Disable the sync for that particular object, my recommendation would be to create a OU in your AD which is not being selected to be synchronized
2. Execute a Sync Delta in your ADConnect Start-ADSyncSyncCycle -PolicyType Delta
3. Check that the bogus user has been deleted, and delete it from Recycle bin withRemove-MsolUser -UserPrincipalName <user> -RemoveFromRecycleBin
4. Find the users ObjectIDldifde -d "CN=username,CN=Users,DC=domain,DC=local" -f C:\user.txt
5. Find objectGUID:: in c:\user.txt
6. If you don’t like the previous step, you can search for the sourceanchor in the metaverse of AADConnect,
7. Update AzureID, setting the object ID to sync with toSet-MsolUser -UserPrincipalName <upn> -ImmutableId <objectGUID>
8. Now, sync withStart-ADSyncSyncCycle -PolicyType Initial

With this, what we are doing id a hard match for the user, once is done, you’re ready to go

gMSA Accounts

A standalone Managed Service Account (gMSA) is a managed domain account that provides automatic password management, simplified service principal name (SPN) management and the ability to delegate the management to other administrator, can be used for services running on multiple servers such as a server farm. ADFS, IIS and systems behind a Network Load Balance.

As I stated at the beginning, the main benefit from an identity perspective is that there is no password to manage for this account. The gMSA is configured on the servers and Windows handles the password management of the account.

This makes the solution easier to manage since there is no user interaction required to cycle the password on a regular basis. This would normally involve changing the password in Active Directory and then updating the individual services with the new password to ensure continuation of services, thus, eliminates service accounts with static passwords that are set upon creation, and then never cycled again, which is very normal in most of my customers.

Also, another thing very important about gMSA accounts, is that cannot be used to log on to any computers in the domain. This ensure the service account is only used for it’s intended purpose of running a service.

one thing to also to keep in mind is that service in olny available from W2012R2, so if your forest is running under W2008R2, forget it and upgrade your forest 🙂

If you want to go ahead and configure your gMSA account, you con do it by executing the following PowerShell:

New-ADServiceAccount AccountgMSA -DNSHostName AccountgMSA.fqdn -PrincipalsAllowedToRetrieveManagedPassword nameoftheServerstoretrievethegmsaaccount$ -KerberosEncryptionType RC4, AES128, AES256

the $ it is not a typpo, it is necessary to include the servers name. If you execute the script and you receive and error like the following:

You will need to create a key first, you can do it with the following command:

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10));

Once we have executed the previous command, we can execute the other one to create the account, which will appear in Users&Computers:

Revoming Naming Contexts

If you need to remove references to orphan domain, you will need to do it by removing naming contexts

Since W2008 versions do not have the “domain management” command, you will need to use the following procedure:

Click Start, click Run, type ntdsutil, and then press ENTER.

metadata cleanup

metadata cleanup: connections
server connections: connect to server (DC with Domain Naming Master)

q

metadata cleanup: select operation target

select operation target: list domains

select operation target: select domain (%d of unwanted Domain)

select operation target: list naming contexts

select operation target: select naming context (%d of naming conext to remove)

q

metadata cleanup: remove selected naming context

(repeat selecting naming contexts for all specified)

After doing that, you will be able to see that references are removed from AD, and after a while, will be replicated to other servers in the AD.