Jaa

Verify and manage single sign-on with AD FS

  • Artikkeli

Updated: June 25, 2015

Applies To: Azure, Office 365, Power BI, Windows Intune

Note

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.

What do you want to do?

  • Verify that single sign-on has been set up correctly

  • Manage single sign-on

Verify that single sign-on has been set up correctly

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.

Note

  • 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.

Test single sign-on for different usage scenarios

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)

Use the Microsoft Remote Connectivity Analyzer

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?

Schedule task to update Azure AD when a change is made to the token signing certificate no longer the recommendation

If you are using AD FS 2.0 or later, Office 365 and Azure AD will automatically update your certificate before it expires.  You do not need to perform any manual steps or run a script as a scheduled task.  For this to work, both of the following default AD FS configuration settings must be in effect:

  1. The AD FS property AutoCertificateRollover must be set to True, indicating that AD FS will automatically generate new token signing and token decryption certificates before the old ones expire. If the value is False, you are using custom certificate settings.  Go here for comprehensive guidance.

  2. Your federation metadata must be available to the public internet.

Manage single sign-on

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

In this section

  • Add URLs to Trusted Sites in Internet Explorer

  • Restrict users from signing in to the cloud service

  • View current settings

  • Update trust properties

  • Recover an AD FS server

  • Customize Local Authentication Type

Add URLs to Trusted Sites in Internet Explorer

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.

Restrict users from signing in to the cloud service

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.

View current settings

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.

Note

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?

Update trust properties

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.

To manually update trust properties, follow these steps.

Note

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.

    Note

    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?

Recover an AD FS server

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.

Note

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.

Note

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.

    Note

    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

Concepts

Checklist: Use AD FS to implement and manage single sign-on
Single sign-on roadmap