This blog post details the User Rights Assignments required for AADSync / AADConnect and the ADFS service accounts to allow them to do their thing! These privileges may be set on the Local Security Policy (secpol.msc) or may be controlled via Group Policy, depending on how your environment is configured. If you do come across any issues which look to be permissions based, please don’t just give the service accounts Domain or Enterprise Admin privileges! The reason we have service accounts is to limit the attack surface of any given application, and using the Domain/Enterprise Admin groups makes the whole concept of service accounts redundant. Anyway….

If your User Rights Assignments are configured in the Local Security Policy, the settings will be located under:

 Security Settings>Local Policies>User Rights Assignment

If your User Rights Assignments are configured in Group Policy, the settings will be located under:

Computer Configuration>Windows Settings>Security Settings>Local Policies>User Rights Assignment

If you need to add a local account to a Group Policy User Rights Assignment setting, then you will need to install the Group Policy Management Console feature on the machine which hosts the local account, and edit the group policy from there. This will allow you to resolve the local account details!

AADSync / AADConnect

If you are using AADSync, then the randomly generated AAD_xxxxxxxxx service account requires both ‘Log on as a service’ and ‘Log on as a batch job’ privileges for the machine on which AADSync is installed on.

If you are using AADConnect, then the randomly generated account mentioned above is no longer relevant (thankfully!) because it no longer exists. The synchronisation service now runs under the designated Active Directory service account, which is useful =] This account requires ‘log on as a service’, ‘log on as a batch job’ and also ‘log on locally’, although I’m not 100% sure why ‘log on locally’ is actually required.

ADFS

If ADFS is being installed, then the ADFS service account will require ‘Log on as a service’, as will the account ‘NTSERVICE\ALL SERVICES’. This last setting is done in order to allow the WID database for ADFS to work properly.

If you do not allow NTSERVICE to ‘Log on as a Service’, you may see the following error:

MSSQK$MICROSOFT##WID service was uanble to log on as NT SERVICE\MSSQL$MICROSOFT##WID

If this happens to you during the installation of ADFS, then your culprit will be the logon as a service rights!