vrijdag 16 augustus 2013

Microsoft Office 365 Federation Metadata Update automation with ADFS Certificate Rollover

Hi, due to circumstances at home I’ve been away for a while.
But I’m planning to resume blogging.
First of all I know I want to point out that anyone who is using ADFS with auto certificate rollover should use this script. I know it’s been around for a while but I noticed it’s not well known among administrators.
So what does the script actually do?
Well, it creates a scheduled task which will automate the update of the Microsoft Office 365 federation metadata. The federation metadata contains certificate validity information for token-signing and token-decrypting and had to be updates with each change to one of the certificates..
When Auto Certificate rollover is enabled for ADFS, the ADFS service creates a new secondary certificate 20 days prior to expiration of the primary certificate. 5 days before expiration the primary and secondary certificates are switched and the new certificate goes live. The time in between is called the grace period
It is critical the federation metadata is updated prior to the end data of the grace period. If it is not this will result in the loss of access to all Office 365 services.
Source :  http://technet.microsoft.com/nl-nl/library/jj933264.aspx#BKMK_GracePeriod
To prevent this from happening the script was created, this will automate the update task so there will be no manual intervention when the certificates are updated.

The script can be downloaded from the Microsoft Gallery. Make sure you check the gallery on a regular base because it does get updated from time to time.
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
  • 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 http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652560.aspx
What I recommend is to create a service account for the update task that will have a non expiring password. In my case I created the svc_update_metadata account which had a non expiring password. This account had admin permissions within ADFS and Local admin permissions on the ADFS box.
To create the scheduled task I logged on with the service account on the machine because the task is created with the logged on user. 
After you download the tool  onto your internal ADFS server, you need to right-click on it and unblock it. Otherwise you will get errors like “the script is not digitally signed. The script will not execute on the system.”
Also, if you get an error that “Failed MSOL credential validation.” it is because you are running the script in the regular Windows Powershell or ADFS PowerShell module.  You need to make sure you run this in the window “Microsoft Online Services Module for Windows PowerShell” that looks like this on the desktop:
Run the installation script as follows.

It is recommended to also use a non expiring service account in Office 365 the entering the MSOL credentials. These credentials are stored in the credentials vault in Windows and need to be changed everytime the password is changed.
Once the script is run there will be a scheduled task in the task scheduler.
The schedule can be adjusted to your needs, but I ( and also Microsoft ) recommend to update metadata at least once a week.
A cool feature is that the script discovers all federeted domains within your tenant and will add this to the update script every time it is run. It also adds the –Supportmultipledomain switch when the command initially fails.
A logfile is written to the following folder:
The logfile will show the  result for each domain name discoved for both the internal ADFS and Office 365.
In the results below the certificate has already been updates so there is no “nexttokensigningcertificate” known in the internal ADFS log. Office 365 defaults back to the “old” certificate which is shown in the “nexttokensigningcertificate”
Office 365
And at the end it will show if the update works with or without the –supportmultipledomain switch and if the update had succeeded.
Hope this will help you in automating renewals in your Single Sign On solution.

2 opmerkingen: