Well then, here we are in part three already!  Previously we:

Installed ADFS 2012 R2 For Office 365 in part 1

Installed ADFS 2012 R2 Proxy For Office 365 in Part 2

Now we want to change the Office 365 domain to be a federated domain.  As discussed in part 1, this means that all of the users who authenticate using this domain will become a federated identity and the on-premises ADFS server is responsible for authenticating these requests.

Update 20-8-2014: Added comment for SupportMultipleDomain switch for the Convert-MSOLDomainToFederated cmdlet.

Importance Of ADFS When Office 365 Relies Upon It

Before we discuss the integration of Office with the on-premises ADFS infrastructure, let’s just again be clear on the criticality of ensuring that ADFS is available when the Office 365 domain is set to use ADFS authentication.  For whatever reason if the ADFS infrastructure is unavailable, then Office 365 cannot complete the authentication process and thus users cannot get access to Office 365.  This will cause a service impacting outage that will require resolution from you, not Microsoft’s online services team.

For this reason, unless you really need to leverage ADFS please review the DirSync password synchronisation feature in the recent DirSync builds.

Apologies if I sound pessimistic, but I don’t want to obviate the requirement for ADFS redundancy!

ADFS in Azure

On the topic of ADFS redundancy one option is to also host a portion of your ADFS infrastructure in Azure.  This is a perfect solution if you do not have sufficient capacity in your current datacentre, or your datacentres are located in close proximity of each other and a major incident would take both of them down.

There is a whitepaper published for this exact scenario. Please check this link. The documentation covers three main scenarios to meet the situations discussed above:

• Scenario 1: All Office 365 SSO integration components deployed on-premises. This is the traditional approach; you deploy directory synchronization and Active Directory Federation Services (AD FS) by using on-premises servers.
• Scenario 2: All Office 365 SSO integration components deployed in Windows Azure. This is the new, cloud-only approach; you deploy directory synchronization and AD FS in Windows Azure. This eliminates the need to deploy on-premises servers.
• Scenario 3: Some Office 365 SSO integration components deployed in Windows Azure for disaster recovery. This is the mix of on-premises and cloud-deployed components; you deploy directory synchronization and AD FS, primarily on-premises and add redundant components in Windows Azure for disaster recovery.

This is an example of hosting ADFS in Azure for DR purposes:

AD FS is supported for deployment on Azure Virtual Machines, but there are AD FS best practices that require technologies beyond what AD FS offers itself, such as load balancing/high availability.  In addition to this please also consider the pricing for running this IAAS.  Read through the deployment caveats in the ADFS Azure documentation above and also the additional discussion points here.

Updating ADFS

Back to the business at hand – updating Office 365 so that it now uses your on-premises ADFS server!

We will run the below on a domain joined server on the corporate network.  This has the Windows Azure Active Directory PowerShell Module and the Microsoft Online Sign-In Assistance (SIA) installed.  Let’s launch the WAAD PowerShell module.  For reference the remote ADFS server is Tail-CA-STS.TailspinToys.ca.

For other WAAD management tasks, take a peek at Manage Azure AD using Windows PowerShell page.

Using Connect-MsolService let’s connect to our WAAD instance.  Provide a set of global admin credentials:

We can see the current status of the domains within this tenant.  the Get-MsolDomain cmdlet will show the domains, and we are interested in the first domain – “Tailspintoys.ca”.

Before we can execute the Convert-MsolDomainToFederated cmdlet, we need to also a hook into the local ADFS server (not the ADFS proxy) so that we can configure it.

There is a word of warning here, as chances are that you will see this lovely screen that features copious red text.

Set-MsolADFSContext : The connection to <ServerName> Active Directory Federation Services 2.0 server failed due to invalid credentials.

Active Directory Federation Services 2.0 server failed due to invalid credentials" style='background-image: none; padding-top: 0px; padding-left: 0px; display: inline; padding-right: 0px; border-width: 0px;' alt='Set-MsolADFSContext : The connection to Active Directory Federation Services 2.0 server failed due to invalid credentials' src='/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-91-09-metablogapi/image_5F00_thumb_5F00_62F9607B.png' border='0' />

This is caused by Remote PowerShell not being enabled on the remote  ADFS server.  This is an issue that is present on ADFS 2012 and ADFS 2012 R2 servers amongst others.  Thankfully it is quite easy to fix, by running the below on the ADFS server:

Enable-PSRemoting 

Once Remote PowerShell has been enabled, we can then connect to the ADFS server using the Set-MsolADFSContext cmdlet. Like the other MSOL cmdlets, this one is as unforgiving.  If you forget to explicitly use the required parameters the MSOL cmdlets typically do not prompt like the Exchange cmdlets do.  Because of this I have a habit of always specifying every option and not relying on PowerShell to prompt for required options that were missed. 

