Configuring a multi-tenant federation with AD FS in a multi forest scenario with PowerShell

For weeks we have been working with Microsoft Premier Support and several product teams within Microsoft on a multi-forest to multi-tenant federation solution for Office 365 at two Dutch municipalites. There was some unclarity concerning supportabilty for our desired architecture at Microsoft, but as Microsoft calls it… this architecture qualifies for supportabilty. The fun part is, this scenario doesn’t require the provisioning of AD objects by hand, and allows you to use AADConnect to do this for you!

Now as the topology shows, we have two accounting forests where the AADConnect servers and Active Directory users reside. Each municipality has its own forest (forest B and forest C) and a configured a two-way full trust (forest-wide) to the resource forest (forest A). The Active Directory Federation Services (AD FS) farm resides in the resource forest (forest A).

Now the business requirement is having a single but high available AD FS farm in a resource forest, delivering an easy way of administering Identity Management for the long term. While at the same time delivering single sign-on functionality to all users working with Office 365 for each respected municipality.

Now the hard part here is the second federation to Office 365. The first federation configurated between the Microsoft Federation Gateway and your on-premises AD FS farm is pretty straight forward. And here is how it’s done:

  1. Log in to one of the AD FS Servers with an Domain Administrator account.
  2. You need to install the modules that are required for Office 365,
    1. Microsoft Online Service Sign-in Assistant for IT Professionals RTW
    2. Windows Azure Active Directory Module for Windows PowerShell (64-bit version
  3. Setup a Remote PowerShell connection to your tenant with an account having Global Administrator rights with this script;
    1. Import-Module MSOnline
      $O365Cred = Get-Credential
      $O365Session = New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection
      Import-PSSession $O365Session
      Connect-MsolService –Credential $O365Cred

Once connected to the first tenant in Office 365 on the AD FS server run this cmd-let, be sure to use the -SupportMultipleDomains $true parameter.

Convert-MsolDomainToFederated -DomainName contoso.com -SupportMultipleDomain $true

The –SupportMultipleDomain parameter is needed since this is required for the multi-tenant configuration to work. This paramater makes sure that the federation is built with the correct IssuerUri set to https://contoso.com/adfs/services/trust/ instead of the Federation Service namespace (generally sts.domain.com) when not using this parameter. This is a vital requirement later on. To double-check this you can check the Claim Rules in AD FS management, the third rule should containt this claim:

c:[Type == “http://schemas.xmlsoap.org/claims/UPN“] => issue(Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid“, Value = regexreplace(c.Value, “^((.*)([.|@]))?(?<domain>[^.]*[.].*)$”, “http://${domain}/adfs/services/trust/“));

Now this was the first municipality for which contoso.com is the federated domain. You can download the script at the bottom of this blog.

Wait for a minute -or five- untill the federation kicks in and let’s carry on implementing the second federation…the real fun part!

First of all we need to export the token-signing certificate from the AD FS farm by PowerShell:

$tokenRefs=Get-AdfsCertificate -CertificateType Token-Signing
$tokenBytes=$certRefs[0].Certificate.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Cert)
[System.IO.File]::WriteAllBytes(“c:\temp\tokensigning.cer”, $certBytes)

Next we can establish a new Remote PowerShell session to the second tenant with the script shared in step one of this post. After that we configure the second federation with this PowerShell script.

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“C:\temp\tokensigning.cer”)
$certData = [system.convert]::tobase64string($cert.rawdata)
$dom=”fabrikam.com”
$url=”https://adfs.ResourceForestFDQN.com/adfs/ls/&#8221;
$uri=”http://fabrikam.com/adfs/services/trust/&#8221;
$ura=”https://adfs.ResourceForestFDQN.com/adfs/services/trust/2005/usernamemixed&#8221;
$logouturl=”https://adfs.ResourceForestFDQN.com/adfs/ls/&#8221;
$metadata=”https://adfs.ResourceForestFDQN.com/adfs/services/trust/mex&#8221;
#command to enable SSO
Set-MsolDomainAuthentication -DomainName $dom -Authentication Federated -ActiveLogOnUri $ura -PassiveLogOnUri $url -MetadataExchangeUri $metadata -SigningCertificate $certData -IssuerUri $uri -LogOffUri $logouturl -PreferredAuthenticationProtocol WsFed

Now the most beautiful part of this second implementation is that it only configures endpoints on the Microsoft Federation Gateway, and doesn’t touch our on-premises configuration. The magic third claim we talked about earlier is all we need for it to work!

Once configured, the configuration of both tenants can be validated using the ‘Get-MsolDomainFederationSettings’ cmdlet. The only difference when comparing the tenant configuration should be the ‘FederationBrandName’ and the ‘IssuerUri’ values.

Download the PowerShell scripts right here!

 

 

 

Using the SimpleDisplayName attribute for Exchange and Exchange Online in Office 365 with PowerShell

