Category Archives: Web Application Proxy

Backup and Recovery with the AD FS Rapid Restore Tool

AD FS 2012 R2, AD FS 2016, Backup, Disaster Recovery, Restore, Web Application Proxy, Windows Server 2012 R2, , , , , , , , , , , , , ,

Slipping out of the Microsoft stable recently with little fanfare, the AD FS Rapid Restore Tool. As the name suggests, this is a tool geared at aiding in the recovery of your AD FS configuration / environment, in the event of server failure or disaster. To date, effectively backing key material and/or relying parties has been a proverbial thorn-in-the-side for AD FS administrators, so the release of this utility is very interesting.

Does this tool do the trick? Let’s give it a whirl…

Download the MSI and install the tool.  You can get the MSI from here. Supported versions are AD FS 2012 R2 and AD FS 2016. The tool is directly installed on the farm node and the installation process is very straightforward ( a la Next Next Next).

2016-10-01_15-04-32

With the tool installed we can launch a Administrative PowerShell prompt and then import the module.

2016-10-01_21-25-16

Let’s look at some of the command option via Get-Help Backup-ADFS -full

2016-10-01_18-09-49

As can be seen from the graphic above, when we call the Backup-ADFS cmdlet, backup of the AD FS configuration is possible to both the filesystem or to Azure. In these test scenarios, the local file system is used.

A backup folder (e.g. C:\ADFSExport) is created manually as the backup/restore location. The Backup-ADFS cmdlet is then run. Here’s the syntax used for testing.

Backup-ADFS -StorageType “FileSystem” -StoragePath “C:\ADFSExport\” -EncryptionPassword “12345678” -BackupComment “Clean Install of ADFS (FS)” -BackupDKM

2016-10-01_18-07-26

Oops.. a warning. As the Microsoft documentation points out, your AD FS SSL/TLS certificate will only be backed up during the export if the private keys are marked as exportable and the associated Manage Private Keys permission is given to the user running the script. In the above example, my certificate does not fit that criteria. A simple way to check beforehand is to attempt to export the SSL certificate via the Certificate Export Wizard.  If “Yes, export the private key” is greyed out, it’s not exportable. Now go find that PFX ……

2016-10-01_18-16-45

Where the script can’t handle the service communication certificate migration, the PFX should be manually imported on the replacement server before the restore script is run.

By the way, the token signing and decryption certificates (incl. private keys) used by AD FS are stored in the AD FS configuration database itself. These certificates are then encrypted using something called the Distributed Key Manager (DKM). A container is created in the local Active Directory  of your AD FS during installation of the first AD FS node in the farm. The DKM master key is then stored in this container. The recovery tool provides for backup of the DKM facility and in the export command-line above the “Backup-DKM” is used. I’m no expert on DKM, so if you require a more detailed information, I suggest you go hunting here.

Onto the recovery. Here I wanted to test a number of changes.

Same Server Recovery

For this simple test, we elected to remove the AD FS farm (primary) role  in each case and cleaned out the AD FS container in Active Directory (CN=ADFS,CN=Microsoft,CN=Program Data). A fresh installation of AD FS was then made, the tool installed and then the restore operation begun.  Any existing configuration database was overwritten.

Restore 1 – Basic

To begin with, in the first restore, we help the tool along a little bit by partially rebuilding the AD FS server. I added the AD FS role manually via Server Manager, specified the federation service name, the SSL certificate to use and the relevant service account. Here the recovery script was as follows:

Restore-ADFS -StorageType “FileSystem” -StoragePath “C:\ADFSExport\” -DecryptionPassword “12345678” -RestoreDKM

Restore worked fine. No errors and the WAP connected back to the “new” farm without issues.

Restore 2 – Complete

This option required providing the command-line with a little more information as the role was not pre-installed. Consequently, those missing elements, pre-loading of SSL/TLS service communications certificate aside, needed specifying.

Restore-ADFS -StorageType “FileSystem” -StoragePath “C:\ADFSExport\” -DecryptionPassword “12345678” -RestoreDKM -ADFSName “adfs.mydomain.com” -DBConnectionString “WID” -GroupServiceAccountIdentifier “MYDOMAIN\gmadfs$”

Again, no issues. Impressive.

