Export (0) Print
Expand All

Verify and manage single sign-on with AD FS

Published: June 8, 2012

Updated: June 16, 2014

Applies To: Azure, Office 365, Windows Intune

noteNote
This topic might not be completely applicable to users of Microsoft Azure in China. For more information about Azure service in China, see windowsazure.cn.

As the administrator, before you verify and manage single sign-on (also called identity federation), review the information and perform the steps in Checklist: Use AD FS to implement and manage single sign-on.

After setting up single sign-on, you should verify that it is working correctly. Also, there are several management tasks you can occasionally perform to keep it running smoothly.

To verify that single sign-on has been set up correctly, you can perform the following procedure to confirm that you are able to sign in to the cloud service with your corporate credentials, Test single sign-on for different usage scenarios, and Use the Microsoft Remote Connectivity Analyzer.

noteNote
  • If you converted a domain, rather than adding one, it may take up to 24 hours to set up single sign-on.

  • Before you verify single sign-on, you should finish setting up Active Directory synchronization, synchronize your directories, and activate your synced users. For more information, see Directory synchronization roadmap.

To verify that single sign-on has been set up correctly, complete the following steps.

  1. On a domain-joined computer, sign in to your Microsoft cloud service using the same logon name that you use for your corporate credentials.

  2. Click inside the password box. If single sign-on is set up, the password box will be shaded, and you will see the following message: “You are now required to sign in at <your company>.”

  3. Click the Sign in at <your company> link.

    If you are able to sign in, then single sign-on has been set up.

After you have verified that single sign-on is complete, test the following sign-in scenarios to ensure that single sign-on and the AD FS 2.0 deployment are correctly configured. Ask a group of your users to test their access to the cloud service services from browsers as well as rich client applications, such as Microsoft Office 2010, in the following environments:

  • From a domain-joined computer

  • From a non-domain-joined computer inside the corporate network

  • From a roaming domain-joined computer outside the corporate network

  • From the different operating systems that you use in your company

  • From a home computer

  • From an Internet kiosk (test access to the cloud service through a browser only)

  • From a smart phone (for example, a smart phone that uses Microsoft Exchange ActiveSync)

To test single sign-on connectivity, you can use the Microsoft Remote Connectivity Analyzer. Click the Office 365 tab, click Microsoft Single Sign-On, and then click Next. Follow the screen prompts to perform the test. The analyzer validates your ability to sign on to the cloud service with your corporate credentials. It also validates some basic AD FS 2.0 configuration.

What do you want to do?

By default, AD FS generates a new self-signed token-signing certificate, 20 days before the certificate expires each year. Certificate rollover, or generating a new certificate when the existing certificate is about to expire and then promoting it to the primary certificate, applies only to self-signed certificates that are generated by AD FS.

The token-signing certificate is critical to the stability of the Federation Service. In case it is changed, Azure AD needs to be notified about this change. Otherwise, requests made to your cloud services will fail. You need to download and configure the Microsoft Federation Metadata Update Automation Installation Tool on your primary federation server or any writeable federation server, which will automatically monitor and update the Azure AD federation metadata on a regular basis so that any changes made to the token signing certificate in the AD FS Federation Service is replicated to Azure AD automatically.

To run this tool successfully:

  • You need must have deployed at least one AD FS Federation Service.

  • You must have completed the steps in Set up a trust between AD FS and Azure AD.

  • This tool must be run on your primary federation server or on a writable Federation Server.

  • You need to have access to Global Administrator credentials for your Azure AD tenant.

    noteNote
    If you have not set the Global Administrator credentials with ‘password – do not expire’, make sure to re-run this tool with the new password after the password for Global Administrator has expired. Otherwise, the scheduled task will fail.

The steps to run this tool are as follows:

  1. Download and save the Microsoft Federation Metadata Update Automation Installation Tool to your computer.

  2. Start the Administrator Windows PowerShell module, and then change to the directory where you copied the tool.

  3. At the prompt, type .\O365-Fed-MetaData-Update-Task-Installation.ps1, and then press ENTER.

  4. At the prompt, type the federated domain name, and then press ENTER.

  5. At the prompt, type your User ID credentials, and then press ENTER.

  6. At the prompt, type your local administrator credentials, and then press ENTER.

After completing those steps, the script will create a scheduled task to run as the local administrator credentials provided in step 6 above. The scheduled task will run once per day.

noteNote
This tool needs to be run for each federated domain in your account, and it does not currently provide support for multiple top-level domains. For more information, see Support for Multiple Top Level Domains. It is recommended that you periodically check that that the scheduled task is running correctly by making sure the log file is being generated successfully.

noteNote
You can configure when AD FS generates the new token signing certificate. When the certificate rollover time comes, AD FS generates a new certificate with the same name as the expiring certificate but with a different private key and thumbprint. Once a new certificate is generated, it will remain as a secondary certificate for five days before being promoted as the primary certificate. Five days is the default period, but this is configurable.

There are other optional or occasional tasks that you can do to keep single sign-on running smoothly.

After you add or convert your domains as part of setting up single sign-on, you may want to add the fully qualified domain name of your AD FS server to the list of Trusted Sites in Internet Explorer. This will ensure that users are not prompted for their password to the AD FS server. This change needs to be made on the client. You can also make this change for your users by specifying a Group Policy setting which will automatically add this URL to the Trusted Sites list for domain-joined computers. For more information, see Internet Explorer Policy Settings.