Once we have connected to the ADFS server, we use the Convert-MsolDomainToFederated cmdlet to convert the Office 365 domain from Managed to Federated.

Set-MsolADFSContext -Computer Tail-CA-STS.tailspintoys.ca

Convert-MsolDomainToFederated -DomainName tailspintoys.ca

Update 20-8-2014:  Andy pointed out in the comment that there is an area of concern to be noted here for customers that have multiple top level domains.  Back with ADFS 2.0 customers with multiple top level UPNs had to deploy separate ADFS instances for each domain suffix.  A rollup was added to assist with this and the SupportMultipleDomain switch.   Please see here for more details if you have multiple sign on domains.

Once converted, we check to see if the change applied:

Yes it did!  The domain is now Federated.

The full properties of the domain now look like so:

Please be aware that it can take up to two hours for domain authentication changes to apply.  Go drink a vat of coffee or play some flappy birds!

Testing Access To Office 365 OWA

To test that we are being authenticated to Office 365 OWA via ADFS, let’s see what happens now that the domain has been converted to federated.

Open IE, and navigate to https://outlook.com/tailspintoys.ca  this is the neat shortcut that we can use to access OWA.  Change the domain name to match your own.

When we go to  the browser is redirected to our on-premises ADFS server, at this URL:  https://adfs.tailspintoys.ca/adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=wa%3Dwsignin1.0%26rpsnv%3D3%26ct%3D1398824668%26rver%3D6.1.6206.0%26wp%3DMBI_KEY%26wreply%3Dhttps:%252F%252Fwww.outlook.com%252Fowa%252F%26id%3D260563%26whr%3Dtailspintoys.ca%26CBCXT%3Dout

We then sign in to the on-premises ADFS server:

ADFS authenticates us, assuming that the password is not fat-fingered, and this authorises Office 365 to let us access OWA:

The astute reader will notice that IE in-private mode has been used.  This keeps my testing separate from the other IE Instances running on my laptop.

One thing to note, when testing this connectivity please do so on a regular client machine that has the proper access to the Internet and where the browser is not totally locked down.  In the below example on a Server 2008 R2 SP1 server, when browsing to outlook.com/tailspintoys.ca the user experience is very different from the screenshots above.

The user will get logged on, but it can be disconcerting if you are expecting the sexy looking ADFS screen and you get an auth prompt instead…..

Testing Office 365 SSO

Chances are you will have use the TestExchangeConnectivity.com site to test and troubleshoot on-premises issues.  The tool has been expanded as now we can also use it to test and diagnose Office 365 issues.

KB 2650717  How to diagnose single sign-on (SSO) logon issues in Office 365 by using Remote Connectivity Analyzer  discusses using the tool to validate SSO.

BONUS TIP – if you get tired of typing that long URL to get to the site, try http://exrca.com

Viewing the SSO Shuffle

Using the IE developer tools, that are accessible by pressing F12 we can see the traffic flow that the browser has taken to reach the sites involved.  You will want to click to enlarge the below.

Note that we went to the following URLs.  Can you work out why there are three outlook.com ones at the top?

Repairing Office 365 Federated Domain

As discussed in KB 2647048, there are situations that will require the Office 365 domain federation to be repaired.