That SSL error during the initial export was still bugging me though. Just to make sure that SSL export really was supported, I flipped the Service Communications certificate in AD FS to one with an exportable private key (the replacement certificate was one from a local test CA, complete with Server Authentication EKU). The cert then needed to be assigned to AD FS  via PowerShell.

dir cert:\LocalMachine\My
Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint thumbprint
Set-AdfsSslCertificate -Thumbprint thumbprint

 

After an AD FS  restart, with the new certificate in place, I then reran a new export:

2016-10-01_21-28-23.png

As can be seen from the above screenshot, with the exportable cert in place there were no SSL errors this time. Removing AD FS and then rerunning the Restore-ADFS cmdlet an additional  time then demonstrated that the SSL certificate was then imported as part of the recovery.  Nice.

New Server Recovery

Of course, no test is worth its weight in custard unless we actually go the extra mile and try and break stuff.  In the next scenarios, we’ll tweak the configuration a little, moving AD FS to a completely new server and do a database recovery to a new format.

Restore 1 – WID to SQL

As well as introducing a new server, complete with different IP, computer name etc., we will also migrate the recovered solution to a new database form factor, as part of the recovery. Via the script, the original Windows Internal Database (WID)-based AD FS solution will be refactored in SQL Server.

Restore-ADFS -StorageType “FileSystem” -StoragePath “C:\ADFSExport\” -DecryptionPassword “12345678” -RestoreDKM -ADFSName “fed.route443.net” -DBConnectionString “data source=sqlserverFQDN;initial catalog=adfsconfiguration;integrated security=true” -GroupServiceAccountIdentifier “MYDOMAIN\gmadfs”

The change in the script is minimal from previous cases. In order to effect the transition from WID to SQL we simply provide the necessary connection string in the Restore-ADFS cmdlet so that the recovery tool can provision the AD FS configuration and Artifact database on the SQL Server. Running the restore script against Backup ID 8 (in this example).

2016-10-02_7-50-31

The restore is complete without errors. On the SQL Server in Management Studio, the databases are successfully provisioned.

2016-10-02_7-48-33

On our Web Application Proxy (WAP) in a HOSTS file (or DNS – YMMV), we update the reference to the AD FS farm pointing to the new IP address. Excellent! Cue login test page and successful logon.

2016-10-02_8-06-54

Restore 2 – SQL to WID

Believe it or not, the request to move from SQL to Windows Internal Database (WID) does come up from time-to-time on Technet forums, so I thought I’d validate this scenario also. Here we’re moving back our AD FS configuration database(s) running on a SQL workload to WID. We back up our ADFS/SQL server  and then copy the C:\ADFSExport folder to the newly minted server. Here the following syntax is then run:

Restore-ADFS -StorageType “FileSystem” -StoragePath “C:\ADFSExport” -DecryptionPassword “12345678” -RestoreDKM -ADFSName “adfs.mydomain.com” -DBConnectionString “WID” -GroupServiceAccountIdentifier “MYDOMAIN\gmadfs$”

2016-10-02_9-37-11

Item 9 is the ADFS/SQL backup which we wish to restore. Again, on the WAP we point away from our old ADFS / SQL pair to our freshly restored ADFS / WID combination and test logon and we’re up and running.

Summary

This is an outstanding tool and one every AD FS administrator should be in possession of. Not to be underestimated, the AD FS Rapid Restore tool not only  adds great value to the recovery process, but also provides an excellent means for copying/mirroring your environment AD FS for testing. Moreover, as can be seen from the previous screenshots, it’s also an excellent way of backing up and charting your AD FS configurations vis-a-vis change management.

MFA Conditional Access Policies in AD FS 2012 R2

AD FS R2, Claims-based Authentication, Multi-Factor Authentication, Web Application Proxy, Windows Server 2012 R2, , , ,

Hello again. The previous Multi-Factor Authentication (MFA) post on User Certificates provided an opportunity to expand and look at  some of the more interesting scenarios for MFA conditional access.  This “interest”, if I may call it that, stemmed from playing around with MFA over the last few months and looking at the role of conditional access polices therein.

Ramiro Calderon wrote a great article on MFA policy here and it comes highly recommended. As he mentions in his post, the AD FS claims engine computes MFA authentication requests (defined via the AD Management UI) in a logical OR fashion. This can be initially a little confusing and we’ll take a look at some more creative use of MFA policies, to handle more flexible access scenarios in R2.

MFA Primer