AD FS provides administrators with the option to define custom rules that will grant or deny users’ access. For single sign-on, the custom rules should be applied to the relying party trust associated with the cloud service. You created this trust when you ran the cmdlets in Windows PowerShell to set up single sign-on.

For more information about how to restrict users from signing in to services, see Create a Rule to Permit or Deny Users Based on an Incoming Claim. For more information about running cmdlets to set up single sign-on, see Install Windows PowerShell for single sign-on with AD FS.

If at any time you want to view the current AD FS server and the cloud service settings, you can open the Microsoft Azure Active Directory Module for Windows PowerShell and run Connect-MSOLService, then run Get-MSOLFederationProperty –DomainName <domain>. This allows you to check that the settings on the AD FS server are consistent with those in the cloud service. If the settings do not match, you can run Update-MsolFederatedDomain –DomainName <domain>. See the next section, “Update trust properties,” for more information.

noteNote
If you need to support multiple top-level domains, such as contoso.com and fabrikam.com, you must use the SupportMultipleDomain switch with any cmdlets. For more information, see Support for Multiple Top Level Domains.

What do you want to do?

You must update the single sign-on trust properties in the cloud service when:

  • The URL changes: If you make changes to the URL for the AD FS server, then you must update the trust properties.

  • The primary token signing certificate has been changed: Changing the primary token signing certificate triggers event ID 334 or event ID 335 in Event Viewer for AD FS server. We recommend that you check Event Viewer regularly, at least on a weekly basis.

    To view the events for the AD FS server, follow these steps.

    1. Click Start, and then click Control Panel. In Category view, click System and Security, then click Administrative Tools, and then click Event Viewer.

    2. To view the events for AD FS, in the left pane of Event Viewer, click Applications and Services Logs, then click AD FS 2.0, and then click Admin.

  • The token signing certificate expires every year: The token-signing certificate is critical to the stability of the Federation Service. In case it is changed, Azure AD needs to be notified about this change. Otherwise, requests made to your cloud services will fail.

    Please follow the steps provided above in the Set up scheduled task section of this topic which will walk you through how to download and configure the Microsoft Federation Metadata Update Automation Installation Tool. This tool will automatically monitor and update the Azure AD federation metadata on a regular basis so that any changes made to the token signing certificate in the AD FS Federation Service will be replicated to Azure AD automatically.

To manually update trust properties, follow these steps.

noteNote
If you need to support multiple top-level domains, such as contoso.com and fabrikam.com, you must use the SupportMultipleDomain switch with any cmdlets. For more information, see Support for Multiple Top Level Domains.

  1. Open the Microsoft Azure Active Directory Module for Windows PowerShell.

  2. Run $cred=Get-Credential. When this cmdlet prompts you for credentials, type your cloud service administrator account credentials.

  3. Run Connect-MsolService –Credential $cred. This cmdlet connects you to the cloud service. Creating a context that connects you to the cloud service is required before running any of the additional cmdlets installed by the tool.

  4. Run Set-MSOLAdfscontext -Computer <AD FS primary server>, where <AD FS primary server> is the internal FQDN name of the primary AD FS server. This cmdlet creates a context that connects you to AD FS.

    noteNote
    If you have installed the Microsoft Azure Active Directory Module on the primary server, then you do not need to run this cmdlet.

  5. Run Update-MSOLFederatedDomain –DomainName <domain>. This cmdlet updates the settings from AD FS into the cloud service and configures the trust relationship between the two.

What do you want to do?

In the event that you lose your primary server and are not able to recover it, you will need to promote another server to become the primary server. For more information, see AD FS 2.0 - How to Set the Primary Federation Server in a WID Farm.

noteNote
If one of your AD FS servers fails, and you have set up a high availability farm configuration, users will still be able to access the cloud service. If the failed server is the primary server, you will not be able to perform any updates to the farm configuration until you promote another server to become the primary.

If you lose all servers in the farm, you must rebuild the trust with the following steps.

noteNote
If you need to support multiple top-level domains, such as contoso.com and fabrikam.com, you must use the SupportMultipleDomain switch with any cmdlets. When you use the SupportMultipleDomain switch, you usually have to run the procedure on each of your domains. However, to recover your AD FS server, you only need to follow the procedure once for one of your domains. Once your server is recovered, all of your other single sign-on domains will connect to the cloud service. For more information, see Support for Multiple Top Level Domains.

  1. Open the Microsoft Azure Active Directory Module.

  2. Run $cred=Get-Credential. When the cmdlet prompts you for credentials, type your cloud service administrator account credentials.

  3. Run Connect-MsolService –Credential $cred. This cmdlet connects you to the cloud service. Creating a context that connects you to the cloud service is required before running any of the additional cmdlets installed by the tool.

  4. Run Set-MSOLAdfscontext -Computer <AD FS primary server>, where <AD FS primary server> is the internal FQDN name of the primary AD FS server. This cmdlet creates a context that connects you to AD FS.

    noteNote
    If you have installed the Microsoft Azure Active Directory Module on the primary AD FS server, then you do not need to run this cmdlet.

  5. Run Update-MsolFederatedDomain –DomainName <domain>, where <domain> is the domain for which you want to update properties. This cmdlet updates the properties and establishes the trust relationship.

  6. Run Get-MsolFederationProperty –DomainName <domain>, where <domain> is the domain for which you want to view properties. You can then compare the properties from the primary AD FS server and the properties in the cloud service to make sure they match. If they don’t match, run Update-MsolFederatedDomain –DomainName <domain> again to sync the properties.

See Also

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft