Search This Blog

Friday, February 10, 2017

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 colleagueTo 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