Numerous challenges & issues presented themselves during the AD Connect implementation at a recent customer. The first was that they had already bought some E3 & E5 licenses & started to use the mailboxes, PowerBI etc. The second major issue was caused by the fact that their AD had been upgraded from Small Business Server, which caused Password write-back to fail.
- Problem: Synchronising to accounts that are member of Azure group Global Admins fails.
- The customer had some existing E3 & E5 licenses & were using them. Two of the E5 users had Azure AD accounts that were members of Azure group “Global Admins”. The rest were configured as users in Azure AD. On initial sync AD Connect (ADC) (using a soft match on UPN/SMTP address), matched all the users fine, but created 2 new Azure AD accounts for the 2 admins. After deleting those 2 new Azure accounts, ADC refused to match them still. Only deleting the Azure AD accounts & letting ADC create new ones, then adding those back into all their Azure groups (including Global Admins) worked.
- Problem: Password Hash synchronisation failed immediately after ADC installation.
- The customer wanted to name the ADC service account & choose it’s OU. That meant choosing “use an existing account” during installation, & not letting ADC create its own. If you do this, the wizard doesn’t give the existing account any new rights. You have to do this manually. I knew that, but it takes time of course & until you do add the rights, numerous things will fail. This page explains how to add the rights: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account
- Problem: Two E3 users had repeated account lockouts as soon as ADC started synchronising on-prem passwords to Azure.
- This was a curious one, Outlook had prompted them for a password, they specified their AD one, but within minutes they would be locked out. It took some time to figure out what was happening here, we isolated it to just Outlook. Resetting AD passwords had no effect. Changing their UPN in ADUC & proxy addresses had no effect (i.e. Putting back their initial config). I realised they must have had cached credentials & asked the customer to clear them out on the laptops; this fixed it. They had cached their Azure credentials in Outlook, which then caused lockouts. Only had a problem with these 2 users though, other E3/E5 users were not impacted, so obviously didn’t have cached creds.
- Problem: SSPR password write-back failed after setting the 2 new passwords.
- The Application event log on the ADC server was saying the ADC account didn’t have permission to reset the password; but I triple checked & everything was set as per Microsoft BP/config etc. This was a thorny one to fix & took most of a 3rd day. After much troubleshooting & log searching, I discovered that the AD users accounts in a specific OU didn’t have inheritance configured. I discovered that all accounts were members of Print Operators & Domain Power Users (yes you read that right!). This last group existed in Small Business Server 2003! So their WS2012R2 AD was upgraded from that & kept specific things from SBS. These 2 groups are protected, so SDProp runs every N hours & resets the permissions on objects that are members of these groups using AdminSDHolder. So they are configured without inheritance & even if I ticked “enable inheritance”, SDProp would remove it within hours. The fix? Well only adding the ADC account to Domain Admins was about the only solution. Restarting the ADC service too, to pick up those new rights. This leaves the customer to sort out the SBS “mess” of those 2 groups, removing users from them & then enabling inheritance on the user accounts, then removing the ADC account from Domain Admins.
