We will now describe the process of setting up Windows 2012 for SAML, LDAP, IIS and eFront. This guide is a series of steps along with their corresponding screenshots (when applicable). Start with logging into your IIS server.
1. Click on "Add roles and features"
2. Click on “next” and then on “Role-based or feature-based installation”
3. Select a server from the server pool
4. Select server roles, accepting any prompts:
- Active Directory Certificate Services
- Active Directory Domain Services
- Active Directory Federation Services
- DNS Server
- Web Server (IIS)
5. Don’t install anything for “Select features” in the next screen
6. Move next until the end
7. Click to Restart automatically, and then click on “Install”. The process will start.
8. Go to Start->Administrator tools->IIS
9. Expand the Service and click “No” when prompted to get started with “Microsoft Web Platform”
10. Click on “Server Certificates”
11. Click on “Create Certificate Request” and fill in the appropriate information. Then click next, specify 2048 for the key length and finally specify a path and filename
12. Go to Zero SSL to issue free SSL. Use the CSR generated in the previous step.
13. Click on “Complete certificate request”
14. After that, it should look like this: (an error might crop up while importing, ignore it)
15. Go back to the Server Manager’s Dashboard and click on “AD DS”
16. You’ll see a notice “Configuration required…” click on “more”
17. Click to “Promote this server to a domain controller”
18. Click to “Add a new Forest” and type the server’s domain name, e.g adfs2.efrontlearning.com
19.Type a DSRM password and click next
20. Ignore the “A delegation for this DNS server [...]” message
21. Move on from the NetBIOS screen and confirm the paths
22. Click next on “Review your selections”
Note: On Windows Servers, IIS is not configured to work with the PUT command by default.
The eFront API uses the PUT command. To enable IIS PUT:
- Open your IIS Manager and select your eFront
- Open 'Handler Mappings'
- Find and select PHP_via_FastCGI
- On the 'Edit Module Mapping' window, please select 'Request Restrictions'
- Go to the 'Verbs' tab and make sure you input the 'PUT' command
- Click OK twice to confirm (in case there is a pop up disallowing you to continue, please enter the double quote symbols in the executable path)
- Finally, select 'No' at the FastCGI creation selection pop up window
23. If all prerequisites pass, click “install” (Unless you see the next step)
24. If you see an error above like Certificate Server is installed, go to "Server Manager", "Manage", "Remove Roles and Features", remove the check mark in "Active Directory Certificate Services", and walk through the removal. Then retry the prerequisites check
25. After restarting, create a new user from Tools->Active Directory Users and Computers
26. Navigate to the Users section and right click to create a new User
27. Enter the user’s information and then create a password
28. Find this user in the Users List at the right and click to View properties
29. Add a valid email address for the user
30. Go back to the server manager’s home page and click on the “AD FS” panel
31. You‘ll see a note that configuration is pending for ADFS. Click on “More...”
32. Click on “Configure the federation service”
33. Select “Create the first federation server in a federation server farm” and click “Next”
34. Leave the selected account for the next screen
35. Click on the drop-down list to select the installed certificate. Enter a name for the Display Name” and click Next
36. You’ll get a note that “Group Managed Service Accounts are not available [...]”. Click on “Show more” to see the command that has to be ran using PowerShell
37. Run the command. You may have to click on Previous and then Next again to get past the screen
38. Create a new account
39. Select to create a database
40. Review options and click next
41. If all the prerequisite checks pass, click configure
42. Time to setup SAML 2.0. Go to the server manager dashboard and click on Tools->AD FS Management
43. Click to Select the “Services” and right click and select “Edit Federation Service Properties”
44. The “General” tab reveals the “Federation Service Identifier” which is what we need for SAML in eFront
45. Click on the Certificates Entry from the left tree-view, right-click on Token-Signing certificate and then click on View Certificate.
46. In the Details Tab click on Copy to File and the Certificate Export Wizard launches. Click on Next, select DER encoded binary X.509 (.cer) format, and then click Next. Choose where you want to save the certificate and click on Finish.
47. eFront requires a PEM format certificate. So you will need to convert the certificate to PEM format using any appropriate tool or even online tools such as sslshopper. Convert the certificate from DER to PEM format. You will need it during configuration later on. Keep in mind that eFront will work with RSA certificates. DSA certificates are not supported.
48. We need the SAML metadata XML now from eFront. Sign in as admin and go to System settings (1) → Single Sign On (2) → SAML (3).
49. We need what’s next to the URL of SP Metadata XML (4).
50. From the AD FS Manager, go to Trust Relationships → Relying Party Trusts and right click to bring up the context menu. Select Add Relying Party Trust.... to launch the Wizard
51. Click on start to kick off the wizard and then click on the option “Import data about the relying party published online”. Paste the URL found in eFront SAML settings above. It is imperative that you use HTTPS for this. In our example. It’s https://saml.pro.efrontlearning.com/saml/module.php/saml/sp/metadata.php/efront-sp
52. Click on Next and ignore the warning message
53. Enter a descriptive name for the Service Provider, e.g. “eFront”
54. Skip the “multi-factor authentication
55. Permit all users to access this relying party
56. Continue until Finish
57. You should now see the “eFront” entry under “Relying Party Trusts”.
58. Double click on it to bring up its properties modal. Go to the “Advanced” tab and select “SHA-1” as the Secure hash algorithm
59. ADFS 2.0 Claim Rules Configuration: Click on “Edit claim rules”
60. On the first tab, “Issuance Transform Rules”, click on “Add rule”
61. Select Send LDAP Attribute as Claims and click on Next
62. Define the Claim rule name (eg. Get LDAP Attributes) and select Active Directory in Attribute Store. In the Mapping of LDAP attributes to outgoing claim type select the following:
- LDAP Attribute: E-Mail-Addresses, Outgoing Claim Type: E-mail Address
- LDAP Attribute: Given-Name, Outgoing Claim Type: Given Name
- LDAP Attribute: Surname, Outgoing Claim Type: Surname
- LDAP Attribute: User-Principal-Name, Outgoing Claim Type: UPN
63. Click on Finish to create the rule
64. Click on “Add Rule…” again to create a new rule. From the “Claim Rule Template” drop down, select “Transform an Incoming Claim”
65. Define the Claim rule name (eg. “Email to Name ID”) and set “Incoming claim Type” as “E-Mail Address” (the same one from the previous rule), “Outgoing claim type” as “Name ID” and “Outgoing name ID” format as “Email”. Then click on Finish. Have in mind that the email should be defined in all users to achieve proper communication between your ADFS and eFront.
66. Open the AD FS Manager, go to Relying Party Trusts, right-click on “eFront” and click on Edit claim rules
67. Select “Get LDAP Attributes” and click on Edit. Then click on “View Rule Language”
68. Copy the information found there. You will need it in order to find out the Attribute matches for TargetedID, First name, Last name, and Email.
69. Sign into eFront and go to System settings (1) → Single Sign On (2) → SAML (3).
70. Paste the information like as per the example below. The values for TargetedID, First name, Last name and Email can be found from the Claim rule language we copied earlier. The certificate fingerprint can be found by executing an OpenSSL command (openssl x509 -in adfs2.crt -sha1 -noout -fingerprint), or by simply clicking on the “ or paste your SAML certificate (PEM format)” and pasting your certificate.
Identity provider (4) |
https://adfs2.efrontlearning.com/adfs/services/trust |
Certificate fingerprint (5) |
2e47fb8f201f016825a... |
Remote Sign-in URL (6) |
https://adfs2.efrontlearning.com/adfs/ls/ |
Remote Sign-out URL (7) |
https://adfs2.efrontlearning.com/adfs/ls/?wa=wsignout1.0 |
TargetedID (8) |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn |
First name (9) |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname |
Last name (10) |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname |
Email (11) |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress |
71. Now try signing into eFront by clicking on the “Sign in with SAML” link
72. You will be redirected to your ADFS portal and prompted to sign in with your username and password
73. That’s it! An account has been automatically created for you in eFront, and you’re signed in
74. You can click on the log out button to sign out of the Service
75. Debugging the service: If anything doesn’t work, you can consult the AD FS’ log files, found under Server Manager→ AD FS
76. Now, setup LDAP SSO (Efront only): First, make sure that port 389 is open in the server’s firewall
77. Create a user account that will be used to search the AD tree.
78. Let’s call it, for example, “ad_searcher”
79. Go to eFront’s LDAP settings. We need the following information:
- LDAP Server: The IP or domain name of the Active Directory
- LDAP Server Port: This is 389 for standard LDAP or 636 for secure LDAP (ldaps)
- LDAP Bind DN: The Bind DN of a user that has search rights across the whole AD tree. In our example, it’s “CN=AD Searcher,CN=Users,DC=adfs2,DC=efrontlearning,DC=com”, but you can also use the User login name (pre-Windows 2000) as shown in the step above, which for our example is “ADFS2\ad_searcher”
- LDAP Bind Password: The password for the user above
- LDAP Base DN: The Base DN under which the user ad_search will perform searches in the tree. Users outside this base DN will not be retrievable, so the will not be able to sign in
- LDAP Protocol Version: Always 3 for Active Directory
- Login name attribute: The user attribute that will be used as the username. Typically this is “samaccountname” but older versions of Active Directory required “sAMAccountName”
- Full name attribute: Where eFront will read the user’s name from, typically “cn”
- Email attribute: Where eFront will read the user’s name from, typically “mail”
Note: If you can’t find the Bind DN or Base DN, you can use the following technique:
- Bring up the PowerShell
- Run the following command: dsquery user
Or, if you want to search for our “searcher” user (which is more convenient): dsquery user -name ad* That will display the Bind DNs for all users. So, for our example, we locate the user ad_searcher”, whose Bind DN is CN=AD Searcher,CN=Users,DC=adfs2,DC=efrontlearning,DC=com. Removing the first part which is user specific, leaves the Base DN, which is CN=Users,DC=adfs2,DC=efrontlearning,DC=com
Below we can see the data entered:
LDAP server |
adfs2.efrontlearning.com |
LDAP server port |
389 |
LDAP Bind DN |
CN=AD Searcher,CN=Users,DC=adfs2,DC=efrontlearning,DC=com |
LDAP Bind password |
The password for user ad_searcher |
LDAP Base DN |
CN=Users,DC=adfs2,DC=efrontlearning,DC=com |
LDAP Protocol Version |
3 |
Login name attribute |
samaccountname |
Full name attribute |
cn |
Email attribute |
|
80. You can click on “Check settings” to verify that the information entered is correct.
81. That’s it! Now users can sign in to eFront using their AD username and password