Tags


Support for Multiple Top Level Domains

http://community.office365.com/en-us/w/sso/support-for-multiple-top-level-domains.aspx

Currently, Microsoft Office 365 customers who utilize single sign-on (SSO) through AD FS 2.0 and have multiple top level domains for users’ user principal name (UPN) suffixes within their organization (for example, @contoso.com or @fabrikam.com) are required to deploy a separate instance of AD FS 2.0 Federation Service for each suffix.  There is now a rollup for AD FS 2.0 (http://support.microsoft.com/kb/2607496) that works in conjunction with the “SupportMultipleDomain” switch to enable the AD FS server to support this scenario without requiring additional AD FS 2.0 servers.

Support for Sub domains

It is important to note that the “SupportMultipleDomain” switch is not required when you have a single top level domain and multiple sub domains.  For example if the domains used for upn suffixes are @sales.contoso.com, @marketing.contoso.com and @contoso.com and the top level domain (contoso.com in this case) was added first and federated then you don’t need to use the “SupportMultipleDomain” switch.  This is because these sub domains are effectively managed within the scope of the parent and a single AD FS server can be utilized to handle this already. If however, you have multiple top level domains (@contoso.com and @fabrikam.com) and these domains also have sub domains (@sales.contoso.com and @sales.fabrikam.com) the “SupportMultipleDomain” switch will not work for the sub domains and these users will not be able to login.  We are working on a solution for this problem and will post this as soon as it is ready until then we can’t support this solution.

What if I already have multiple AD FS Servers or need to add more supported domains?

If you currently have an AD FS 2.0 server that is configured to support a single domain or you have multiple AD FS 2.0 servers, one for each federated top level and want to move to a single server or add more domains to an existing server the following procedure will help you with that process.  NOTE:  During this process customers will be unable to authenticate for a few minutes while the trust is being recreated.

  1. Select the primary server of the AD FS Farm you want to keep (if you have more than one or the current server
  2. Ensure you have the Microsoft Online Services Module for Windows PowerShell installed and working correctly (see http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652560.aspx for more details).  This is very important to minimize the downtime impact.
  3. Ensure you are able to update the current trust (Update-MsolFederatedDomain -DomainName <domainname>) using the following “Update trust properties” in the following article http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652538.aspx.  Again make sure that you can do this, if you can’t you should fix this before you move forward.
  4. After and only after ensuring you can update the trust perform the following on the AD FS Primary server, once you complete this step users won’t be able to logon (if you have multiple servers this will only affect the users for this one server):
    • Open the “AD FS 2.0 Management Console”
    • Navigate to the Relying Parties node (Trust Relationships |Relying Party Trusts)
    • Delete the Relying party “Microsoft Office 365 Identity Platform” or “Microsoft Online Trust”
  5. Re run step 3 to update the trust again making sure to include the “-SupportMultipleDomain” this time.  This will recreate the trust for you and set it such that you can add additional top level domains to the server.  At the end of the step users will be able to logon again.
  6. Refresh the view in the “AD FS 2.0 Management Console” to ensure the trust has been recreated.
  7. Run Get-MSOLFederationProperty -DomainName <domain> -SupportMulitpleDomain to confirm the settings are correct on both AD FS 2.0 and the Cloud.

If you have more top level domains on other servers then run Update-MsolFederatedDomain -DomainName <domain> -SupportMulitpleDomain on the server above, once you have confirmed the update you can decommission the other servers.  If you are simply adding more top level domains then use the standard procedures to add a new domain or convert an existing domain, remembering to use the -SupportMulitpleDomain as you add or convert the domains.

http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652560.aspx

Install and configure the Microsoft Online Services Module for Windows PowerShell for single sign-on

After you, the administrator, have deployed Active Directory Federation Services (AD FS) 2.0, the next step to set up single sign-on is to download, install, and configure the Microsoft Online Services Module for Windows PowerShell. To do this, you must have the required software for the Microsoft Online Services Module. After you have downloaded and installed the module, you then run a series of cmdlets in the Windows PowerShell command-line interface to add or convert domains for single sign-on.

For more information about deploying AD FS 2.0, see Plan for and deploy Active Directory Federation Services 2.0 for use with single sign-on.

1. Follow the requirements for the Microsoft Online Services Module

The following are required in order to run the Microsoft Online Services Module:

  • Operating system: Use Windows 7 or Windows Server 2008 R2.
  • Microsoft .NET Framework: You must turn on the Microsoft .NET Framework 3.51 feature in Windows 7 or Windows Server 2008 R2.
  • Windows PowerShell 2.0 and AD FS 2.0: In order to run the cmdlets to set up single sign-on, you must turn on the Windows PowerShell 2.0 feature, and you must have administrator privileges on the AD FS 2.0 server. We recommend that you use remote access to the AD FS 2.0 server when you run the cmdlets; to do this you must use Windows PowerShell remoting. For information, see About_Remote_Requirements.
  • All Office 365 software updates: From the Office 365 downloads page, install the required updates. To access the Office 365 downloads page, sign in to the Office 365 portal, and, under Resources, click Downloads. These updates are required because the features in Office 365 will not work properly without the appropriate versions of operating systems, browsers, and software. For more information, see Set up your desktop for Office 365.

Back to top

2. Download the Microsoft Online Services Module

The Microsoft Online Services Module for Windows PowerShell is a download that comes with Office 365. This module installs a set of cmdlets to Windows PowerShell; you run those cmdlets to set up single sign-on for Office 365. Before you set up single sign-on in your full production environment, you can also run a single sign-on pilot. See Run a pilot to test single sign-on before setting it up (optional).

noteNote:
  • For more information about a cmdlet that you can run in Windows PowerShell, at the Windows PowerShell command prompt, type Get-help and the name of the cmdlet.
  • For more information about single sign-on cmdlets, see Use Windows PowerShell to manage Office 365.

Run a pilot to test single sign-on before setting it up (optional)

Before adding or converting a domain as a single sign-on domain, you may want to run a pilot. Performing a staged rollout of single sign-on is not currently possible; all users become federated at the same time. However, you can pilot single sign-on with a set of production users from your production Active Directory forest.

Pilot users should thoroughly test various sign-in scenarios to ensure that single sign-on (and the AD FS 2.0 deployment) is correctly configured and ready to be rolled out across the entire organization. To test this, have users access Office 365 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 (browser only)
  • From a smart phone (for example, a smart phone that uses Microsoft Exchange ActiveSync)

For more information, see How to pilot single sign-on in a production user forest.

Back to top

3. Set up a trust by adding or converting a domain for single sign-on

Each domain that you want to federate must either be added as a single sign-on domain or converted to be a single sign-on domain from a standard domain. Adding or converting a domain sets up a trust between AD FS 2.0 and Office 365.

importantImportant:
  • If you are using a subdomain (for example, corp.contoso.com) in addition to a top-level domain (for example, contoso.com), you must add the top-level domain in Office 365 before you add any subdomains. When the top-level domain is set up for single sign-on, all subdomains are automatically set up as well.
  • Setting up a trust is a one-time operation, and you do not need to run the Microsoft Online Services Module again if you add more AD FS 2.0 servers to your server farm.
  • If you add and verify a domain with the Microsoft Online Services Module, you need to specify several additional settings in Office 365. These settings are required so that you can see the DNS records that you must configure to enable your domain to work with Office 365 services. For more information, see Specify the services you’ll use with your domain.
  • If you need to support multiple top-level domains, you must use the SupportMultipleDomain switch with any cmdlets, such as the cmdlets used in the “Add a domain” and the “Convert a domain” procedures. For example, to add both contoso.com and fabrikam.com as single sign-on domains, you would follow the “Add a domain” procedure for contoso.com, using the SupportMultipleDomain switch in each step that has a cmdlet. So, for step 5, you would use New-MsolFederatedDomain -DomainName contoso.com -SupportMultipleDomain. After you complete all the steps in the procedure for contoso.com, you would repeat the procedure again for your fabrikam.com domain. In step 5, you would use New-MsolFederatedDomain -DomainName fabrikam.com -SupportMultipleDomain. For more information, see Support for Multiple Top Level Domains.

Add a domain

  1. Open the Microsoft Online Services Module.
  2. Run $cred=Get-Credential. When the cmdlet prompts you for credentials, type your Office 365 administration account credentials.
  3. Run Connect-MsolService -Credential $cred. This cmdlet connects you to Office 365. Creating a context that connects you to Office 365 is required before running any of the additional cmdlets installed by the tool.
  4. Run Set-MsolAdfscontext -Computer <AD FS 2.0 primary server>, where <AD FS 2.0 primary server> is the internal FQDN name of the primary AD FS 2.0 server. This cmdlet creates a context that connects you to AD FS 2.0.
    noteNote:
    If you have installed the Microsoft Online Services Module on the primary AD FS 2.0 server, then you do not need to run this cmdlet.
  5. Run New-MsolFederatedDomain -DomainName <domain>, where <domain> is the domain to be added and enabled for single sign-on. This cmdlet adds a new top-level domain or subdomain that will be configured for federated authentication.
    noteNote:
    Once you have used the New-MsolFederatedDomain cmdlet to add a top-level domain you will not be able to use the New-MsolDomain cmdlet to add standard domains (non-federated).
  6. Using the information provided by the results of the New-MsolFederatedDomain cmdlet, contact your domain registrar to create the required DNS record. This verifies that you own the domain. Note that this may take up to 15 minutes to propagate, depending on your registrar. It can take up to 72 hours for changes to propagate through the system. For more information, see Locate my domain name registrar and Verify a domain at any domain name registrar.
  7. Run New-MsolFederatedDomain a second time, specifying the same domain name to finalize the process.

Convert a domain

When you convert an existing domain to a single sign-on domain, every licensed user will become a federated user, using their existing Active Directory corporate credentials (user name and password) to access services in Office 365. Performing a staged rollout of single sign-on is not currently possible; however, you can pilot single sign-on with a set of production users from your production Active Directory forest. For more information, see Run a pilot to test single signon before setting it up (optional).

noteNote:
It’s best to perform a conversion when there are the fewest users, such as on a weekend, to reduce the impact on your users.

To convert an existing domain to a single sign-on domain, follow these steps.

  1. Open the Microsoft Online Services Module.
  2. Run $cred=Get-Credential. When the cmdlet prompts you for credentials, type your Office 365 administration account credentials.
  3. Run Connect-MsolService -Credential $cred. This cmdlet connects you to Office 365. Creating a context that connects you to Office 365 is required before running any of the additional cmdlets installed by the tool.
  4. Run Set-MsolAdfscontext -Computer <AD FS 2.0 primary server>, where <AD FS 2.0 primary server> is the internal FQDN name of the primary AD FS 2.0 server. This cmdlet creates a context that connects you to AD FS 2.0.
    noteNote:
    If you have installed the Microsoft Online Services Module on the primary AD FS 2.0 server, then you do not need to run this cmdlet.
  5. Run Convert-MsolDomainToFederated -DomainName <domain>, where <domain> is the domain to be converted. This cmdlet changes the domain from standard authentication to single sign-on.
noteNote:
To verify that the conversion has worked, compare the settings on the AD FS 2.0 server and on Office 365 by running Get-MsolFederationProperty -DomainName <domain>, where <domain> is the domain for which you want to view settings. If they don’t match, you can run Update-MsolFederatedDomain -DomainName <domain> to sync the settings.
4. Next step

Install and configure the Microsoft Online Services Module for Windows PowerShell for single sign-on

After you, the administrator, have deployed Active Directory Federation Services (AD FS) 2.0, the next step to set up single sign-on is to download, install, and configure the Microsoft Online Services Module for Windows PowerShell. To do this, you must have the required software for the Microsoft Online Services Module. After you have downloaded and installed the module, you then run a series of cmdlets in the Windows PowerShell command-line interface to add or convert domains for single sign-on.

For more information about deploying AD FS 2.0, see Plan for and deploy Active Directory Federation Services 2.0 for use with single sign-on.

1. Follow the requirements for the Microsoft Online Services Module

The following are required in order to run the Microsoft Online Services Module:

  • Operating system: Use Windows 7 or Windows Server 2008 R2.
  • Microsoft .NET Framework: You must turn on the Microsoft .NET Framework 3.51 feature in Windows 7 or Windows Server 2008 R2.
  • Windows PowerShell 2.0 and AD FS 2.0: In order to run the cmdlets to set up single sign-on, you must turn on the Windows PowerShell 2.0 feature, and you must have administrator privileges on the AD FS 2.0 server. We recommend that you use remote access to the AD FS 2.0 server when you run the cmdlets; to do this you must use Windows PowerShell remoting. For information, see About_Remote_Requirements.
  • All Office 365 software updates: From the Office 365 downloads page, install the required updates. To access the Office 365 downloads page, sign in to the Office 365 portal, and, under Resources, click Downloads. These updates are required because the features in Office 365 will not work properly without the appropriate versions of operating systems, browsers, and software. For more information, see Set up your desktop for Office 365.

Back to top

2. Download the Microsoft Online Services Module

The Microsoft Online Services Module for Windows PowerShell is a download that comes with Office 365. This module installs a set of cmdlets to Windows PowerShell; you run those cmdlets to set up single sign-on for Office 365. Before you set up single sign-on in your full production environment, you can also run a single sign-on pilot. See Run a pilot to test single sign-on before setting it up (optional).

noteNote:
  • For more information about a cmdlet that you can run in Windows PowerShell, at the Windows PowerShell command prompt, type Get-help and the name of the cmdlet.
  • For more information about single sign-on cmdlets, see Use Windows PowerShell to manage Office 365.

Run a pilot to test single sign-on before setting it up (optional)

Before adding or converting a domain as a single sign-on domain, you may want to run a pilot. Performing a staged rollout of single sign-on is not currently possible; all users become federated at the same time. However, you can pilot single sign-on with a set of production users from your production Active Directory forest.

Pilot users should thoroughly test various sign-in scenarios to ensure that single sign-on (and the AD FS 2.0 deployment) is correctly configured and ready to be rolled out across the entire organization. To test this, have users access Office 365 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 (browser only)
  • From a smart phone (for example, a smart phone that uses Microsoft Exchange ActiveSync)

For more information, see How to pilot single sign-on in a production user forest.

Back to top

3. Set up a trust by adding or converting a domain for single sign-on

Each domain that you want to federate must either be added as a single sign-on domain or converted to be a single sign-on domain from a standard domain. Adding or converting a domain sets up a trust between AD FS 2.0 and Office 365.

importantImportant:
  • If you are using a subdomain (for example, corp.contoso.com) in addition to a top-level domain (for example, contoso.com), you must add the top-level domain in Office 365 before you add any subdomains. When the top-level domain is set up for single sign-on, all subdomains are automatically set up as well.
  • Setting up a trust is a one-time operation, and you do not need to run the Microsoft Online Services Module again if you add more AD FS 2.0 servers to your server farm.
  • If you add and verify a domain with the Microsoft Online Services Module, you need to specify several additional settings in Office 365. These settings are required so that you can see the DNS records that you must configure to enable your domain to work with Office 365 services. For more information, see Specify the services you’ll use with your domain.
  • If you need to support multiple top-level domains, you must use the SupportMultipleDomain switch with any cmdlets, such as the cmdlets used in the “Add a domain” and the “Convert a domain” procedures. For example, to add both contoso.com and fabrikam.com as single sign-on domains, you would follow the “Add a domain” procedure for contoso.com, using the SupportMultipleDomain switch in each step that has a cmdlet. So, for step 5, you would use New-MsolFederatedDomain -DomainName contoso.com -SupportMultipleDomain. After you complete all the steps in the procedure for contoso.com, you would repeat the procedure again for your fabrikam.com domain. In step 5, you would use New-MsolFederatedDomain -DomainName fabrikam.com -SupportMultipleDomain. For more information, see Support for Multiple Top Level Domains.

Add a domain

  1. Open the Microsoft Online Services Module.
  2. Run $cred=Get-Credential. When the cmdlet prompts you for credentials, type your Office 365 administration account credentials.
  3. Run Connect-MsolService -Credential $cred. This cmdlet connects you to Office 365. Creating a context that connects you to Office 365 is required before running any of the additional cmdlets installed by the tool.
  4. Run Set-MsolAdfscontext -Computer <AD FS 2.0 primary server>, where <AD FS 2.0 primary server> is the internal FQDN name of the primary AD FS 2.0 server. This cmdlet creates a context that connects you to AD FS 2.0.
    noteNote:
    If you have installed the Microsoft Online Services Module on the primary AD FS 2.0 server, then you do not need to run this cmdlet.
  5. Run New-MsolFederatedDomain -DomainName <domain>, where <domain> is the domain to be added and enabled for single sign-on. This cmdlet adds a new top-level domain or subdomain that will be configured for federated authentication.
    noteNote:
    Once you have used the New-MsolFederatedDomain cmdlet to add a top-level domain you will not be able to use the New-MsolDomain cmdlet to add standard domains (non-federated).
  6. Using the information provided by the results of the New-MsolFederatedDomain cmdlet, contact your domain registrar to create the required DNS record. This verifies that you own the domain. Note that this may take up to 15 minutes to propagate, depending on your registrar. It can take up to 72 hours for changes to propagate through the system. For more information, see Locate my domain name registrar and Verify a domain at any domain name registrar.
  7. Run New-MsolFederatedDomain a second time, specifying the same domain name to finalize the process.

Convert a domain

When you convert an existing domain to a single sign-on domain, every licensed user will become a federated user, using their existing Active Directory corporate credentials (user name and password) to access services in Office 365. Performing a staged rollout of single sign-on is not currently possible; however, you can pilot single sign-on with a set of production users from your production Active Directory forest. For more information, see Run a pilot to test single signon before setting it up (optional).

noteNote:
It’s best to perform a conversion when there are the fewest users, such as on a weekend, to reduce the impact on your users.

To convert an existing domain to a single sign-on domain, follow these steps.

  1. Open the Microsoft Online Services Module.
  2. Run $cred=Get-Credential. When the cmdlet prompts you for credentials, type your Office 365 administration account credentials.
  3. Run Connect-MsolService -Credential $cred. This cmdlet connects you to Office 365. Creating a context that connects you to Office 365 is required before running any of the additional cmdlets installed by the tool.
  4. Run Set-MsolAdfscontext -Computer <AD FS 2.0 primary server>, where <AD FS 2.0 primary server> is the internal FQDN name of the primary AD FS 2.0 server. This cmdlet creates a context that connects you to AD FS 2.0.
    noteNote:
    If you have installed the Microsoft Online Services Module on the primary AD FS 2.0 server, then you do not need to run this cmdlet.
  5. Run Convert-MsolDomainToFederated -DomainName <domain>, where <domain> is the domain to be converted. This cmdlet changes the domain from standard authentication to single sign-on.
noteNote:
To verify that the conversion has worked, compare the settings on the AD FS 2.0 server and on Office 365 by running Get-MsolFederationProperty -DomainName <domain>, where <domain> is the domain for which you want to view settings. If they don’t match, you can run Update-MsolFederatedDomain -DomainName <domain> to sync the settings.
4. Next step

Now that you have installed the module and configured the domains to use single sign-on, you must set up Active Directory synchronization. For more information, see Active Directory synchronization: Roadmap. After you have set up Active Directory synchronization, see Verify and manage single sign-on.

Now that you have installed the module and configured the domains to use single sign-on, you must set up Active Directory synchronization. For more information, see Active Directory synchronization: Roadmap. After you have set up Active Directory synchronization, see Verify and manage single sign-on.

Install and configure the Microsoft Online Services Module for Windows PowerShell for single sign-on

After you, the administrator, have deployed Active Directory Federation Services (AD FS) 2.0, the next step to set up single sign-on is to download, install, and configure the Microsoft Online Services Module for Windows PowerShell. To do this, you must have the required software for the Microsoft Online Services Module. After you have downloaded and installed the module, you then run a series of cmdlets in the Windows PowerShell command-line interface to add or convert domains for single sign-on.

For more information about deploying AD FS 2.0, see Plan for and deploy Active Directory Federation Services 2.0 for use with single sign-on.

1. Follow the requirements for the Microsoft Online Services Module

The following are required in order to run the Microsoft Online Services Module:

  • Operating system: Use Windows 7 or Windows Server 2008 R2.
  • Microsoft .NET Framework: You must turn on the Microsoft .NET Framework 3.51 feature in Windows 7 or Windows Server 2008 R2.
  • Windows PowerShell 2.0 and AD FS 2.0: In order to run the cmdlets to set up single sign-on, you must turn on the Windows PowerShell 2.0 feature, and you must have administrator privileges on the AD FS 2.0 server. We recommend that you use remote access to the AD FS 2.0 server when you run the cmdlets; to do this you must use Windows PowerShell remoting. For information, see About_Remote_Requirements.
  • All Office 365 software updates: From the Office 365 downloads page, install the required updates. To access the Office 365 downloads page, sign in to the Office 365 portal, and, under Resources, click Downloads. These updates are required because the features in Office 365 will not work properly without the appropriate versions of operating systems, browsers, and software. For more information, see Set up your desktop for Office 365.

Back to top

2. Download the Microsoft Online Services Module

The Microsoft Online Services Module for Windows PowerShell is a download that comes with Office 365. This module installs a set of cmdlets to Windows PowerShell; you run those cmdlets to set up single sign-on for Office 365. Before you set up single sign-on in your full production environment, you can also run a single sign-on pilot. See Run a pilot to test single sign-on before setting it up (optional).

noteNote:
  • For more information about a cmdlet that you can run in Windows PowerShell, at the Windows PowerShell command prompt, type Get-help and the name of the cmdlet.
  • For more information about single sign-on cmdlets, see Use Windows PowerShell to manage Office 365.

Run a pilot to test single sign-on before setting it up (optional)

Before adding or converting a domain as a single sign-on domain, you may want to run a pilot. Performing a staged rollout of single sign-on is not currently possible; all users become federated at the same time. However, you can pilot single sign-on with a set of production users from your production Active Directory forest.

Pilot users should thoroughly test various sign-in scenarios to ensure that single sign-on (and the AD FS 2.0 deployment) is correctly configured and ready to be rolled out across the entire organization. To test this, have users access Office 365 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 (browser only)
  • From a smart phone (for example, a smart phone that uses Microsoft Exchange ActiveSync)

For more information, see How to pilot single sign-on in a production user forest.

Back to top

3. Set up a trust by adding or converting a domain for single sign-on

Each domain that you want to federate must either be added as a single sign-on domain or converted to be a single sign-on domain from a standard domain. Adding or converting a domain sets up a trust between AD FS 2.0 and Office 365.

importantImportant:
  • If you are using a subdomain (for example, corp.contoso.com) in addition to a top-level domain (for example, contoso.com), you must add the top-level domain in Office 365 before you add any subdomains. When the top-level domain is set up for single sign-on, all subdomains are automatically set up as well.
  • Setting up a trust is a one-time operation, and you do not need to run the Microsoft Online Services Module again if you add more AD FS 2.0 servers to your server farm.
  • If you add and verify a domain with the Microsoft Online Services Module, you need to specify several additional settings in Office 365. These settings are required so that you can see the DNS records that you must configure to enable your domain to work with Office 365 services. For more information, see Specify the services you’ll use with your domain.
  • If you need to support multiple top-level domains, you must use the SupportMultipleDomain switch with any cmdlets, such as the cmdlets used in the “Add a domain” and the “Convert a domain” procedures. For example, to add both contoso.com and fabrikam.com as single sign-on domains, you would follow the “Add a domain” procedure for contoso.com, using the SupportMultipleDomain switch in each step that has a cmdlet. So, for step 5, you would use New-MsolFederatedDomain -DomainName contoso.com -SupportMultipleDomain. After you complete all the steps in the procedure for contoso.com, you would repeat the procedure again for your fabrikam.com domain. In step 5, you would use New-MsolFederatedDomain -DomainName fabrikam.com -SupportMultipleDomain. For more information, see Support for Multiple Top Level Domains.

Add a domain

  1. Open the Microsoft Online Services Module.
  2. Run $cred=Get-Credential. When the cmdlet prompts you for credentials, type your Office 365 administration account credentials.
  3. Run Connect-MsolService -Credential $cred. This cmdlet connects you to Office 365. Creating a context that connects you to Office 365 is required before running any of the additional cmdlets installed by the tool.
  4. Run Set-MsolAdfscontext -Computer <AD FS 2.0 primary server>, where <AD FS 2.0 primary server> is the internal FQDN name of the primary AD FS 2.0 server. This cmdlet creates a context that connects you to AD FS 2.0.
    noteNote:
    If you have installed the Microsoft Online Services Module on the primary AD FS 2.0 server, then you do not need to run this cmdlet.
  5. Run New-MsolFederatedDomain -DomainName <domain>, where <domain> is the domain to be added and enabled for single sign-on. This cmdlet adds a new top-level domain or subdomain that will be configured for federated authentication.
    noteNote:
    Once you have used the New-MsolFederatedDomain cmdlet to add a top-level domain you will not be able to use the New-MsolDomain cmdlet to add standard domains (non-federated).
  6. Using the information provided by the results of the New-MsolFederatedDomain cmdlet, contact your domain registrar to create the required DNS record. This verifies that you own the domain. Note that this may take up to 15 minutes to propagate, depending on your registrar. It can take up to 72 hours for changes to propagate through the system. For more information, see Locate my domain name registrar and Verify a domain at any domain name registrar.
  7. Run New-MsolFederatedDomain a second time, specifying the same domain name to finalize the process.

Convert a domain

When you convert an existing domain to a single sign-on domain, every licensed user will become a federated user, using their existing Active Directory corporate credentials (user name and password) to access services in Office 365. Performing a staged rollout of single sign-on is not currently possible; however, you can pilot single sign-on with a set of production users from your production Active Directory forest. For more information, see Run a pilot to test single signon before setting it up (optional).

noteNote:
It’s best to perform a conversion when there are the fewest users, such as on a weekend, to reduce the impact on your users.

To convert an existing domain to a single sign-on domain, follow these steps.

  1. Open the Microsoft Online Services Module.
  2. Run $cred=Get-Credential. When the cmdlet prompts you for credentials, type your Office 365 administration account credentials.
  3. Run Connect-MsolService -Credential $cred. This cmdlet connects you to Office 365. Creating a context that connects you to Office 365 is required before running any of the additional cmdlets installed by the tool.
  4. Run Set-MsolAdfscontext -Computer <AD FS 2.0 primary server>, where <AD FS 2.0 primary server> is the internal FQDN name of the primary AD FS 2.0 server. This cmdlet creates a context that connects you to AD FS 2.0.
    noteNote:
    If you have installed the Microsoft Online Services Module on the primary AD FS 2.0 server, then you do not need to run this cmdlet.
  5. Run Convert-MsolDomainToFederated -DomainName <domain>, where <domain> is the domain to be converted. This cmdlet changes the domain from standard authentication to single sign-on.
noteNote:
To verify that the conversion has worked, compare the settings on the AD FS 2.0 server and on Office 365 by running Get-MsolFederationProperty -DomainName <domain>, where <domain> is the domain for which you want to view settings. If they don’t match, you can run Update-MsolFederatedDomain -DomainName <domain> to sync the settings.
4. Next step

Now that you have installed the module and configured the domains to use single sign-on, you must set up Active Directory synchronization. For more information, see Active Directory synchronization: Roadmap. After you have set up Active Directory synchronization, see Verify and manage single sign-on.

Verify and manage single sign-on

As the administrator, before you verify and manage single sign-on (also called identity federation), review the information and perform the steps in the following articles to set up 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.

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 Office 365 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 Active Directory synchronization: Roadmap.

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

  1. On a domain-joined computer, go to the Microsoft Office 365 portal.
  2. Sign in using the same logon name that you use for your corporate credentials.
  3. 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>.”
  4. 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 Office 365 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 Office 365 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 Office 365 with your corporate credentials. It also validates some basic AD FS 2.0 configuration.

Back to top

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

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 2.0 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 2.0 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 Office 365

AD FS 2.0 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 Office 365 relying party trust. 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 and configure the Microsoft Online Services Module for Windows PowerShell for single sign-on.

View current settings

If at any time you want to view the current AD FS 2.0 server and Office 365 settings, you can open the Microsoft Online Services 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 2.0 server are consistent with those in Office 365. 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.

Back to top

Update trust properties

You must update the single sign-on trust properties in Office 365 when:

  • The URL changes: If you make changes to the URL for the AD FS 2.0 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 2.0 server. We recommend that you check Event Viewer regularly, at least on a weekly basis. To view the events for the AD FS 2.0 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 2.0, 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:By default, AD FS 2.0 generates a new token signing certificate, which is a self-signed 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 2.0.
    noteNote:
    You can configure when AD FS 2.0 generates the new token signing certificate. When the certificate rollover time comes, AD FS 2.0 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.
CautionCaution:
The token-signing certificate is critical to the stability of the Federation Service. In case it is changed, Office 365 needs to be notified about this change. Otherwise, the requests to Office 365 services will fail. For this reason, we recommend that you download and configure the Microsoft Office 365 Federation Metadata Update Automation Installation Tool, which will automatically monitor and update the Office 365 federation metadata on a regular basis so that any changes made to the token signing certificate in the AD FS 2.0 Federation Service is replicated to Office 365 automatically. For general information about managing certificates across the AD FS 2.0 federation server farm and Office 365, see Update trust properties.

To 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 Online Services Module for Windows PowerShell.
  2. Run $cred=Get-Credential. When this cmdlet prompts you for credentials, type your Office 365 administration account credentials.
  3. Run Connect-MsolService -Credential $cred. This cmdlet connects you to Office 365. Creating a context that connects you to Office 365 is required before running any of the additional cmdlets installed by the tool.
  4. Run Set-MSOLAdfscontext -Computer <AD FS 2.0 primary server>, where <AD FS 2.0 primary server> is the internal FQDN name of the primary AD FS 2.0 server. This cmdlet creates a context that connects you to AD FS 2.0.
    noteNote:
    If you have installed the Microsoft Online Services Module on the primary AD FS 2.0 server, then you do not need to run this cmdlet.
  5. Run Update-MSOLFederatedDomain -DomainName <domain>. This cmdlet updates the settings from AD FS 2.0 into Office 365 and configures the trust relationship between the two.

Back to top

Recover an AD FS 2.0 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.

noteNote:
If one of your AD FS 2.0 servers fails, and you have set up a high availability farm configuration, users will still be able to access the services in Office 365. 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 2.0 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 Office 365. For more information, see Support for Multiple Top Level Domains.
  1. Open the Microsoft Online Services Module.
  2. Run $cred=Get-Credential. When the cmdlet prompts you for credentials, type your Office 365 administration account credentials.
  3. Run Connect-MsolService -Credential $cred. This cmdlet connects you to Office 365. Creating a context that connects you to Office 365 is required before running any of the additional cmdlets installed by the tool.
  4. Run Set-MSOLAdfscontext -Computer <AD FS 2.0 primary server>, where <AD FS 2.0 primary server> is the internal FQDN name of the primary AD FS 2.0 server. This cmdlet creates a context that connects you to AD FS 2.0.
    noteNote:
    If you have installed the Microsoft Online Services Module on the primary AD FS 2.0 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 2.0 server and the properties in Office 365 to make sure they match. If they don’t match, run Update-MsolFederatedDomain -DomainName <domain> again to sync the properties.

http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652538.aspx