AAD Connect Error, Encryption Keys Could Not Be Accessed

Hello again,

This installment I have a write up on an error a co-worker encountered in AAD Connect. All credit for write up goes to an engineer by the name Cody Rowe, reposted here with permission. Thanks Cody!

Fixing AAD Connect Service Account Issues

Friday, February 10, 2017

12:58

Issue: Server had not been restarted for a very long time.  Customer needed to install updated VMWare tools for their backup solution.  On reboot, the ad sync service could not start and gave off this error.

Resolution:

That led me to a few thoughts after doing some searching. 

·         An update was installed after reboot.  Maybe this broke the service.

·         The local service account used to start the ad sync service was affected by the reboot.

After coming up empty with repairing, reinstalling and looking over event viewer longer, I decided to proceed with the assumption that the local service account had its password reset.  I reset the password to the local service account :

Added the service account to local administrators to be able to log into the machine with said account.  Logged out and logged in as the service account.  Make sure you update the password associated with the service

Now I went through the process of abandoning the previous encryption key and adding in a new one.  Run miiskmu.exe located in the Bin folder for the ad sync directory with elevated permissions.

You'll want to select Abandon key set, then provide the credentials for the local service account.

When the operation is complete, stop the ad sync service since it will automatically start and attempt to create new encryption keys.  Go back to the key management utility and select add new key to key set.  I opted to select re-encrypt as well.

When that finishes start the service and open powershell.  Run the following.

Import-module adsync

Start-adsyncsyncCycle -policytype delta

After this ran I was getting some errors I did not expect to happen when it was healthy.

Specifically the stopped-extension-dll-exception is what I'm concerned about.  Going to event viewer it appeared that I was getting password issues with the service accounts.

I reset passwords for all the service accounts (AD for both forests, Cloud service account for machine) and added the updated passwords to the connection credentials for all 3 connectors.

After that I ran another delta sync, and everything came back clean.

Editors Note, From another colleague

To add to that, when you abandon the key, all of the data inside the sync database that was encrypted with the old key is invalid.  This includes the passwords for the accounts used by each connector.  This is why the last step was required