To make use of MFA, an MFA provider is required. In a vanilla AD FS R2 setup, this is limited to certificate authentication using client certificates (see previous post). For other MFA options, check with your favorite 2FA vendor to see if they’ve written an MFA adapter for AD FS R2.

In the global authentication policy, the MFA provider needs to be enabled.

image

Let’s have a look at what happens when MFA is enabled through the AD FS Management UI. MFA policies can be triggered either globally (applicable to all relying parties), or on the relying party itself.

In the example below, MFA is required for securing access to applications outside of the organization, what Microsoft call Extranet use.

image

Users connecting from outside the corporate network will be prompted after successful AD username/password authentication by the MFA handler.

When the MFA policy is set globally, this can be seen in PowerShell via the Get-AdfsAdditionalAuthenticationRule

c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");

If a global authentication policy is not specified, but the policy is enabled in a relying party rule, then an additional authentication rule, defined on the RP, is evaluated. This allows for a more refined use of policy and I’ll show examples of this, by way of scenarios, later in the post.

The AD FS Management UI is sufficient for applying the use of MFA in most single “context” access scenarios. By this I mean, we are able to enforce the requirement of MFA to satisfy policies, that stipulate additional authentication is required by use of one of either user/group, device or location. For example, if we determine that a MFA policy needs to be used by location only, e.g. Extranet, we simply select the Extranet location checkbox. All users connecting from outside of the corporate network must then use MFA. Conversely, if we want to enforce MFA for a specific subset of users/groups, irrespective of their location (Extranet/Intranet), by adding them via the users/groups option in the UI, this can be  also be set. Finally, we can also specify that unregistered or registered devices (a la Workplace Join) need to use MFA, via the devices checkboxes. The fact that these policies may also be applied independently on a per relying party basis, often satisfy basic access policy needs.

The challenge arises when dealing with a combination of policy, for example, when stating an MFA requirement by device and by location.

image

AD FS will now trigger MFA when an unregistered device (non-workplace joined) connects to AD FS AND also when users are connecting from the Internet  The policies are evaluated independently and we may unwittingly be enforcing MFA for a registered device in a Workplace Join scenario, when the desired outcome was actually to ensure that a single authentication factor (the device certificate paired with the user concerned) was sufficient for access from the outside. This is the logical OR behavior that Ramiro refers to in his post.

Similar behavior can be observed if the following settings are made.

image

Here we have a specific user/group requiring MFA and also the location (Extranet) checkbox is checked. Users who are members of the GU-SEC-ADFS-MFA group must always use MFA, irrespective of their location AND other users, connecting from outside of the corporate network, will be challenged by the MFA handler. Again, if the intention was to enforce MFA for a combination of outcomes; namely, by group and location outside, then this is not the outcome.

