AD FS Windows 2012 R2: adfssrv hangs in starting mode
Question
Thursday, October 17, 2013 1:52 PM | 1 vote
Does anyone has the same issue. Installed and configured ADFS with service account. After a server reboot service cannot start anymore and it always stay in "starting" state.
Unfortunately nothing in a log and no Windows Updates for 2012 R2 yet... many holes like Swiss cheese.
Thanks!
All replies (21)
Thursday, December 12, 2013 12:17 PM ✅Answered | 8 votes
If you have AD FS installed on the DC running 2012 R2 and use a gmsa for the service account, set the kdssvc to auto (instead of manual trigger) and restart the DC. You'll find this fixes this issue. You should no longer have a recurrence.
Please report back if you do.
M@
Friday, February 7, 2014 9:46 PM ✅Answered | 14 votes
Note that if you just set the Microsoft Key Distribution Service to Automatic, it will end up being set to Automatic (Trigger Start). The default trigger has created problems for AD FS startup (for me and maybe others too). You can query the trigger configuration by running the sc qtriggerinfo kdssvc command. The default for the Microsoft Key Distribution Service is using an RPC trigger which will start the service when a request is received on the interface. In my testing, I still run into trouble with the AD FS service starting up.
The workaround that I found to be consistent is changing the trigger configuration so that it relies on a different trigger. The command to use is sc triggerinfo kdssvc start/networkon which starts the service when the network is on (typically very early in the boot cycle).
I also tested removing the trigger completely but that wasn't effective at all.
Brian
Thursday, October 17, 2013 9:17 PM
Hi Matt,
Is the same machine also a domain controller?
Regards,
Mylo
Friday, October 18, 2013 6:50 AM
Hi Matt,
Thank you for your posting.
Since Active Directory Federation Service is not an extension of Active Directory, I suggest you refer to Geneva Forum to get professional support:
Geneva Forum
http://social.msdn.microsoft.com/Forums/vstudio/en-US/home?forum=Geneva
Thank you for your understanding and support.
Best Regards,
Amy Wang
Friday, October 18, 2013 6:19 PM
Hi Mylo,
Yes AD FS server is also one of the domain controllers. Just tried it now on totally different system and got same behaviour. I think it is something about new Managed Service Accounts.
Regards,
Matt
Friday, October 18, 2013 7:34 PM
Hi Matt,
You could be right on the MSA . I've seen this behavior when testing as well on a consolidated setup with a DC/FS role. I'm just setting up a separate AD FS 3.0 instance on another VM and see if the same thing happens. I'll keep you posted.
Regards,
Mylo
Friday, October 18, 2013 7:49 PM
Thanks Mylo, one thing I noticed now when re-installed with Windows Account. There is now drs and **adfssrv **groups with Read permissions on certificate's private key. I don't remember seeing them with MSA.
BTW when this behaviour occurs you will need to restart server into safe mode and put adfs service to manual.
Celox Group - Cloud Provider
Friday, October 18, 2013 9:28 PM
Hi Matt,
Just to give you an update. I installed AD FS on a separate VM using a Managed Service Account. I didn't see a "starting" issue with the service, as I did when co-located on a domain controller, but it seems that the delayed start on the service means that its failed on the first cycle and second. I changed the timers down to a more aggressive setting on 1 minute and the remedial action on the 3rd attempt to continuing trying. After around 3-4 minutes, the service starts fine with a managed service account, so perhaps I was just being impatient. That has some interesting ramifications though if plan on sitting AD FS behind a load balancer and "probing" the availability of the service through something like the idpinitiatedsignon.aspx page as the new relaxed settings on service startup will mean that the probe window becomes larger time-wise.
On the "Manage Private Keys" side, the adfssrv and drs services have read-only rather than the service account itself (if you're not using a GMSA account). I suspect this means that GMSA access to the private key is implicit through the adfssrv service itself rather than explicit reference through a service account.
Keep it coming. We're all learning :-)
Regards,
Mylo
Friday, October 18, 2013 9:33 PM
Wanted to just modify that last comment.. given that we're not using IIS and application pools and using kernel mode, then everything is wrapped around adfssrv. I've not tried using a normal service account yet.
Monday, November 18, 2013 7:23 PM | 1 vote
This issue appears to be gMSA related, when you install ADFS 3.0 on a 2012R2 running AD DS, than after the reboot (not always) gMSA fails to authenticate on behalf of the ADFS Service under which the service is configured to run. After investigation I eventually found an unacceptable workaround, which is (1) Reboot the ADDS/ADFS3.0 server, logon and immediately set the ADFS Service from Automatic (Delayed) to Manual. (2) Open the AD PowerShell and reset the gMSA service account password (3) Start the ADFS service (starts successfully) (4) Set the service back to automatic (delayed). Done. I am not sure if anyone else has tried to work around this issue which we are experiencing but it appears to be gMSA related. Configuring ADFS to run under normal non-gMSA account works perfectly fine (tested).
Thanks All
Paresh Nhathalal [MSFT]
paresh
Friday, November 22, 2013 5:01 AM
Hi Paresh,
I'm not able to modify the ADFS service to manual. The system just hangs. Do you have a suggestion?
Best regards,
Klauss
Friday, November 22, 2013 5:04 AM | 1 vote
Hi Klauss,
Boot your system to Safe Mode. Then you will be able to change AFDS service to manual.
Regards,
Matt
Friday, November 22, 2013 5:11 AM
Hi Matt,
Lack of sleep. Totally forgot to do it under safe mode.
Thank you for the help.
Best regards,
Klauss
Friday, November 22, 2013 5:53 AM
Hi Paresh & Matt,
The workaround worked. The password reset took a little while, but it went through.
I have been trying to change the account that AD FS uses to avoid this problem. I have not been able to do this. When I restart the server, the AD FS continues to the same thing. I had the reset the password again. This was the only way to make it run.
Could you help me?
Thank you
Klauss
Friday, December 20, 2013 12:49 PM | 1 vote
I can confirm that putting the Microsoft Key Distribution Service on Automatic resolves the issue. Thanks!!
Marc
Thursday, January 2, 2014 11:05 PM | 1 vote
I changed the Microsoft Key Distribution Service to Automatic and restarted the computer. The ADFS service was set to a delayed start and it attempted to start before the Key Dist Service which instead of simple automatic is displaying as Automatic (Trigger Start). It fails to start if I manually start it while the ADFS service is hung in the starting state.
Randy
Thursday, March 13, 2014 9:20 AM
We've just experienced this problem - thanks for the solution!
Can anyone else confirm that the triggers definitely need changing?
Thanks,
Daniel
Thursday, April 10, 2014 3:36 AM
Microsoft Key Distribution Service is the key and needs to started. The sc triggerinfo kdssvc start/networkon command did the trick.
Thanks !
Jojo
Monday, June 2, 2014 2:22 AM
Hi Daniel,
We can confirm we're having the same issue. Had to reboot in to Safe Mode, change the KDC to run the trigger start and set ADFS to manual, restart normally then manually start ADFS and reset to automatic delayed.
This seems to be working for now.
Jason.
Consultant | Nerd | Visionary. http://www.ethertech.com.au/ | http://www.deeperstates.com.au
Wednesday, July 9, 2014 6:19 PM
Note that if you just set the Microsoft Key Distribution Service to Automatic, it will end up being set to Automatic (Trigger Start). The default trigger has created problems for AD FS startup (for me and maybe others too). You can query the trigger configuration by running the sc qtriggerinfo kdssvc command. The default for the Microsoft Key Distribution Service is using an RPC trigger which will start the service when a request is received on the interface. In my testing, I still run into trouble with the AD FS service starting up.
The workaround that I found to be consistent is changing the trigger configuration so that it relies on a different trigger. The command to use is sc triggerinfo kdssvc start/networkon which starts the service when the network is on (typically very early in the boot cycle).
I also tested removing the trigger completely but that wasn't effective at all.
Brian
Setting sc triggerinfo kdssvc start/networkon worked perfectly for me. Thank you!
Monday, October 22, 2018 9:12 AM
Thank you for this big help!
This resolved my issue of AD FS service being hanged as well as AD FS service giving timeout error. Although AD FS Service still not starts automatically after reboot.