So I came across a scenario where a organization doesn’t use the DisplayName field for external mailflow and has this disabled on their Remote Domain. In this scenario messages will use the SMTP address.

This setting is enabled by default and Exchange Server will use the DisplayName field for external mailflow. Now imagine the scenario you want your users to use a different and somewhat more catchy name for external parties and suppliers. A nice additional attribute can be used for this, which is the SimpleDisplayName attribute. By populating this object with for instance “John Doe – Microsoft Corporation” you will use this information for external parties, and keep using the already in-place DisplayName attribute for internal mailfow and these changes wont affect your Global Address List.

Now to enable Exchange Server, or Exchange Online to use start using the SimpleDisplayName object this needs to be enabled on your Remote Domain. This can be done via a simple PowerShell one-liner.

Set-RemoteDomain -Identity Default -UseSimpleDisplayName $true

Now once this is done Exchange will stop using the populated DisplayName field, and it will use the empty SimpleDisplayName field on userobjects. While being empty and not populated Exchange will use the SMTP Address for external mailflow, so next step will be populating all the empty fields  with the new desired values.

To accomplish this I use this handy PowerShell script which uses the FirstName and LastName attribute and adds a catchy company name behind it.

$users = Get-User -ResultSize Unlimited
foreach ($user in $users) {

$name=$user.DisplayName

$SDN=[string]::Concat($user.FirstName.Trim(), ” “, $user.LastName.Trim(), ” – Microsoft Corporation”)

Set-User $user.Identity -SimpleDisplayName $SDN

}

Intune device enrollment AD FS sign-in error “An error occurred. Contact your administrator for more information.”

Recently a client of mine added Windows Intune to their existing Office 365 subscription. The enablement of Intune requires users to install the Company Portal App on their mobile device which enrolls their device to your Office 365 organization.

In the process of enrolling a device it asks to login to Office 365. When a user tries to login with a federated Identity useraccount the login session will be redirected to your local AD FS sign-in page. However, when this is done from a mobile device it throws an error.

“An error occurred. Contact your administrator for more information.”

4-2-2016 14-17-03

Now once you have a look on the AD FS Admin eventviewer logging which can be found under the Applications and Services tree in the eventviewer MMC snap-in.

There you will find the error listed below:

Encountered error during federation passive request.

Additional Data

Protocol Name:
wsfed

Relying Party:
urn:federation:MicrosoftOnline

