To fully enable single sign-on, you must give your company email domain to your iMeet® Central representative so that they may provision your account properly. Send an email to support@imeetcentral.com with this information.
iMeet® Central can utilize the technologies in the latest Active Directory Federation Services 2.0 from Microsoft to enable a seamless Single Sign-On solution. This allows for centralized management of user accounts in Microsoft Active Directory. Group memberships may also be synchronized, reducing administrative overhead. Familiarize yourself with the documentation at the following links. To utilize this technology, you will need MS Active Directory set up. We will be installing ADFS 2.0 (and IIS as a dependency).
- Active Directory Federation Services (AD FS) 2.0
- Microsoft Active Directory Overview
- Create a Self-Signed Server Certificate
Jump to:
ADFS Installation and Configuration
Testing SSO with an Active Directory User
Adding Custom Claim Rules
Creating a Rule to Permit or Deny Users Based on an Incoming Claim
ADFS Firefox and Chrome Compatibility
Troubleshooting Tips
ADFS installation and configuration
1. You will need to be administrator on your AD server. On that machine, download ADFS 2.0 and save the file to your desktop.
2. Double-click the AdfsSetup.exe to start the ADFS installation Wizard
3. Choose your server Role. You need at a minimum a Federation Server. If you don't wish to expose IIS on your AD server to the internet (ports 80 and 443 for HTTP and HTTPS respectively) you can first set up a Federation Server behind the firewall (can be on the AD machine) and then build a second Federation Server Proxy that lives in the DMZ and passes requests through the firewall to the Federation Server.
4. When the ADFS setup is complete, check the box to Start the AD FS 2.0 Management snap in... and click Finish.
5. Once ADFS is installed the Federation Service Properties window must be adjusted. Make sure to change the Federation Service identifier to HTTPS rather than HTTP (by default HTTP is set). Without HTTPS you will get an HTTP error (see troubleshooting tips). Click on ADFS 2.0 and then choose Edit Federation Service properties in the rightmost pane.
6. You should now have AD FS 2.0 Management open. If not, navigate to Start > Administrative Tools > AD FS 2.0 Management.
This is the main ADFS control application. We will begin by clicking AD FS 2.0 Federation Server Configuration Wizard which will walk us through the process of configuring ADFS and enabling us to connect ADFS to both the internet via IIS and to AD on the back end.
7. This is a new ADFS server so we'll select Create a new Federation Service.
8. For high availability it is recommended to evaluate creating a federation server farm. For this installation we will keep things simple and select the stand-alone federation server option.
9. This is where you will need to select the SSL certificate for the server. If the SSL certificate field is empty, you will need to create one before moving on. This is explained in Steps 9-11. Otherwise, click Next and skip to Step 12 to complete the configuration.
10. To create a SSL certificate, navigate to to Start > Administrative Tools > Server Manager > Roles > Web Server (IIS) > Internet Information Services Manager (IIS) and open Server Certificates
11. Click Create Self-Signed Certificate
12. Specify a name for the certificate and click OK. You should now be able to continue with the ADFS configuration and continue on.
13. Click Close when the configuration is complete.
14. Now we will configure SSO on the iMeet® Central side. As a Company Administrator, navigate to Company Settings > Advanced > Single Sign On where you will see the below options. You will need to populate this data with the URLs to the ADFS services that we just created. Steps 14-17 will show you how you can access this information.
- Enable SAMLv2 Single Sign On: This must be enabled to allow SSO
- SSO URL: Paste your entityID here. For example: http://ADFSTEST.ssotest.local/adfs/services/trust
- SSO Login URL: Paste your SSO login URL here. For example: https://adfstest.ssotest.local/adfs/ls/
- Thumbprint: Paste your thumbprint here
- Display a link to your SAMLv2 login page: this will display a SSO login link in your company login page
To quickly find this information, browse to your federation metadata URL which can be found in the ADFS MMC\Endpoints|Metadata|Type:Federation Metadata. Or go to this link after filling in your company name: https://[servername]/FederationMetadata/2007-06/FederationMetadata.xml
15. We will need the certificate thumbprint to use inside of the SSO settings page in iMeet® Central. Open ADFS 2.0 Management and navigate to AD FS 2.0 > Service > Certificates > Token-signing > right-click and View Certificate.
16. Scroll down the the thumbprint. Type CTRL-C to copy the thumbprint.
17. Next, locate the SSO URL. This can be found in the meta data URL page as seen below.
18. Next, locate your SSO Login URL. This can be found in the meta data URL page as seen below.
19. You will also need to give your company email domain to your iMeet® Central representative so they may provision your account properly. Open a Support ticket to provide us with this information. If this step is missed or the email domain is incorrect, you should see an error message similar to this when logging in via SSO.
20. Once configuration is complete you will need to work in the Certificates and Relying Party Trusts sections. Open ADFS 2.0 > Trust Relationships > Relying Party Trusts > click Add a Relying Party Trust which begins the Wizard.
21. Click Start
22. Select your data source which will be a iMeet® Central URL of this form: https://[companyname].imeetcentral.com/saml2-metadata.php .
This will automatically configure most of the Relying Party Trust for you.
23. Type in a name and click Next
24. We will Permit all users to access this relying party, thus allowing all users of AD to also use iMeet® Central via SSO. You can create further rules here such as one to permit only certain AD groups to login via SSO (see Creating a Rule to Permit or Deny Users Based on an Incoming Claim.
25. Check the box to Open the Edit Claim Rules... and click Close to continue.
26. Upon completion we now will need to open the Claim Rules editor in order to build some mappings from AD attributes to iMeet® Central properties. Two claim rules are required for single-sign-on with iMeet® Central.
- nameID
27. Click Edit Claim Rules... for your relying party trust.
28. Click Add Rule
29. Select Send LDAP Attributes as Claims and click Next.
30. Name this rule email and fill in the rest of the fields as displayed below and click Finish.
31. Click Add Rule again to create the second required rule. This time, select the Transform and Incoming Claim template.
32. Name this rule nameid and fill in the rest of the fields as displayed below and click Finish.
33. You should now have the two required claim rules and should be ready to test the SSO configuration.
Testing SSO with an Active Directory user
At this point we are complete with the configuration. Now we can browse to https://[companyname].imeetcentral.com/sso and we will then be prompted with an NTLM login box. (If we are already signed into the domain this may not appear). The credentials entered here are transmitted to your ADFS server which then validates the credentials. Upon passing, the user will then be passed an authentication token and redirected back to iMeet® Central and logged in. Their credentials are not sent to iMeet® Central
1. Create a new user in Active Directory
2. Fill in the user details as follows
3. After creating the user profile, edit the profile and add an email address which is what iMeet® Central uses to authenticate the user.
4. Go to your SSO login page: https://[companyname].imeetcentral.com/sso) and log in with the user credentials
5. If successful, you should be logged into iMeet® Central
Adding custom claim rules
Custom claim rules can be added to map Active Directory user fields to iMeet® Central user profile fields. Here are some examples of claim rules you can build. The following fields can be mapped to iMeet® Central.
- company
- phone
- country_code
- country_name
- fullname (you can use firstname and lastname OR fullname)
- firstname
- lastname
- address1
- address2
- city
- state
- zipcode
- job_title
- company_department
- mobile_phone
1. Navigate to Start > Administrative Tools > AD FS 2.0 Management.
2. In the console tree, under AD FS 2.0 > Trust Relationships > Relying Party Trusts, click a specific trust in the list where you want to create this rule.
3. Click Edit Claim Rules
4. Click Add Rule
5. Select Send Claims Using a Custom Rule and click Next.
6. Fill in the custom rule name and custom rule .
Examples of Custom Claims Rules
Mapping to First and Last name field in iMeet® Central:
c:[Type == c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("fullname"),
query = ";displayName;{0}", param = c.Value);
Mapping to Company field in iMeet® Central:
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("company"),
query = ";company;{0}", param = c.Value);
Mapping to Internal Member Group in iMeet® Central:
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("memberof"),
query = ";memberOf;{0}", param = c.Value);
Creating a rule to permit or deny users based on an Incoming Claim
Using the Permit or Deny Users Based on an Incoming Claim rule template in Active Directory Federation Services (AD FS) 2.0, you can create an authorization rule that will grant or deny user’s access to the relying party based on the type and value of an incoming claim. For example, you can use this rule template to create a rule that will permit only users that have a group claim with a value of Domain Admins to access the relying party. If you want to permit all users to access the relying party, use the Permit All Users rule template.
You can use the following procedure to create a claim rule with the AD FS 2.0 Management snap-in. Membership in Administrators, or equivalent, on the local computer is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups.
1. Navigate to Start > Administrative Tools > AD FS 2.0 Management.
2. In the console tree, under AD FS 2.0 > Trust Relationships > Relying Party Trusts, click a specific trust in the list where you want to create this rule.
3. Click Edit Claim Rules
4. In the Edit Claim Rules dialog box, make sure Permit Access to All Users is highlighted, click Remove Rule
5. In the Edit Claim Rules dialog box, click the Issuance Authorization Rules tab or the Delegation Authorization Rules tab (based on the type of authorization rule you require), and then click Add Rule to start the Add Authorization Claim Rule Wizard.
6. On the Select Rule Template page, under Claim rule template, select Permit or Deny Users Based on an Incoming Claim from the list, and then click Next.
7. On the Configure Rule page under Claim rule name type the display name for this rule, in Incoming claim type select a claim type in the list, under Incoming claim value type a value or click Browse (if it is available) and select a value, and then select one of the following options, depending on the needs of your organization:
- Permit access to users with this incoming claim
- Deny access to users with this incoming claim
For the purpose of this document we are going to go with Permit access to users with this incoming claim. For Incoming Claim Type choose Group SID, then click Browse to search/select the Security Group you want to Permit access to Login into iMeet® Central. Click Finish.
8. In the Edit Claim Rules dialog box, click Apply, and then OK to save the rule.
9. Test your rule by going to your SSO login page: https://[companyname].imeetcentral.com/sso and log in with the user credentials.
Firefox and Chrome compatibility
To be able to use ADFS SSO with either Firefox or Chrome, you will need to turn Extended Protection off, in IIS.
1. To turn Extended Protection off, on the ADFS server, launch IIS Manager, then, on the left side tree view, access Sites > Default Web Site > adfs > ls.
2. Once you’ve selected the /adfs/ls folder, double-click the Authentication icon, then right-click Windows Authentication and select Advanced Settings.
3. On the Advanced Settings dialog, choose Off for Extended Protection. 
Troubleshooting tips
If you run into any issues logging into iMeet® Central via SSO after following this guide, review the following troubleshooting tips.
1. Review the installation and configuration steps above to ensure that they are accurate and complete.
2. Remove any custom claim rules (if they have been added) and try again. This will ensure that the issue is not related to any custom claim rules you have set.
3. Open Microsoft Event Viewer and view the ADFS 2.0 logs for information on what is not working.
4. If you continue to have issues, take a screenshot of the error you are encountering and send an email to support@imeetcentral.com.
5. Upon updating a person's profile in Active Directory make sure to restart your ADFS server. For example, if a user changes their last name will need to update their profile in Active Directory and change the appropriate fields in their iMeet® Central profile. Once updated, try rebooting ADFS.
6. Seeing the error below?
It's likely that the self-signed certificate has not been created.
To fix:
- Open IIS and then click on your server name
- Go down to IIS and open server certificates. Choose "Create self signed certificate".
- Give it a friendly name like ADFS Certificate.
- Re-run the federation Setup Configuration Wizard.
7. Seeing the error below?
This is expected when using a self signed cert.
If you want to use a real cer and eliminate this error you must change the cer within IIS for the Default website (or ADFS site if you are hosting other sites).
To accomplish this follow the directions below:
- Open IIS and then click certificate the server name, and then open server certificates.
- Request a cert of 2048bit
- Create certificate request and complete the request.
- Once complete, go to 'default website (or ADFS site) > edit site > bindings > HTTPS > edit' and choose the new Cert.
Do not change the certificate used for SSO within the ADFS Man
8. The error below indicates the Claims rules are in the wrong order. Email should be first, then NameID second.
Also, it could indicate that the users email address field on the AD server is empty.
9. The error below occurs when the SSO username / password box is canceled.
10. The error below indicates the SSO Certificate Fingerprint within CD does not match the fingerprint within ADFS Token Signing Certificate.
11. The error below indicates that the Federation Server Properties within ADFS is using HTTP rather than HTTPS.
12. The error below indicates that the SSO login URL is incorrect.
13. The error below indicates that the SSO Login URL is typed in as HTTP rather than HTTPS.
14. The error below indicates that port 443 (https) is closed to the server or the ADFS Server's Public A Record is incorrect.
