Testing AADConnect Part 5 - Verifying
Till now, in the last posts, we saw how one can install and configure AAD Connect. In this post, we will see how to verify the install and check and verify whether AAD Connect is syncing our users to Azure AD just fine.
Firstly, we had installed our AAD Connect in Staging mode we need to disable staging mode and enable it to SYNC.
Open the AAD Connect configuration file and click on Configure.
Here select "View Current Configuration" to check the current configuration.
We can see the Account that we are using for AAD Connect here. If you did not use Custom installation and used express installation you would see an account like "MSOL_xxxxx"
And the other options we selected for installing and configuring AAD Connect.
Select "Configure staging mode(current state:enabled)" and click Next.
Here give the Azure AD credentials.
Uncheck the "Enable Staging mode"
Here check the option that says "Start the Syncronization.."
Get-ADSyncScheduler output before and after enabling "Start Synchronization" as shown above
Once done, you can open the "Synchronization Service Manager" > Connectors > On-Prem Connector.
Here we can click on Containers and see the OU filtering we had selected earlier and do any changes that are required.
Synchronization Service Manager can we viewed to see the Sync status as shown below
On the first Sync, it added 57 On-prem objects to the cloud.
We can click on the ADDs to see the accounts that were added.
Selecting any object will give us details about that specific account.
Connect to MSOL PowerShell to check the objects that are being Synced as shown below.
In portal, we can check the DirSync Status as shown below
We saw the account that AAD Connect is using for syncing. If we go to services.msc and select the Microsoft Azure AD SYNC service we can see an account like "AAD_xxxx". It is a local service account is created by the installation wizard.`
The account is created with a long complex password that does not expire.
This account is used to store the passwords for the other accounts in a secure way. These other accounts passwords are stored encrypted in the database. The private keys for the encryption keys are protected with the cryptographic services secret-key encryption using Windows Data Protection API (DPAPI). You should not reset the password on the service account since Windows will then destroy the encryption keys for security reasons.
You should not reset the password on the service account since Windows will then destroy the encryption keys for security reasons.
We can check the same is AD users and computers.
We see that AAD_xxxx is also part of ADSYNCadmins group.
There are other ADSYNC groups that are created as shown below
We also have AzureADSSOACC is the account that will be used for single sign on. When you enable Single Sign-on for either Password Sync or Pass through Authentication. This account is created on on-premise which is used to encrypt the KERBEROS ticket that is being given to the client to be consumed by Azure AD