Exception details:
Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.InvalidAuthenticationTypePolicyException: MSIS7102: Requested Authentication Method is not supported on the STS.
at Microsoft.IdentityServer.Web.Authentication.GlobalAuthenticationPolicyEvaluator.EvaluatePolicy(IList`1 mappedRequestedAuthMethods, AccessLocation location, ProtocolContext context, HashSet`1 authMethodsInToken, Boolean& validAuthMethodsInToken)
at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.RetrieveFirstStageAuthenticationDomain(Boolean& validAuthMethodsInToken)
at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.EvaluatePolicy(Boolean& isLastStage, AuthenticationStage& currentStage, Boolean& strongAuthRequried)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthMethodsFromAuthPolicyRules(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthenticationMethods(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

Solution:

  1. Logon to AD FS server(s).
  2. Open the AD FS Management Console
  3. On the right hand side right click on the Authentication Policies folder
  4. Choose “Edit Global Primary Authentication…”
  5. In this menu you should check (enable) Forms Authentication on both Intranet and Extranet.

 

After enabling forms authentication on both sides the AD FS requests sent from mobile devices will be succesfully authenticated by the AD FS secure token service.

How to force a manual DirSync to Office 365 with AADConnect

Since the introduction of the renewed version of DirSync – called AADConnect nowadays – we have noticed great new functionalities. Depending upon the version that you are using to replicate Active Directory objects from on-premises Active Directory Domain Services to Office 365 Windows Azure Active Directory there are different commands that you will need to use.

Since June 2015 we have the release of AADConnect. As time of writing this blog the current version we’re on is 1.0.9125.0. Because the tool is under heavy development check out version history ocasionally on this website.

The default installation folder of AADConnect is C:\Program Files\Microsoft Azure AD Sync\Bin and this is where you can initiate a full or delta sync to Office 365.

deltasync_aadconnect

  1. Open PowerShell with administrative priviliges.
  2. Change the directory to folder containing the tool with the cmd-let cd “C:\Program Files\Microsoft Azure AD Sync\Bin” 
  3. To initiate a Full Syc to Office 365 run the cmd-let .\DirectorySyncClientCmd.exe initial staging 
  4. For a incremental or delta sync the cmd-let .\DirectorySyncClientCmd.exe delta 

Now be patient for 5 minutes for the new and edited objects to show up on the Office 365 portal. Depending on the amount of objects in ADDS and assigned server resources this action can take up to 15 minutes.

Add Office 365: Exchange Online e-mail address on every mailbox with PowerShell

When carrying out hybrid Exchange deployments to Office 365: Exchange Online one of the challenges I commonly face is the disablement of the e-mail address policy on stacks of mailboxes. To handle mailflow in a hybrid scenario every mailbox needs an e-mail routing address matching the tenant e-mail domainname (contoso.mail.onmicrosoft.com). Now this requirement is covered by running the Hybrid Configuration Wizard in stage 8: configuring mailflow. This phase simply adds the new e-mail routing address to the “Default Policy”.

This new configuration automatically adds the new e-mail address on every mailbox which has the e-mail address policy enabled on it. Now this is where the challenge appears. What to do when a lot of mailboxes within your Exchange organisation do not have the e-mail address policy enabled?

The easiest fix is enabling the e-mail address policy on every mailbox with a simple one-liner of PowerShell right? Well in a lot cases this solution doesn’t suffice because this would mess up naming conventions. A lot of IT departments knowingly disabled the policy on mailboxes over the years to configure the desired e-mail address by hand for their end-users.

To automatically configure or add the new e-mail address on every mailbox without enabling the e-mail address policy I use this great PowerShell script.

<#
.SYNOPSIS
The Add-O365MailAddress script is used to add your Office 365 e-mail address on every mailbox within your Exchange Organisation.

.DESCRIPTION
The Add-O365MailAddress script is used to add a new Office 365 e-mail address on every mailboxes where it is currently not present.

Make sure script execution is set to unrestricted by running “Set-ExecutionPolicy -ExecutionPolicy unrestricted -Force”

Please note that this script is only tested on Windows Server 2008 R2 and higher servers which have the Exchange Management Shell installed.
#>

$mailbox = Get-Mailbox -ResultSize Unlimited -Filter {EmailAddresses -notlike “*@contoso.mail.onmicrosoft.com*”}
foreach ($user in $mailbox) {

$alias=$user.alias

$email=$alias + “@contoso.mail.onmicrosoft.com”

Set-mailbox $user.Identity -EmailAddresses @{add=$email}
}

Export-Csv -Path c:\temp\mailboxes_output.csv

 

DOWNLOAD HERE

The script iterates trough every mailbox in the Exchange Organisation. Every mailbox which does not have a present Office 365 routing address (contoso.mail.onmicrosoft) is put in the pipeline. Next the script will add the new e-mail address on every selected mailbox which is required for for Office 365 hybrid mailflow.

Change explicit User Principal Names to match Office 365 domain suffix

#MICROSOFT #OFFICE365 #EMS #INTUNE #EXCHANGE #AZURE #IDENTITY

Most Enterprise Office 365 clients will use Active Directory Federation Services and Windows Azure Active Directory Sync, also known as DirSync for Single Sign-On functionality with Office 365.

Standard AD FS will use the on-premises UPN to access services in Office 365. Therefore Microsoft advises to make sure User Principal Name suffixes and e-mail adress suffixes match to make life simpler. Most ADS domains still use an internal routable domainname for instance contoso.local. However when implementing AD FS with Office 365 it permitted to have an “internet routable” domain suffix for instance contoso.com.

The best solution for this before implementing and running a DirSync is to create a new User Principal Name suffix to match your Office 365 domain suffix. This can be done by adding a new UPN suffix by going to:

  1. Open Active Directory Domains and Trusts
    2. Right click on the top level of the tree in…

View original post 116 more words

Change explicit User Principal Names to match Office 365 domain suffix

Most Enterprise Office 365 clients will use Active Directory Federation Services and Windows Azure Active Directory Sync, also known as DirSync for Single Sign-On functionality with Office 365.

Standard AD FS will use the on-premises UPN to access services in Office 365. Therefore Microsoft advises to make sure User Principal Name suffixes and e-mail adress suffixes match to make life simpler. Most ADS domains still use an internal routable domainname for instance contoso.local. However when implementing AD FS with Office 365 it permitted to have an “internet routable” domain suffix for instance contoso.com.

The best solution for this before implementing and running a DirSync is to create a new User Principal Name suffix to match your Office 365 domain suffix. This can be done by adding a new UPN suffix by going to:

  1. Open Active Directory Domains and Trusts
    2. Right click on the top level of the tree in the left pane and select properties
    3. Add the new internet routable UPN suffix e.i. contoso.com

Next step is to change the explicit User Principal Names for all the designated user objects in Active Directory which you plan to synchronize to Office 365. The easiest way to do this is with the help of allmighty PowerShell.

I wrote this easy one-liner which allows you to target a specific OU in Active Directory. Don’t forget to use the Active Directory Module for PowerShell.

Get-ADUser -Filter * -SearchBase ‘OU=Users,DC=fabrikam,DC=local’ -Properties userPrincipalName | foreach { Set-ADUser $_ -UserPrincipalName “$($_.samaccountname)@contoso.com”}

After succesfully running the cmd-lets you will notice the new UPN suffix is configured for the targeted user objects in ADS.