I’ve recently built a new lab for my Office 365 tenant including Azure AD Sync and ADFS running on Windows Server 2012 R2 machines. Everything worked as expected until I installed some updates on the ADFS server and restarted it. I noticed right away that the Active Directory Federation Service did not start at all. When I checked in services.msc I noticed that it is in a “starting” state. I waited a lot, but it remained the same.
I tried t stop it and to restart it manually. However, when I did this I received an error message pointing out that the service account may be short of some necessary permissions. This seemed very strange to me, since it worked perfectly before the reboot. As a further background, I was using an gMSA account as ADFS service account.
When searching the web for some hints, I found lot of stuff related to similar behaviour, all information referred to a scenario where the ADFS server role was installed on a DC. And this was not my case, since I have a dedicated machine for my ADFS server.
So I started to put together all my knowledge on how ADFS works, in order to find out on what dependencies this ADFS service relies. Finally I managed to resolve this issue on my machine.
The resolution was kind of simple. In order to perform all necessary tasks, the service account needs some specific permissions. So I opened secpol on the server and made sure that the used service account is added to the following permissions in User Rights Assignments:
Act as part of the operating system
Generate security audits
Lock pages in memory
Log on as a batch job
Log on as a service
Afterwards I restarted the server and everything works fine now.
I really can’t guarantee 100% that this will help in all cases where the ADFS service does not start after a server reboot, but at least in my case this really helped.
Latest posts by Dan Patrascu-Baba (see all)
- ADFS in multi forest environments - 20/10/2017
- #Build 2017 – some exciting things - 10/05/2017
- Testing Azure AD per app MFA and conditional access based on network location - 29/07/2016