Rules  are evaluated independently when set via the UI. Given that requirements via the UI operate this way, if there is a requirement to enforce MFA via policy where:

      • it’s an unregistered device AND
      • connecting from the Internet

                OR in the second example where:
              • user is member of group X AND
              • connecting from the Internet

            The AD FS Management  UI doesn’t support this arrangement. Instead, more refined policies can be handled with PowerShell, using combinations of authentication rules. As with the UI, this can be expressed either as a global authentication policy applicable to all relying parties (Set-AdfsAdditionalAuthenticationRule) or MFA policies defined on a per relying party basis (Set-AdfsRelyingPartyTrust).  I’ll use the latter to drum up examples of setting finer-grained access rules in the scenarios that follow. More work for us admins, but greater flexibility to boot…

                    Scenario A: Externally connecting workplace joined device (registered user)

              Requirement: Registered users on Workplace Join devices connecting from outside the corporate Internet may authenticate using the device authentication certificate. All other users/devices must use MFA.

            $rp = Get-AdfsRelyingPartyTrust –Name "WIF Test Application"
            Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –AdditionalAuthenticationRules ‘c: [Type == "            http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] && [Type == "http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");’

              Requirement: Users who are members of Group X are exempt from a general policy stipulating use of MFA when connecting from the outside of  the network. All other users must use MFA. Note: We flip the behavior with the Group SID claim use in Scenario B by using the NOT EXISTS evaluation.

              $rp = Get-AdfsRelyingPartyTrust –Name "WIF Test Application"
              Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –AdditionalAuthenticationRules ‘exists([Type == "              http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"]) && NOT EXISTS ([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-Insert your Group SID here"]) => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");’

              Scenario D: MFA using a custom evaluation rule

              Requirement: The Azure Sprout organization is using “vanity” UPNs to enforce MFA for non-standard UPN suffixes. Corporate users with an @azuresprout.com UPN suffix may use single factor (forms) authentication from the outside. All other UPN suffixes in the “organization” must use MFA.

              $rp = Get-AdfsRelyingPartyTrust –Name "WIF Test Application"
              Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –AdditionalAuthenticationRules ‘NOT EXISTS([Type == "              http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", Value =~ "^.*@azuresprout\.net$"]) => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");’

              Scenario E: MFA based on custom claims extrapolated from an attribute store

              Requirement: An SQL attribute store is used to augment claims when accessing a business application. Values extracted  from the store are to be used as triggers for MFA.

              On the relying party, we connect to an attribute store and populate an sqlrole claim, based on running a stored procedure to find the user and the appropriate access information for user on application FOO.

              c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"%5D => add(store = "SQL Attribute Store", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/sqlrole"), query = "EXEC dbo.GET_ACCESSTOKEN @UserID={0},@AppCode=’FOO’", param = c.Value);

            Next, on the RP pipeline, we define the MFA requirement based on value returned in the sqlrole claim .

            $rp = Get-AdfsRelyingPartyTrust –Name "WIF Test Application"
            Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –AdditionalAuthenticationRules  ‘c:[Type == http://schemas.microsoft.com/ws/2008/06/identity/claims/sqlrole”, Value =~ "<Whatever the response we’re expecting for MFA trigger>"]) => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn&quot;);’ 

              The latter scenario is a little more unusual, but I’ve used it to highlight what is possible (as with Scenario D) outside of the normal conventions provided by the UI.

              As a sneak peek into the new Window Server “10” release, it appears that Microsoft have expanded authentication support and making the nuances of policy-based access control more accessible to the end user, through the use of a new policy template editor, made available to the AD FS administrator.. more on this and another ADFS “stuff” to come…

              Here’s a snippet of the new rules editor from the pre-release.

            image

            MFA with Client Certificates in ADFS 2012 R2

            AD FS R2, Claims-based Authentication, MFA, Multi-Factor Authentication, Relying Party, Strong Authentication, Web Application Proxy, Windows Server 2012 R2, , , , , , ,

            There have been questions on this subject posted recently to comments and also on the TechNet forums, so I just wanted to quickly write up something about use of client certificates in the MFA (secondary) slot in AD FS 2012 R2.  You may recall from earlier AD FS R2 posts, that we used virtual smart card and smart card as examples. Let’s broaden that to include “soft” client certificates as an MFA/secondary provider. This functionality is provided “out-of-the box” in AD FS 2012 R2. An Active Directory Certificate Services (AD CS) infrastructure is required to serve up certificates for enabling users for PKI.

            In this post, I’ll be using an Active Directory Certificate Services (AD CS) role from Windows Server 2012 R2 as the Certification Authority (CA). I won’t be explaining the CA setup, beyond the templates used, as there’s been plenty of ink expended on this topic already on the Internet.  A Windows 2003/2008/2012 CA setup will suffice for the activities  concerned here.

            Testing was done with client certificates from a Windows 8.1 clients using:

            • a non domain-joined machine, via Certificate Enrollment (Policy) Web Services and Microsoft Management Console (MMC)
            • a domain-joined machines, via an auto-enrollment policy User-Context GPO.

            In AD Certificate Services (AD CS) a duplicate of the default User certificate template was made (called User V2). Under the Application Policy, the policy is limited to Client Authentication.

            image

            For domain-joined clients, we can enable auto-enrollment via the security tab of the template. Here we see a group called GU-SEC-ADCS-Managed, which is given the necessary read, enroll and autoenroll permissions and we can add users to that security group.

            image

            To enable auto-enrollment for domain-joined clients we need to activate a policy to accomplish this. Against best practices (boo), but for expediency (mine.. yay!), I enable the policy in the Default Domain Policy GPO. The actual settings can be find under Windows Settings|Security Settings|Public Key Policies. Select the Certificate Services Client – Auto Enrollment object and enable the Configuration model section as seen below.

            image

            For the non-domain joined client, read and enroll permissions are given to a group I’ve called GU-SEC-ADCS-Workgroup. The test user, who will be a member of that group, can request the UserV2 certificate template via the Certificates|User MMC plug-in using AD CS Certificate Enrollment Web Services. Again, I won’t be describing how to setup enrollment web services. If you need help, just post in the comments section.

            With Certificate Services, we need to make available the template available to both sets of clients, by enabling the template in the Certification Authority MMC plugin – Certificate Templates|New|Certificate Template to Issue.

            image 

            In a correctly configured setup, domain-joined clients will obtain a certificate on the next GPO refresh cycle for the user (e.g. logon).

            As mentioned previously, I’m joining non-domain joined clients via enrollment web services using the MMC snap-in in Windows 8.  In the Certificates|User context of the MMC snap-in, we request a new certificate. In this particular test setup, there are three certificate templates visible for enrollment by the client from the CA:

            image

            User V2 is the template we just created for use for “soft” client certificates.The certificate services enrollment point in this example is configured for Username/Password authentication. Logon is done with a test AD user account training@azuresprout.net, who is a member of the GU-SEC-ADCS-Workgroup and authorized with the enroll permission.

            image

            Once that’s done, a client certificate is installed in the user context.

            image

            On the AD FS side of things, let’s assume we now need to apply MFA for users (with client certificates) coming from the Internet. Before we jump into the actual AD FS settings, it’s worth mentioning that any firewalls in front of the Web Application Proxy (WAP) will need to allow port 49443/TCP inbound, as this is the port the AD FS Smartcard Authentication Service listens on.

            We see evidence of this requirement in the Windows Firewall snap-in. AD FS creates a firewall rule during the installation allowing 49443/TCP inbound.

            image

            image

            In AD FS Global Authentication Policy for MFA, we enable certificate authentication:

            image

            Note that at this point, I’m not enforcing the use of MFA globally, rather enabling it for use at a lower level on a relying party rule, for more incremental control. Whether to go for global or granular policies really boils down to a question of fit and the use cases may need to support. .

            On a test Windows Identity Foundation (WIF) relying party, MFA is enforced for externally connecting users.

            image

            Logging on to the relying party, we hit the primary authentication handler (AD FS forms), enter our username/password.

            image

            Connecting from the Internet, with MFA enabled, the secondary (MFA) authentication handler kicks in and we’re presented with a login popup.

            image

            In the above graphic, we have an option to login with a virtual smart card (top) and an X509 client certificate (bottom). Click on the certificate and AD FS will authenticate the user using secondary authentication (MFA).

            The enrolled certificate is stored by AD CS in the userCertificate attribute of the user object within AD. This attribute contains the DER-encoded X509v3 certificates issued to the user. We can lookup the necessary certificate reference, for example, in the Attribute Editor of AD Users & Computers (ADUC).

            image

            This is a multi-valued attribute.

            image

            One thing that can be useful, should you be working with multiple certificates for a given user, is being able to cut and paste the hex encoded value into Notepad, save it, then check to see what the certificate value corresponds to using CERTUTIL.

            certutil –decodehex mylo.hex mylo.cer

            We can then open the .cer file to see what the certificate is.

            Returning to the test claims applications (having logged in successfully0, we pass all claims processed via an issuance transform rule of c:[]  => issue(claim = c);
            We can see the relevant authentication method references processed during primary and secondary logon.

            image

            As I mentioned in an earlier post, the nice thing here is that you can use the Enhanced Key Usage (EKU) claim emitted for both client certificates and smart cards / virtual smartcards to moderate access to resources as you see fit.

            Looking at a user authenticating with a client certificate, the following EKU is emitted as a claim.

            image

            Smart cards also emit the smart card EKU

            image

            Access can also be further graded by using custom OIDs to differentiate between levels of access based on the type of MFA being used and the EKU value.

            Use of certificates in the MFA slot in R2 (I suspect) are really geared for use in a true two-factor (2FA) authentication capability, i.e. smart cards. While the use of a client certificate does offer value in offering richer access possibilities, this is not 2FA, in that it does not satisfy the mantra of “something I have and something I know”. Instead, this is more akin to 1.5FA.

            To finish up, Microsoft recently added support in Windows 7 for domain-joined clients via a hotfix. I’ll attempt to throw out a quick post on this, but in the meantime,  I’ll be following up by looking at conditional access policies for MFA.

            As always, thanks for reading and if you have any questions, please post a comment and I’ll do my best to answer quickly.

            Exchange 2013 SP1, Outlook Web App (OWA) and AD FS

            AD FS R2, Claims-based Authentication, Exchange Control Panel, Exchange Server 2013, Outlook Web App, Web Application Proxy, , , , ,

            It’s over a year now since the last Outlook Web App article about integrating OWA with ADFS. In that post we explored the use of claims-based authentication with OWA in a Proof of Concept using WIF 3.5 and FedUtil. This was an unsupported setup in Microsoft eyes and, in the meantime, with the release of Windows Server 2012 R2, opportunities for supporting Exchange web applications such as OWA,  have arisen. The first, provided support via the use of a non-claims aware web application in AD FS R2 using Kerberos Constrained Delegation (KCD), utilizing the new Web Application Proxy (WAP) feature. The recent release of Exchange 2013 SP1 further expands OWA support, including native support for AD FS in the Exchange product, with claims-based authentication now possible for Outlook Web App (OWA) and the Exchange Admin Center (EAC).

            To get started, I’ll refer you to a Technet article here that provides a step-by-step. I used this article as a starting point for setting up OWA/EAC with AD FS R2. These two application endpoints in Exchange (OWA and ECP) need to be represented as relying parties within AD FS.

            Here’s an excerpt of the PowerShell rules required for creating the RPs:

            Add-ADFSRelyingPartyTrust -Name “Outlook Web App” -Enabled $true -Notes “This is a trust for https://mail.mydomain.com/owa” -WSFedEndpoint https://mail.mydomain.com/owa -Identifier https://mail.mydomain.com/owa -IssuanceTransformRules $IssuanceTransformRules -IssuanceAuthorizationRules $IssuanceAuthorizationRules

            Add-ADFSRelyingPartyTrust -Name “Exchange Admin Center (EAC)” -Enabled $true -Notes “This is a trust for https://mail.mydomain.com/ecp” -WSFedEndpoint https://mail.mydomain.com/ecp -Identifier https://mail.mydomain.com/ecp -IssuanceTransformRules $IssuanceTransformRules -IssuanceAuthorizationRules $IssuanceAuthorizationRules

            The AD User and Group SIDs, together with UPN also need to be defined for each of the Exchange Relying Party applications in the form of custom claims rules: Windows Account Name (sAMAccountName)

            c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”, Issuer == “AD AUTHORITY”] => issue(store = “Active Directory”, types = (“http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid”), query = “;objectSID;{0}”, param = c.Value);

            Group SID (enumarate group membership)

            c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”, Issuer == “AD AUTHORITY”] => issue(store = “Active Directory”, types = (“http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”), query = “;tokenGroups(SID);{0}”, param = c.Value);

            User Principal Name (UPN)

            c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”, Issuer == “AD AUTHORITY”] => issue(store = “Active Directory”, types = (“http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn”), query = “;userPrincipalName;{0}”, param = c.Value);

            On the Exchange side, via PowerShell, we specify the Relying Party Identifiers via the AdfsAudienceUris parameter and must also provide the token signing certificate thumbprint from the AD FS server.

            $uris = @(“https://mail.mydomain.com/owa”,”https://mail.mydomain.com/ecp”) Set-OrganizationConfig -AdfsIssuer “https://adfs.contoso.com/adfs/ls/” -AdfsAudienceUris $uris -AdfsSignCertificateThumbprint “TOKEN SIGNING CERTIFICATE THUMBPRINT”

            Don’t forget to import the token signing certificate into the Trusted Root Certificate Authorities container of your Exchange servers, otherwise you may fall foul of the following error logging on to your mailbox.

            clip_image002

            The source in pinpointing the problem here, lies in the query string of the error message https://external.mydomain.com/owa/auth/errorfe.aspx?msg=WrongAudienceUriOrBadSigningCert.

            In this (my) case, the token signing certificate had not been added to the Exchange servers as a trusted cert. Equally, the wrong Audience URI can present a configuration problem. It commonly arises when a unnecessary trailing slash is added to the Relying Party Identifier when configuring in AD FS, e.g. https://mail.mydomain.com/owa/. s something to keep an eye on. The correct RP identifier would be https://mail.mydomain.com/owa.

            I’ve not yet tested setting up Exchange 2013 SP1 under AD FS 2.0, but there’s nothing untoward going on here to suggest that using it as your identity provider is not possible. If you’re running under AD FS Windows Server 2012 R2 then the Web Application Proxy (WAP) adopts the proxy role for external access scenarios and also supports host name translation. For example, I make use of https://external.mydomain.com as an external URL and map this to the internal name of https://mail.mydomain.com. Be aware that matching of path-based names is not supported in the current release of the WAP, so mixing path names between externally and internally published resources is a no-no.

            To illustrate this, let’s look at an example of an OK configuration:

            Add-WebApplicationProxyApplication -BackendServerUrl ‘https://mail.mydomain.com/owa/’ -ExternalCertificateThumbprint ‘DD94E2ABAA123C6B6009CB42F16CE892AF96A47C’ -ExternalUrl ‘https://external.mydomain.com/owa/’ -Name ‘OWA’ -ExternalPreAuthentication ADFS -ADFSRelyingPartyName ‘Outlook Web App’

            Whereas, this is a non-workable configuration.

            Add-WebApplicationProxyApplication -BackendServerUrl ‘https://mail.mydomain.com/owa/’ -ExternalCertificateThumbprint ‘DD94E2ABAA123C6B6009CB42F16CE892AF96A47C’ -ExternalUrl ‘https://external.mydomain.com/mail/’ -Name ‘OWA’ -ExternalPreAuthentication ADFS -ADFSRelyingPartyName ‘Outlook Web App’

            Note the use  in publishing of the same literal path  https://external.mydomain.com/owa/ in the first example, versus a rewritten one in the second https://external.mydomain.com/mail/.

            If you’re contemplating the use of AD FS 2.0, then clearly host-name translation is not something that the AD FS 2.0 proxy brings to the table. Alternatively, a suitably equipped front-end load balancer may also fulfill that role.

            On the subject of load balancers, this rather conveniently brings me back to new features in AD FS R2. Server Name Indication (SNI) was mentioned in the “First Looks” articles about AD FS R2 and it’s worth checking that your current load balancer/reverse proxy in front of AD FS supports SNI and is supported/enabled on the device concerned. This is becoming a pain point for many, as evidenced by various posts on the Technet forums. The move to kernel-mode (HTTP.SYS) in R2 mandates the use of SNI. Therefore, it’s worthwhile checking that:

            • your friendly neighbourhood load balancer/device in front of AD FS supports SNI
            • clients and user agents support SNI and you’re not inadvertently locking them out
            • (08/04) SSL termination endpoints (e.g. load balancer / 3rd-party reverse proxies) in front of AD FS  may be affected by the recent heartbleed bug (http://heartbleed.com), exposing vulnerable OpenSSL libraries and certificates used on those devices. Microsoft infrastructure, employing Secure Channel (SChannel)  not affected, may inadvertently become so through SSL termination endpoints on the aforementioned devices in front of AD FS. More information can also be found here (http://www.kb.cert.org/vuls/id/720951)

            Accessing the OWA URL, via https://external.mydomain.com/owa and the OWA Relying Party redirects the user to AD FS for logon. In a default AD FS R2 configuration, this equates to forms-based authentication for external users.

            clip_image003

            Users accessing OWA internally, access https://mail.mydomain.com via the farm using Integrated Windows Authentication (IWA). As usual when connecting to the farm, the URL for the federation service needs to be added to the Local Intranet Zone within IE and any corresponding configuration changes made to support Kerberos for other browsers.

            At this point, optional use of a clams provider (connecting to the local AD) or an MFA provider in R2 could also come into play to provide stronger authentication, should it be required. Having successfully authenticated via AD FS, we gain access to the user mailbox. image

            The Exchange Control Panel (ECP) was also configured as a relying party within AD FS and within the Exchange configuration. Accessing the Exchange Admin Center remotely, with the Exchange Organization Administrator mylo, we can see the gamut of administrative console options available under federated logon.

            image

            This is one of those scenarios where it might be a good idea to apply stronger authentication (MFA)  to privileged user accounts when accessing the Exchange Admin Center. We can do this by applying policy-based access on the AD FS R2 server.

            In the next post, I’ll be taking a look at strong authentication access scenarios using ActiveSync and Lync (primarily with mobile clients), before completing Part 3 of the First Looks series of AD FS R2.