Identity Management for the Cloud Era – Part II: AD FS Configuration

Posted by on February 27th, 2014
January 9th, 2017

Picking up from Part 1: ThousandEyes with Microsoft Active Directory Federation Services, you already have both AD FS and your ThousandEyes application running and accessible. I am going to use this link to verify my installation works: https://sso.les.local/adfs/fs/federationserverservice.asmx. It will return an XML page if everything is OK.

If you are doing a new AD FS installation, here are couple things to remember. In AD FS from 2012 R2, there is no need to install Internet Information Services, it’s not required anymore. The SSO service name must be different from the server name, in my case they are sso.les.local and adfs.les.local. Due to Kerberos and service principle names registration requirements, make sure DNS resolution works (create A record for sso.les.local).

When AD FS is installed it automatically selects it’s Active Directory as identity provider, this is where all user accounts will be stored. You can verify it using AD FS Management – select “Trust Relationships”, under “Claims Provider Trusts” you will see “Active Directory” as Enabled.

The next step is to configure ThousandEyes as a service provider using AD FS Management – select “Trust Relationships”, under “Relying Party Trusts”.

1. Open AD FS management console, click “Certificates” under “Service” under “AD FS”. Double click Token-signing certificate to open it and click Details tab of the certificate as depicted on figure below.

Token signing certificate export
Figure 1: Token signing certificate export

2. Click “Copy to file”, this will launch “Certificate Export Wizard”. Save certificate into a file of DER format (.CER), for example, “C:\Temp\Token-signing-certificate.cer”

3. Login into ThousandEyes application using your Organizational Admin account and navigate to “Settings” – “Account” – “Security & Authentication”; select check box – “Enable Single Sign-On”

ThousandEyes SSO configuration
Figure 2: ThousandEyes SSO configuration

4. Here are the entries you’ll have to make (replace “sso.les.local” with your Web SSO service name):

5. Click Save; this will save your SSO configuration.

Now we’ll finish AD FS configuration.

6. In AD FS management console (sso.les.local) under “Trust Relationships” right click “Relying Party Trusts” and select “Add Relying Party Trust…”. This will launch “Add Relying Party Trust Wizard”. Click Start on the welcome page.

7. On the next page select Enter data about the relying party manually, as depicted below and click Next.

Add Relying Party Trust Wizard
Figure 3: Add Relying Party Trust Wizard

8. Enter “Display name” ThousandEyes and hit Next. This is the application name you see in the combo box on the SSO login page.

9. Leave AD FS Profile selected to activate SAML 2.0 and hit Next.

10. Do not make any changes on the next page (certificate selection) and hit Next.

11. On the next page select “Enable support for the SAML 2.0 WebSSO Protocol” checkbox and enter the following string as service URL: https://app.thousandeyes.com/login/sso/acs. Hit Next.

Relying party SAML 2.0 SSO Service URL
Figure 4: Relying party SAML 2.0 SSO Service URL

12. Enter “Relying party trust identifier” as it was entered on step 4 (“Service Provider Issuer” in ThousandEyes application): http://www.thousandeyes.com and hit Add and Next.

Relying party trust identifier
Figure 5: Relying party trust identifier

13. Next step offers to configure multi-factor authentication. For the purpose of this lab scenario I did not configure strong authentication, select “I do not want to configure multi-factor authentication for this relying party trust at this time.” and hit Next.

14. Next page offers to create authorization rules. For the purpose of this lab scenario I did not configure authorization rules, select “Permit all users to access this relying party.” and hit Next.

15. Review information on summary page and hit Next, then Close.

16. “Edit Claim Rules” dialog opens. Now you need to define how you will map your internal Active Directory users to ThousandEyes users. At ThousandEyes we expect to see an attribute called “Name ID” and it must be equal to an email as registered in ThousandEyes. For the purpose of this lab scenario I am mapping “User Principle Name” (UPN) into “Name ID”. In your real case scenario this probably will be an email address.

17. Click Add Rule, select “Send LDAP Attributes as Claims”, Claim rule name “UPN as NameID”, Attribute store – select Active Directory, on the left side of the table select “User-Principle-Name”, on the right side – “Name ID” and hit Finish.

Claim rules
Figure 6: Claim rules

This step completes configuration. Now it is time to test.

I have created a test user in Active Directory and ThousandEyes. The UPN of Active Directory user equals to email of ThousandEyes user. On my Windows 8.1 workstation I am logging in as this user, opening Web browser and navigating it to the Les Local SSO page at: https://sso.les.local/adfs/ls/idpinitiatedsignon.htm. Now select ThousandEyes from the list of your service provider applications and hit “Sing in”, this will sign you into ThousandEyes application using your local Active Directory credentials and SAML in federated Web SSO scenario.

Now if everything works as expected you can login into ThousandEyes and force use of SSO, this will prevent users from using local ThousandEyes accounts and enforce federated identity. Please note, Organization Admins will still be able to login using their ThousandEyes local account.

Force SSO
Figure 7: Force SSO

Troubleshooting

To troubleshoot issues you can enable AD FS trace in Windows Server Event Viewer. Also you need to know the following URL https://app.thousandeyes.com/login?breakSso to stop using Web SSO and to return to use of local ThousandEyes accounts. Feel free to ask me any questions in the comments field below or get help in the ThousandEyes Customer Success Center.

Processing...