• 2523494 (You receive a certificate warning from AD FS when you try to sign in to Office 365, Windows Azure, or Windows Intune
• 2618887 Error when you try to configure a second federated domain in Office 365: "Federation service identifier specified in the AD FS server is already in use."
• 2713898 "There was a problem accessing the site" error from AD FS when a federated user signs in to Office 365, Windows Azure, or Windows Intune 
• 2647020 "Your organization could not sign you in to this service" error and "80041317" or "80043431" error code when a federated user tries to sign in to Office 365
• 2707348 "Metadata Exchange (MEX) document received from AD FS contains an unknown WS-Trust version" error after you run the MOSDAL Support Toolkit
• The Federation Service name in AD FS is changed. For more info, go to the following Microsoft website: AD FS 2.0: How to Change the Federation Service Name

For example, you may find yourself running this:

Additional Reading

I love this KB as it links to so many other articles that are relevant and introduce many of the issues that can arise with an ADFS deployment.

KB 2647048 -- How to update or to repair the configuration of the Office 365 federated domain 

The PFE Platform blog have some great ADFS content, amongst other things.  Just don't propose to Charity via the comment system please!

How to Build Your ADFS Lab on Server 2012 Part 1

Introduction to Active Directory Federation Services (AD FS) AlternateLoginID Feature

Upgrading ADFS to Server 2012 R2

FAQ on ADFS - Part 1

Finally the TechNet Wiki has the ADFS content section.

ADFS Content MAP

Cheers,

Rhoderick

In part one we installed the ADFS server on our corporate network, and tested that it was working.

Now we need to make the ADFS infrastructure available to the Internet in a secure fashion, so that Office 365 will be able to contact the ADFS proxy to authenticate user requests.

In part three we will add the ADFS infrastructure to the Office 365 configuration,

Planning And Prerequisites

Install And Configure ADFS Proxy OS

In this installation, the ADFS proxy server will be placed into the DMZ, and installed as a workgroup machine since the Tailspintoys organisation does not possess a separate management forest in the DMZ.  Ensure the machine is built as per your standard build process, is secured and all Microsoft updates are installed.

You will want to install the April 2014 Windows 2012 R2 update to light up additional pieces of ADFS functionality, but we will save that for a later blog post.  If you do want to take a peek at this now, the PFE Platform folks are rocking it over here – please subscribe to their RSS feed too!

Install  And Verify Certificate

As discussed in part one, you will need a certificate from a trusted third party.  Ensure that you check with the CA to ensure that you are able to install the certificate onto multiple servers as this is blocked in some license agreements.  This is something that you must check directly with the CA.

If you are allowed to install the certificate from the ADFS server, then this simplifies matters else you will require an additional certificate.  The name must match the ADFS namespace that you selected through the ADFS design process.

Name resolution

Since the ADFS server will be in  a network that may not have access to the internal DNS zone information, ensure that it is able to resolve the ADFS namespace to the internal ADFS server.  A swift update to the local hosts file may suffice, just remember to add this to your build documentation.

External DNS Record

Create external DNS record for the ADFS proxy server.  This A record will exist in the external DNS zone of you are using split DNS.  In the Tailspintoys enterprise (cough, cough this lab) the internal DNS zone is held on AD integrated DNS zones.  The external zone is at a commercial ISP, so the external DNS record was created at the commercial ISP so it resolves to the external IP of the ADFS proxy when I am at Starbucks.

Open Firewalls

Having the external DNS record point to the ADFS server’s external IP address will not allow traffic to flow unless the firewalls are configured to do so.  In enterprises the ADFS proxy server will be installed into a DM so there will be an internal and external firewall.  Both must be opened to allow SSL traffic over TCP port 443.  In addition to this the ADFS server will also need access to the CRL distribution points on the Internet to verify certificate validity.

Exchange administrators should be used to this now as they have see Exchange updates take a long time to install on Exchange servers do not have access to crl.microsoft.com.  In the case of ADFS, the server should be able to hit the CRL of external CAs.

Installing Web Application Proxy

Let’s fire up the Add Roles Wizard from server manager!

As noted in the previous post, there is no longer a separate ADFS proxy role in Windows 2012 R2.  The Remote Access feature provides VPN, Direct Access and Web Application Proxy (WAP) functionality.  It is the latter that we need to install. 

Select Remote Access and let’s go find the droids we are looking for…

Unless you want to add any features, like telnet * for troubleshooting purposes later, click next.

The Remote Access role selection process starts.  Unlike in days of old when installing a feature would install all of the bits, and by extension potential vulnerabilities, Windows now wants to only install the bare minimum.  This is a paradigm shift compared to the early days of IIS where it would install everything and then you have to spend time stripping stuff back out.  Index extension attack anyone?

In our case we just want to install the Web Application Proxy role service, so select that and click next

Confirm the choice, and then install.

Once the necessary WAP role services are installed, we are then able to launch the Web Application Proxy Wizard to configure WAP.

Configure Web Application Proxy

We need to configure the WAP proxy with the necessary information so that it knows it will be publishing our internal ADFS server and how to access ADFS.

On the screen below is where most configuration issues arise with this process.  What a lot of folks do is interpret the Federation service name as the display name of the ADFS server.  That will not get you very far unfortunately…

The federation service name field does NOT want you to enter the display name of the ADFS server farm.   The display name in the previous example was “Tailspintoys STS”. and this can been checked by looking in the ADFS console

If you look closely at the ADFS properties, the federation service name is actually the FQDN of the service.  In our case this is adfs.tailspintoys.ca so let’s enter that along with credentials on the ADFS server so we are able to access ADFS.

In the same way that we require a SSL certificate on the ADFS server, the same is true on the ADFS proxy as clients will establish SSL sessions to this machine which will then be bridged to the internal ADFS server.

Since the certificate was installed and verified as part of the preparatory work, we select it and move on.

Verify the details, and click configure.

The wizard starts to configure the ADFS proxy

And shortly thereafter completes!

Verifying ADFS Proxy Installation

At this time we should have a functional ADFS proxy server that is able to provide internet based users with access to our ADFS server’s authentication services.  But as always, we need to test!

To open up the Remote Access management console, use the Remote Access Management shortcut in administrative tools.

If you have immediately launched this after installing the ADFS proxy it may take a few seconds or a refresh to show up.  The other top tip is not to look for a published web app.  Remember that WAP can be used to publish various applications to the internet, but in this case we are just wanting to use the base ADFS proxy components.

To check that the ADFS proxy is running, click onto the Operational Status in the left hand tree

Selecting the operational status, will then show how the ADFS proxy is currently running.  You can also jump to Perfmon or Event Viewer from this node.

Should the ADFS proxy have an issue the console will light up like a Christmas tree.  In this case I deliberately stopped the “Active Directory Federation Services” service on the ADFS proxy, please click to enlarge the image:

And as expected with the ADFS proxy crippled users will not be able to authenticate, even if they try an alternative browser!

Even though the Windows service is name the same on both the ADFS server and the ADFS proxy, note that the executable path is different:

Verify ADFS Proxy Configuration

In event viewer on the ADFS proxy, open up the application and services logs and check that the proxy is able to retrieve it’s configuration from the ADFS server.  This can be seen here, click to enlarge:

With the full event details shown here:

Verify Federation Service Metadata

Using the same URL as before, open Internet Explorer and navigate to your ADFS server’s federation metadata URL.

This will be something like the below, just change the FQDN to match your environment.

https://adfs.tailspintoys.ca/federationmetadata/2007-06/federationmetadata.xml

https://sts.contoso.com/federationmetadata/2007-06/federationmetadata.xml

The intent here is to ensure that we are able to get to the site externally.  If you are not able to see the ADFS text rendered in the browser, start with ensuring that the firewalls are not dropping traffic.

Verify ADFS Sign-In Page

Browse to the ADFS sign-in page and test that you are able to authenticate.

The URL will be similar to the below, again change the FQDN to match your organisation’s.

https://adfs.tailspintoys.ca/adfs/ls/idpinitiatedsignon.htm

https://sts.contoso.com/adfs/ls/idpinitiatedsignon.htm

You should see the below, and be prompted to sign in:

(Note that I did not full screen the window before grabbing capture else it would be too small)

Clicking the Sign In button will prompt for credentials:

If you successfully authenticate then you will be rewarded with this stellar screen:

And if are unable to type a password (like me doing demos) then you will get this less than stellar result:

In part three we will finish this off, and instruct Office 365 to leverage the shiny ADFS infrastructure to authenticate users.

Cheers,

Rhoderick

* – Not having telnet client by default always grates.  In the same way that explorer file options are always set to hide the good stuff like file extensions, system files and the ilk.

When discussing and reviewing Office 365 with customers, I wanted to have a series of posts to illustrate the steps involved when deploying Office 365.   In the burgeoning drafts folder ADFS was at the top, so that got finished first!

The act of deploying and configuring ADFS 2012 R2 for Office 365 will be broken down into three separate blog posts

1. Install ADFS (this post)
2. Install ADFS Proxy
3. Leverage ADFS with Office 365

Identity, Identity, Identity

The IT security landscape keeps evolving.  One of the recent changes is a move away from ACLs on files in the NTFS file system to an access control system that is based on claims.  Claims based authentication is an industry standard security protocol to authenticate users.  This is the underlying WS-* standards that describe the usage of Security Assertion Mark-up Language (SAML) tokens.  Claims based auth requires these tokens, and by extension an entity that can issue the token.  This is the Secure Token Service (STS).  The STS server can be based on Active Directory Federation Services (ADFS) or other platforms that provide this service.

ADFS lights up one of the three options for Office 365 identity management, which is option #3 in the below list:

1. Cloud Identity – users are created, and managed,  in Windows Azure Active Directory (WAAD).  No connection to any other directory.  This is the simplest model as there is no integration to any other directory.  Each user has an account created in the cloud which does not synchronise anywhere else.  Note that you will still typically need additional on-premises credentials to gain access to a local workstation and local resources.
2. Directory Synchronisation – Users are created and managed in the on-premises directory and get synchronised up to Office 365 so they can access Office 365 resources.  Typically this means running the DirSync appliance, or in some cases FIM with the Windows Azure Active Directory Connector.  The newer builds of DirSync allow for the user’s password hash to be synchronised up to Office 365.  Note this does not say clear text password.    This allows user’s to logon to Office 365 using the same credentials as on-premises with no additional infrastructure.
3. Federated Identity – Federation relies on directory synchronisation so that WAAD is populated.  When the authentication request is presented to Office 365, the service will then contact the on-premises ADFS infrastructure so that AD is responsible for authenticating the request.

ADFS is the primary choice for customers who want to use federated identities with Office 365.  In addition to this there are a variety of qualified third party identity providers that can be connected with Office 365 to provide the necessary plumbing for federation.  The shortcut URL aka.ms/SSOProviders  links to the ‘Works With Office 365’ Identity program, and lists the identity providers that have been qualified with Office 365.  Please read the notes on the TechNet page with regards to the testing and support aspects of these services.

Some customers will use these services as they do not wish to invest in a fault tolerant and geographically dispersed ADFS implementation.  The availability of ADFS is a key discussion point when discussing federation.  For whatever reason if the ADFS infrastructure is unavailable, then Office 365 cannot complete the authentication process and thus users cannot get access to Office 365.

In addition since DirSync now replicates the user’s hashed password to WAAD, some customers now use DirSync to provide Same Sign On / Single Sign On (SSO).  DirSync version 1.0.6385.12, which was released in May 2013, and latter builds provide the ability to synchronise passwords.  DirSync can be downloaded here, and the TechNet Wiki has details on the release history.   When running the configuration wizard with this release you will get the shiny “Password Synchronization” window:

This is worthwhile to mention as there is still a perception that ADFS is a hard requirement to get SSO.  That is soooooooooooo  Q1 2013!

Anyway, I digress let’s get back to ADFS…..

We shall look at installing ADFS 2012 R2 since there are numerous compelling features in this release!

What’s New And Improved In ADFS 2012 R2

The quick answer is a lot!  Some examples include:

• IIS dependency removed
• Single server installation option removed and now have single farm install (recommended to install a farm always in prior release anyway)
• Separate ADFS proxy role removed.  ADFS proxy now based off Web Application Proxy (WAP), and is used to publish the ADFS server to the Internet.  WAP can publish many other applications, not just ADFS.
• ADFS extranet lockout – ADDS account lockout protection on the ADFS proxy
• Access control based on network location to control user authentication to ADFS

There are many others, but check here for them since we are focussing on Office 365 usage for ADFS.

Note that you will not see me  call this release ADFS 3.0.  Its full and proper name is  ADFS 2012 R2.  for reference here are the older versions and what some folks call them:

Update 5-5-2014:    Please also see this post on exploring ADFS 2012 R2 Extranet Lockout protection. 

Update 29-5-2014:  Please also review update 2948086 Update that improves AD FS proxy and STS reliability in Windows Server 2012 R2 when multiple clients sign in.

Update 9-9-2014:    For the other posts on ADFS, please view this tag cloud.

Planning And Prerequisites, And Other Fun Details

Prerequisites

The prerequisites are listed on TechNet.  Of course before jumping into the install the installation needs to be planned.

ADFS Role Planning

The ADFS role should be deployed within the corporate network, and not in the DMZ.  The ADFS proxy role is intended to be installed into the DMZ.

The default topology for Active Directory Federation Services (AD FS) is a federation server farm, using the Windows Internal Database (WID), that consists of up to five federation servers hosting your organization’s Federation Service. In this topology, AD FS uses WID as the store for the AD FS configuration database for all federation servers that are joined to that farm. The farm replicates and maintains the Federation Service data in the configuration database across each server in the farm.

Since the availability of Office 365 relies upon the availability of ADFS when the domain is federated there is a strong recommendation to have at least two ADFS servers with a redundant ADFS proxy infrastructure.

Please review the design guidance on TechNet.

ADFS Service Account

We can now use a standard service account or a Group Managed Service Account in ADFS 2012 R2.

In this case since the KDS root key was not configured, lets leverage a standard service account.

The installation process should set the required Service Principal Names (SPN) on the account.

ADFS Namespace

Select what name you are to use to access ADFS.  Typically this is along the lines of:

sts.wingtiptoys.ca

adfs.tailspintoys.ca

Note that this is the namespace for the ADFS service.  Since we will be using Kerberos to access ADFS internally, there must be a Service Principle Name (SPN) registered for this name.  This will be associated to the service account, and since SPNs operate in the “Highlander – there can be only one!” mode you do not want to duplicate the SPN on the ADFS server by naming the computer the same as the ADFS namespace.

You also want to discuss what display name should be chosen, as this will be visible to users.

Certificates

Since ADFS leverages SSL, we need to have a SSL certificate.  You could try three options, but only one will work:

1. Self-signed certificate
2. Certificate issued from internal PKI
3. Certificate from 3rd party public CA

Office 365 needs to see a valid Service Communication Certificate on your ADFS infrastructure, so you are going to have to buy a certificate from a public CA.  Office 365 will not trust a service communication certificate that is either self-signed or from your internal CA, which results in tears.  We can use self-signed certificates for the Token Decrypting and Token Signing Certificate.  These are separate from the service communication cert.

Please follow the documentation from your chosen CA to request, install and complete the certificate.  The steps required vary from vendor to vendor and also over time.  Make sure you are not missing any updated intermediate certificates!  How would you know?  Follow their  process!!

For the purposes of this post we shall deploy the initial ADFS server, and in the future add another ADFS server for redundancy.

Installing ADFS On Windows Server 2012 R2

After starting up server manager’s add roles and features wizard, select Active Directory Federation Services, then click next. 

We don’t need to add any additional features.  Remember that the IIS dependency was removed in ADFS 2012 R2.

Clicking next takes us to the ADFS splash screen.  Note that it helpfully tells us that the specific ADFS proxy role has been removed in Windows 2012 R2 and how to go about installing it.  Shame I missed that the very first time  I ran this, and could not find the old school ADFS Proxy role…

Clicking next will then install the necessary bits.

Bits are being shuffled around…

Shuffling has been completed, and the installation is complete.   You can launch the ADFS configuration wizard from here, or alternatively if this window is closed it can be launched from server manager.

Before starting the ADFS configuration wizard I already installed my 3rd party certificate and tested that is was correctly installed.

Additionally a service account called ADFS-Service  was also pre-created.

The wizard also states that you must have access to Domain Admin (DA) credentials!

Note that you are only given an option to either make a new ADFS farm or add this box to an existing farm.  This saves the painful issue from older ADFS builds, where ADFS was not installed into a farm you were then unable to easily the add the second ADFS server for redundancy.

Provide your domain admin credentials.

We need to select the SSL certificate that we will use and also provide the ADFS name we selected in the design process.

In this case the name is adfs.tailspintoys.ca   -- note that there is no concept of an InternalURL or ExternalURL for the ADFS namespace.  Clients will use the same name on the intranet and internet to locate ADFS.  Thus split DNS will make life simple!

Provide your chosen display name, and click next.

As mentioned earlier it is possible to use a GMSA as the ADFS service account.  GMSA will automatically update the service account’s credentials and administrators will also be oblivious as to its password.

In this case a standard service account was used.

Select the database configuration as per the design.

The Tailspintoys corporation will use WID.

Review the options, and when happy pull the trigger!

For reference the PowerShell script is shown here:

#
# Windows PowerShell script for AD FS Deployment
#

Import-Module ADFS

# Get the credential used for the federation service account
$serviceAccountCredential = Get-Credential -Message "Enter the credential for the Federation Service Account."

Install-AdfsFarm `
-CertificateThumbprint:"5804746A7980C8682FBF408D48EF6C3B02A5ZORG" `
-FederationServiceDisplayName:"Tailspintoys STS" `
-FederationServiceName:"adfs.Tailspintoys.ca" `
-ServiceAccountCredential:$serviceAccountCredential

The ADFS pre-requisite checks are done, and we can proceed to the configuration:

One coffee later, we have a shiny new ADFS server – whoo!!

We are not quite done yet, and there a couple of additional things to do!

Next Steps

ADFS Update(s)

Update 29-5-2014:  Please also review update 2948086 Update that improves AD FS proxy and STS reliability in Windows Server 2012 R2 when multiple clients sign in.

Update 11-12-2014:  The above update 2948086  is now bundled in this rollup: May 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2

Update 16-7-2014:  Other updates you may want to review are at the bottom of this post.

When multiple clients (over 200 clients) try to sign in by using an Active Directory Federation Services (AD FS) proxy, the AD FS proxy consumes 100% usage of the CPU. In this situation, the AD FS proxy performance is slow, and causes a delay that exceeds 10seconds. This also causes STS to work under minimal load. Therefore, STS rejects the requests or serves only 5 to 10 requests per second.

DNS A Record

We must create the DNS record  for the ADFS instance.  This maps to the ADFS namespace that we previously planned.  Create this A record in your internal DNS infrastructure.

Once the DNS record has been created an propagated ensure that it resolves correctly.

One thing to mention here, if you create a CNAME and point that to the server hosting ADFS chances are that you will run into a never ending authentication prompt situation.

In the below example the ADFS namespace is called adfs.tailspintoys.ca and a CNAME was used to direct traffic to the ADFS server called tail-ca-sts.tailspintoys.ca.    This will likely cause the client to obtain a Kerberos ticket for the incorrect name.

The easiest way to stop this is to use  a regular A record, like so:

There is also an option contained in KB 911149  that some folks have mentioned.

Additional Steps

This topic covers additional steps to configure AD FS after you install the first federation server, including:

• Opening the ADFS Management Snap-in
• Configuring Name Resolution for AD FS Services
• Adding nodes to the farm
• Adding a Web Application Proxy
• Enabling Device Registration Service

For more information about how to deploy AD FS, see How to deploy AD FS in Windows Server 2012 R2.

Verify Federation Service Metadata

Open Internet Explorer and navigate to your ADFS server’s federation metadata URL.

This will be something like the below, just change the FQDN to match your environment.

https://adfs.tailspintoys.ca/federationmetadata/2007-06/federationmetadata.xml

https://sts.contoso.com/federationmetadata/2007-06/federationmetadata.xml

The result should show this:

Verify ADFS Sign-In Page

Browse to the ADFS sign-in page and test that you are able to authenticate.

The URL will be similar to the below, again change the FQDN to match your organisation’s.

https://adfs.tailspintoys.ca/adfs/ls/idpinitiatedsignon.htm

https://sts.contoso.com/adfs/ls/idpinitiatedsignon.htm

You should see the below, and be prompted to sign in:

Depending upon how IE is configured you will either be prompted to provide credentials or be automatically signed-in.

If you want to have users be automatically signed-in then configure your browser settings to trust the federation server role by adding your federation service name (for example, https://adfs.tailspintoys.ca) to the browser’s local intranet zone. This will enable seamless sign-in using Windows Integrated Authentication.

Once we are happy that the ADFS instance is functioning appropriately we can then move onto installing the ADFS proxy role.

This will be covered in a separate post, to prevent this one getting too long!

Cheers,

Rhoderick

In the smelly MEC 2014 man purse, there was  a shiny Exchange 2103 SP1 architecture poster.  The MEC attendees were the first ones to get the update to the older Exchange 2013 RTM poster, which is now published for everyone! 

I created a deep zoom of the poster so that it is easy to scroll around on phones and tablet devices.  Click the toggle  button at the bottom right hand corner to enter full screen mode. 

Use these controls to zoom in on touch devices rather than the native pinch zoom, else the text will not be readable as you will not be zooming just stretching the currently rendered image.   If you have a mouse and scroll wheel that can also be used to zoom in and out.  Pressing ‘Esc’ will exit the zoom, and return to the blog.

You can also directly download the Exchange 2013 SP1 poster from the Microsoft Download Center.

The Exchange architecture posters have been a very popular wallpaper choice for messaging engineers to adorn their cubicle walls with!  Over the years there have been multiple iterations of the poster, and for reference the older ones are here: 

• Exchange 2013 RTM Architecture Poster
• Exchange 2010 Architecture Poster 
• Exchange 2010 Hub Transport Architecture Poster
• Exchange 2007 Architecture Poster 

Cheers,

Rhoderick

The other Exchange 2013 tips of the day posts can be found here:

Exchange 2013 Tip Of The Day – 1   To 25

Exchange 2013 Tip Of The Day – 26 To 50

Exchange 2013 Tip Of The Day – 51 To 75

To obtain the listing below, the following command was used:

$Int = 76;While ($Int -le 100){Get-Tip $Int;  Write-Host; $Int+=1}

Tip of the day #76:

To get a list of all parameters available for a cmdlet, type:

(Get-Command <Cmdlet Name>).Parameters | ft key

For example, to get all parameters for the New-TransportRule cmdlet, type:

(Get-Command New-TransportRule).Parameters | ft key

Tip of the day #77:

Did you know that you need to use the AssembleMessage script when exporting messages from a queue? For example, if you want to export the message with message ID 1234 from the contoso.com queue on server Mailbox1, you need to run the following command:

Export-Message -Identity Mailbox1\contoso.com\1234 | AssembleMessage -Path "C:\ExportedMessages\Message1234.eml"

Tip of the day #78:

Wondering how many log files are generated per server every minute? Quickly find out by typing:

Get-MailboxDatabase -Server <Mailbox Server Name> | ?{ %{$_.DatabaseCopies | ?{$_.ReplayLagTime -ne [TimeSpan]::Zero -And $_.HostServerName -eq $env:ComputerName} } } | %{ $count = 0; $MinT = [DateTime]::MaxValue; $MaxT = [DateTime]::MinValue; Get-ChildItem -Path $_.LogFolderPath -Filter "*????.log" | %{ $count = $count + 1; if($_.LastWriteTime -gt $MaxT){ $MaxT = $_.LastWriteTime}; if($_.LastWriteTime -lt $MinT){ $MinT= $_.LastWriteTime} }; ($count / ($MaxT.Subtract($MinT)).TotalMinutes) } | Measure-Object -Min -Max –Ave

Tip of the day #79:

Wondering how many log files are generated per database every minute? Quickly find out by typing:

Get-MailboxDatabase -Server <Mailbox Server Name> | %{ Get-ChildItem -Path $_.LogFolderPath -Filter "*????.log" | Group- Object -Property {$_.LastWriteTime.Day,$_.LastWriteTime.Hour,$_.LastWriteTime.minute} | ?{$_.Count -gt 1} | Measure-Object -Property Count -Min -Max -Ave }

Tip of the day #80:

Get quick health and status information for your mailbox database copies by typing:

Get-DatabaseAvailabilityGroup DAG1 | %{ $_.Servers | %{ Get-MailboxDatabaseCopyStatus -Server $_ } }

Tip of the day #81:

Did you know that you can share your calendar and contacts folders with other federated Exchange 2013 organizations by first creating a federation trust with the Microsoft Federation Gateway with a valid digital certificate? Just use the New-FederationTrust cmdlet and the certificate thumbprint to get started. Type:

New-FederationTrust -Name "Microsoft Federation Gateway" -Thumbprint <cetificate thumbprint>

Finish by setting up an organization relationship with another federated Exchange organization to share limited calendar free/busy information. Type:

Get-FederationInformation -DomainName <other domain name> | New-OrganizationRelationship -Name "<name of relationship>" -FreeBusyAccessEnabled $true -FreeBusyAccessLevel –LimitedDetails

Tip of the day #82:

Need to quickly get a list of your Exchange certificates and their thumbprints? Just use the Get-ExchangeCertificate cmdlet. Type:

Get-ExchangeCertificate | fl

Want to filter the list and include just the self-signed certificates? No problem! Type:

Get-ExchangeCertificate | where {$_.IsSelfSigned -eq $true} | fl

Tip of the day #83:

Not sure your federation trust with the Microsoft Federation Gateway is working correctly? To test if a security token can be retrieved, just type:

Test-FederationTrust

Tip of the day #84:

Need a report on the status of each Exchange certificate installed on all Mailbox and Client Access servers? Try this:

Test-FederationTrustCertificate

Tip of the day #85:

Need to verify that an organization relationship is correctly configured and functioning as expected for a user in an external Exchange organization? Just type:

Test-OrganizationRelationship -UserIdentity <user email address> -Identity <external domain> –Confirm

Tip of the day #86:

Use this command to get all active mailbox move requests on a mailbox server:

$(Get-MailboxDatabaseCopyStatus -Server MBX | ?{ $_.status -eq "Mounted" }) | %{ Get-MoveRequest -TargetDatabase $_.DatabaseName } | ?{ $_.Status -ne "Completed" -and $_.Status -ne "CompletedWithWarning" }

Tip of the day #87:

Use this command to find all non-completed move requests and group them by target database:

Get-MoveRequest | ?{ $_.Status -ne "Completed" -and $_.Status -ne "CompletedWithWarning" } | group targetdatabase | sort  Count –Descending

Tip of the day #88:

Use this command to find failure messages for all failed moves:

Get-MoveRequest -MoveStatus Failed | Get-MoveRequestStatistics | ft Alias, percentcomplete, message –auto

Tip of the day #89:

Use these commands to get a snapshot of the move throughput for completed moves.

$stats = Get-MoveRequest -MoveStatus Completed | Get-MoveRequestStatistics
$stats | sort totalmailboxsize | ft Alias,{$_.totalmailboxsize.ToMB()},totalinprogressduration –auto

Tip of the day #90:

Use this command to view how many move requests are in the queue to be moved:

(Get-MoveRequest -MoveStatus Queued).count

Tip of the day #91:

Use this command to find all mailbox move requests for mailboxes on the active mailbox database copies that are hosted on the specified mailbox server. This command returns the display name, status of the move request, and the database to which the mailbox is being moved.

$(Get-MailboxDatabaseCopyStatus -Server MBX01 | ?{ $_.status -eq "Mounted" }) | %{ Get-MoveRequest -TargetDatabase $_.DatabaseName }

Tip of the day #92:

Need to see a list of the URLs for a user's calendar that has been published for Internet access? Just type:

Get-MailboxCalendarFolder -Identity <user alias>:\calendar | fl

Tip of the day #93:

Did you know that you can download and integrate the latest version of Help for all cmdlets on the local Exchange server? Type:

Update-ExchangeHelp

You need to run this command on each Exchange server to get updated Help.

Cheers,

Rhoderick