You are browsing the archive for sso.

Configmgr 2012 & Windows Intune SSO : Self- signed certificate for token signing is about to expire. Now What?

12:15 pm in ADFS, ADFS 2.1, ADFS 3.0, ConfigMgr 2012, configmgr 2012 R2, ConfigMgr 2012 SP1, intune, SCCM 2012, SCCM 2012 R2, SCCM 2012 SP1, sso, Windows Intune, Windows Intune Extensions, windows inune by Kenny Buntinx [MVP]


This morning at a customer , I received the following mail in my mailbox , saying that my ADFS token would expire.

AD FS 2.0 or 2.1 and probably 3.0 generates each year by default a new self- signed certificate for token signing 20 days before the certificate expires . Rollover of the certificate , or generate a new certificate when the existing certificate is about to expire , and make them the primary certificate , applies only to self-signed certificates that are generated by AD FS 2.x . The token signing certificate is essential for the stability of the Federation Service . If this is changed, the change must be reported to Windows Azure AD . Otherwise fail applications for cloud services such as my Windows Intune Service.


When the token signing certificate of your home AD FS organization expires, then federation metadata between AD FS and Office 365 falls out of synch. Equally, when changes are made on the Office 365 or Windows Intune that require updating the metadata, a similar issue arises. The “Microsoft Office 365 Federation Metadata Update Automation Installation Tool” script provide by the AD FS team checks the that federation metadata is validated regularly and any changes replicated between the two federating parties.

You must have the Microsoft Federation Metadata Update Automation Installation Tool download and configure your primary federation server or another recordable federation server, the Windows Azure AD Federation Metadata regularly automatically checks and updates so that changes in the certificate token-signing in the AD FS 2.1 Federation service will be copied automatically onto Windows Azure AD.

You can download the script here :

The script is called : O365-Fed-MetaData-Update-Task-Installation.ps1

To execute this tool successfully:

  • You must make sure that you have installed the latest version of the Microsoft Online Services Module for Windows PowerShell 
  • You need to have a functioning AD FS 2.0 Federation Service (execute this on your primary ADFS server)
  • You need to have access to Global Administrator credentials for your Office 365 tenant
  • You need to have at least one verified domain in the Office 365 tenant must be of type ‘Federated’
  • This tool must be executed on a writable Federation Server
  • The currently logged on user must be a member of the local Administrators group
  • The Microsoft Online Services Module for Windows PowerShell must be installed. You can download the module from

When running the tool and you comply with the above prerequisites , the following screenshot appears as shown below :


It’s worth bearing in mind that the password policy will render the script unusable in the event of a password change on either the Windows Intune side with the MSOL account you specify and the Domain side with the user account used to initiate the scheduled task. It is possible to create service accounts to do this on both sides. However, I’d consider the security consequences of such a change before automatically doing so. This can be done on the O365 side with an Office 365 standard account via the Set-MSOLUser cmdlet.

For example:  Set-MSOLUser –identity –PasswordNeverExpires $true –StrongPasswordRequired $true

The account could also technically be a federated account, but I don’t believe that’s a good idea. In the event that the trust is broken, then a federated account won’t be able to connect to MSOL to update the federated domain information and you would be in trouble big time!

To verify the scheduled task is executed correctly , open task scheduler and verify that the task is there :


That’s again an automated task , without worrying that your infrastructure is in danger :-)

Hope it Helps ,

Kenny Buntinx

Enterprise Client Management MVP

ADFS 2.1 in combo with windows Intune stops working with ‘Error: 15404, State: 19. Could not obtain information about Windows NT group/user ‘Domain\ADFS_srvc’, error code 0x5

12:17 pm in ADFS, ADFS 2.1, CM12, CM12 R2, CM12 SP1, intune, sso by Kenny Buntinx [MVP]


One day my ADFS authentication for Configmgr 2012 R2 and Windows Intune suddenly stopped. I  came across the following on the Active Directory Federation Services farm which uses WID (Windows internal Database) to store its configuration.


In words: An exception occurred while enqueueing a message in the target queue. Error: 15404, State: 19. Could not obtain information about Windows NT group/user ‘<Domain>\ADFS_srvc’, error code 0x5.

The solution: is to give the “Authenticated Users”  “Read Permissions” on the ADFS service account.

Hope it Helps ,

Kenny Buntinx

Enterprise Client Management MVP