We are currently in the process of upgrading our domain controllers from Windows Server 2016 to Windows Server 2022 and there appears to be some security hardening going on when you upgrade to Windows Server 2022 and are using the built-in Default Domain Controllers Policy.
I patched our ADFS servers ending in even numbers this weekend and noticed in our monitoring system that the ADFS service wouldn’t start on the servers that were patched and restarted:
I spent the next hour clearing the GPO cache and staring at the “Login as a service” and “Login as a batch job” settings in our server domain GPO. Our ADFS service account had both rights. I blocked all domain GPOs to said server and restarted the server, then the ADFS service started after SCM (services.msc) granted it some missing privilege when I started the service on demand.
The solution was found via a Google search (quasi AI):
The Active Directory Federation Services (AD FS) service failure is caused by missing User Rights Assignment privileges for the AD FS service account. The most common missing privileges are “Generate security audits” and/or “Log on as a service”.
No where in the event logs does it specifically state it was missing the SeAuditPrivilege privilege.
However, it appears you can get the privileges a service needs by running this Powershell command:
(Get-ItemProperty “HKLM:\SYSTEM\CurrentControlSet\Services\adfssrv”).RequiredPrivileges
Then you can work backwards and see what GPO controls that privilege here.
I also had AI whip up this Powershell script that will give translate the “terse” privilege names to “friendly” GPO names.
Just change the top line of the script to:
$serviceName = “yourservicename”
It appears you can also use sc.exe to get this information (the .exe after sc is important, without it nothing will be displayed):
Something simliar happened on our Exchange server along the same lines a few weeks ago. I could not login to the Exchange SE ECP with my normal DA account from a different NT domain (but could use a DA account within that domain and it worked fine), looking at the event log on the Exchange server:
Process Microsoft.Exchange.Directory.TopologyService.exe (PID=4980). The Exchange computer <removed> does not have Audit Security Privilege on the domain controller <removed>. This domain controller will not be used by Exchange Active Directory Provider.
The fix was adding the Exchange Enterprise Servers group to this policy:
Computer Configuration
└── Policies
└── Windows Settings
└── Security Settings
└── Local Policies
└── User Rights Assignment
└── Manage auditing and security log
- Soli Deo Gloria