AD FS CONFIGURATION GUIDE Contents What is lynda.com?... 1 What this document explains... 1 Requirements... 1 Generate identity provider metadata... 2 Add a relying party trust... 2 Edit claim rules... 3 Testing the configuration... 4 Completing the SAML authentication form... 5 Appendix... 5 What is lynda.com? lynda.com helps anyone learn software, creative, and business skills. Subscribers get unlimited access to thousands of video courses in our library. Your organization has purchased a multi-user account. What this document explains System requirements for configuring SAML based single sign-on (SSO) with Active Directory Federated Services (AD FS) How to configure lynda.com as a relying party trust in AD FS How to configure and create custom claim rules in AD FS Requirements Microsoft AD FS deployed on Windows Server 2008 R2 or later Externally accessible AD FS metadata and endpoints (typically via AD FS Proxy) AD FS Configuration Guide lynda.com 1
Generate identity provider metadata In order for lynda.com to establish a connection with your organization, we will need to upload your identity provider (IdP) metadata. The metadata includes your entity ID, server endpoints, and Security Assertion Markup Language (SAML) token signing certificate. The metadata can be provided as a XML file or a Uniform Resource Identifier (URI). Here are the steps to create your AD FS metadata URI: 1. In AD FS, in the console tree, right-click on the Service folder. 2. Select Edit Federation Service Properties. 3. Select the Organization tab. 4. Review the Organization and Support contact information fields and update accordingly. 5. Check the Publish organization information in federation metadata check box. 6. In the console tree, right click the Service folder, select Edit Federation Service Properties, and copy the Federation Service. 7. Append FederationMetadata/2007-06/FederationMetadata.xml to the Federation Service. https://<federation Service >/FederationMetadata/2007-06/FederationMetadata.xml 8. Provide this URI to your lynda.com technical contact. Once the URI is loaded into the lynda.com Shibboleth Service Provider, your lynda.com technical contact will provide you with a service provider initiated link to access lynda.com. Important tip: Ensure that you have completed the Organization and Support contact form (depicted above) in full before continuing to the next step. Empty fields will result in malformed metadata. Add a relying party trust Creating a relying party trust will allow you to automatically import lynda.com configuration data using our service provider metadata. The metadata contains all of the information AD FS needs in order to identify incoming requests as well as where to send SAML assertions, including a token signing certificate. Follow the steps below to configure AD FS as the identity provider and lynda.com as the relying party: 1. In AD FS, in the console tree, right-click the Relying Party Trusts folder, and then select Add Relying Party Trust to start the Add Relying Party Trust Wizard. 2. On the Select Data Source page, leave selected Import data about the relying party published online or on a local network. 3. In the Federation metadata address field, type https://shib.lynda.com/lyndametadata.xml, and then select Next. 4. Select OK to acknowledge the message Some of the content in the federation metadata was skipped because it is not supported by AD FS. 5. On the Specify Display page, insert lynda.com, and then select Next. 6. On the Choose Issuance Authorization Rules page, leave the default Permit all users to access the relying party selected, and then select Next. 7. This page reviews the relying party trust configuration. After reviewing, select Next. AD FS Configuration Guide lynda.com 2
8. On the Finish page, ensure the Open the Edit Claim Rules dialog for this relying party trust when the wizard closes is unchecked, then select Close. 9. Select lynda.com under Relying Party Trusts, right-click and select Properties. 10. From the Advanced tab, in the Secure hash algorithm list, select SHA-1, select Apply, then select OK (closing the Properties window). LDAP attributes as claims lynda.com requires at least one attribute be released during the authentication process to uniquely identify users. Attributes commonly used to identify users include Email Address, UPN, or Windows Account. Basic profile attributes and reporting attributes are not required but most organizations choose to release them to improve reporting and user management in the lynda.com administrative interface. Support for most frequently released attributes is built into the lynda.com Shibboleth Service Provider. If you would like to release one or more of the attributes in the table to lynda.com, follow the instructions below: LDAP Attribute MSDN attribute URI lynda Attribute Given http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname msgiven Surname http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname mssurname E-Mail Address http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress msmail Locality http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality mslocation Role http://schemas.microsoft.com/ws/2008/06/identity/claims/role msrole Windows Account http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsacco untname mswindowsaccount UPN http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn msupn 1. In the AD FS center pane, under Relying Party Trusts, right-click lynda.com, and then select Edit Claim Rules. 2. On the Issuance Transform Rules tab, select Add Rule. 3. On the Select Rule Template page, select Send LDAP Attributes as Claims. Select Next. 4. Choose the appropriate LDAP Attribute and choose the corresponding Outgoing Claim type. Above you will find an example rule that releases basic profile attributes. If you have a business need to pass additional attributes that are not included in the table above, refer to Appendix B for more information on custom claim rules. AD FS Configuration Guide lynda.com 3
Test the configuration Now that you have created a relying party trust, configured custom claim rules, and received a service provider initiated link, it is time to test the configuration. Here are the steps: 1. Select your service provider initiated link. Here is a sample link: https://shib.lynda.com/shibboleth.sso/incommon?providerid=<yourentityidhere>&target=https://shib.lynda.co m/incommon 2. If you do not have an existing session, you will be prompted to log in. Once you have logged in, you will be redirected to lynda.com. At this point in the configuration, you will not be able to create a lynda.com profile. 3. Open a new tab in your browser and visit http://shib.lynda.com/shibboleth.sso/session. This page will provide you with session details. 4. Please review the session page and ensure that all expected attributes and values appear on the page. If any are missing, revisit the custom claim rules for that attribute. Miscellaneous Client Address: 174.76.115.78 Identity Provider: http://adfs.dundermifflin.com/adfs/services/trust SSO Protocol: urn:oasis:names:tc:saml:2.0:protocol Authentication Time: 2013-11-01T18:15:03.425Z Authentication Context Class: urn:oasis:names:tc:saml:2.0:ac:classes:passwordprotectedtransport Authentication Context Decl: (none) Session Expiration (barring inactivity): 479 minute(s) Attributes ou: Sales given: Jim sn: Halpert l: Scranton, PA mail: jhalpert@dundermifflin.com manager: Michael Scott title: Sales Associate uid: 465 Attributes Glossary ou organizational unit sn surname mail email address title job title given first name l location manager manager uid user ID Complete the SAML authentication form In order to complete your account configuration, you will need to provide your lynda.com technical contact with a completed SAML authentication form. Please use the information on the session details page (depicted above) to complete the asserting party trust and attributes sections of the SAML authentication form. The asserting party trust section requests the identity provider entity ID. The entity ID is available on the session details page next to identity provider. All passing attributes and corresponding values appear below the attribute header and should be copied over to the attributes section of the SAML authentication form. AD FS Configuration Guide lynda.com 4
Appendix A Limiting access via security groups Some organizations choose to limit lynda.com access to a subset of their user population. This can be accomplished in a number of ways but the most flexible option is limiting access to an Active Directory security group. Follow the instructions below to limit access to a security group. 1. Create a security group and add authorized lynda.com users to it. 2. To get the group SID, Open Windows PowerShell and paste the following command, replacing the bolded Group with the lynda.com security group name. $AdObj = New-Object System.Security.Principal.NTAccount("Group ") $strsid = $AdObj.Translate([System.Security.Principal.SecurityIdentifier]) $strsid.value 3. Save the group SID value for use in Step 9. 4. In the AD FS center pane, under Relying Party Trusts, right-click lynda.com, and then select Edit Claim Rules. 5. On the Issuance Transform Rules tab, select Add Rule. 6. On the Select Rule Template page, select Send Claims Using a Custom Rule and then select Next. 7. the rule lynda.com Access Attribute. 8. In the rule below, replace the bolded Security-Group-SID with the lynda.com security group SID. 9. Copy and paste the rule below into ADFS. Important tip: Copying and pasting claim rules from this PDF can cause ADFS syntax errors. Paste all rules into a text editor like Notepad++ and validate the formatting before adding the rule to your ADFS configuration. "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "Security- Group-SID", => issue(type = "urn:oid:1.3.6.1.4.1.5923.1.5.1.1", Value = "Lynda-User", Issuer = c.issuer, Appendix B Custom claim rules The lynda.com Shibboleth Service Provider expects different inbound SAML attribute names and name formats than AD FS publishes by default. For these reasons, we will use the AD FS custom rule language to generate Shibbolethcompliant claims. In this section, we will be creating two claim rules for each attribute you would like to pass to lynda.com. We will start by generating a claim based on each user s objectguid. objectguid is a value set when a security principal (user) is created and cannot be changed. lynda.com will be using this attribute as the unique identifier for each user due to the attribute s unique and immutable nature. AD FS Configuration Guide lynda.com 5
Here are the steps: 1. In the AD FS center pane, under Relying Party Trusts, right-click lynda.com, and then select Edit Claim Rules. 2. On the Issuance Transform Rules tab, select Add Rule. 3. On the Select Rule Template page, select Send Claims Using a Custom Rule and then select Next. 4. On the Configure Rule page, in the Claim rule name box, type Get objectguid. 5. On the Custom rule window, copy and paste the following in plain text using ^ Ctrl + Shift + V: => add(store = "Active Directory", types = ("urn:oid:0.9.2342.19200300.100.1.1"), query = ";objectguid;{0}", param = c.value); 6. Select Finish. 7. On the Issuance Transform Rules tab, select Add Rule. 8. On the Select Rule Template page, select Send Claims Using a Custom Rule, and then select Next. 9. On the Configure Rule page, in the Claim Rule box, type a name for the rule. Example: Transform user name. 10. In the Custom Rule window, copy and paste the following in plain text using ^ Ctrl + Shift + V: "urn:oid:0.9.2342.19200300.100.1.1"] Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/attributenam e"] 11. Select Finish. Sample claim rules Below is a list of the most frequently used custom claim rules. Claim rules must be in sequential order. The Get rule for an attribute needs to be followed by the Transform rule. This section should be used in conjunction with the Edit claim rules section to pass additional user data in each SAML assertion. Paste all rules in plain text to avoid formatting issues in ADFS. Important tip: Copying and pasting claim rules from this PDF can cause ADFS syntax errors. Paste all rules into a text editor like Notepad++ and validate the formatting before adding the rule to your ADFS configuration. department Get Rule: => add(store = "Active Directory", types = ("urn:oid:2.5.4.11"), query = ";department;{0}", param = c.value); department Transform Rule: "urn:oid:2.5.4.11"] location Get Rule: AD FS Configuration Guide lynda.com 6
=> add(store = "Active Directory", types = ("urn:oid:2.5.4.7"), query = ";physicaldeliveryoffice;{0}", param = c.value); location Transform Rule: "urn:oid:2.5.4.7"] title Get Rule: => add(store = "Active Directory", types = ("urn:oid:2.5.4.12"), query = ";title;{0}", param = c.value); title Transform Rule: "urn:oid:2.5.4.12"] employeeid Get Rule: => add(store = "Active Directory", types = ("urn:oid:1.2.840.113556.1.2.610"), query = "; employeeid;{0}", param = c.value); employeeid Transform Rule: "urn:oid:1.2.840.113556.1.2.610"] manager Get Rule: => add(store = "Active Directory", types = ("urn:oid:0.9.2342.19200300.100.1.10"), query = "; manager;{0}", param = c.value); manager Transform Rule: "urn:oid:0.9.2342.19200300.100.1.10"] AD FS Configuration Guide lynda.com 7