HaloCRM

HaloCRM Guides

Guides > ADFS Integration

ADFS Integration

Requirements


To use ADFS to log in to your Halo instance, you need the following components:

  • An Active Directory instance where all users have an email address attribute.
  • A server running Microsoft Server 2012 or 2008. This guide uses screenshots from Server 2012R2, but similar steps should be possible on other versions.

After you meet these basic requirements, you need to install ADFS on your server. Configuring and installing ADFS is beyond the scope of this guide, but is detailed in a Microsoft KB article. You can also follow the YouTube video found here.  


When you have a fully installed ADFS installation, note down the value for the 'SAML 2.0/W-Federation' URL in the ADFS Endpoints section. If you chose the defaults for the installation, this will be '/adfs/ls/'.


Step 1 - Adding a Relying Party Trust


At this point you should be ready to set up the ADFS connection with your Halo instance. The connection between ADFS and Halo is defined using a Relying Party Trust (RPT).

Select the Relying Party Trusts folder from AD FS Management, and add a new Standard Relying Party Trust from the Actions sidebar. This starts the configuration wizard for a new trust.



In the Select Data Source screen, select the last option, Enter Data About the Party Manually.



On the next screen, enter a Display name that you'll recognise in the future, and any notes you want to make.




On the next screen, select the ADFS FS profile radio button.




On the next screen, leave the certificate settings at their defaults.




On the next screen, check the box labelled Enable Support for the SAML 2.0 WebSSO protocol. The service URL will be your authentication server with '/auth/Account/SAMLResponse' added to the end. You can find your authentication server by going to Configuration > Integrations > HaloITSM API (or HaloPSA API or Halo ServiceDesk API depending on your product).





On the next screen, add a Relying party trust identifier of subdomain.Halo.com, replacing subdomain with your Halo subdomain if you are hosted. If you are not hosted, use your usual instance URL with no http / https.




Note: If you enter subdomain.Halo.com, and receive a request failure error, you may need to enter your subdomain as https://subdomain.Halo.com.

On the next screen, you may configure multi-factor authentication but this is beyond the scope of this guide.




On the next screen, select the Permit all users to access this relying party radio button.




On the next two screens, the wizard will display an overview of your settings. On the final screen use the Close button to exit and open the Claim Rules editor.




Step 2 - Creating claim rules


Once the relying party trust has been created, you can create the claim rules and update the RPT with minor changes that aren't set by the wizard. By default the claim rule editor opens once you created the trust.




To create a new rule, click on Add Rule. Create a Send LDAP Attributes as Claims rule.




On the next screen, using Active Directory as your attribute store, do the following:
  1. From the LDAP Attribute column, select E-Mail Addresses.
  2. From the Outgoing Claim Type, select E-Mail Address.




Click on OK to save the new rule. 

Create another new rule by clicking Add Rule, this time selecting Transform an Incoming Claim as the template.




On the next screen:
  1. Select E-mail Address as the Incoming Claim Type.
  2. For Outgoing Claim Type, select Name ID.
3. For Outgoing Name ID Format, select Email.
  Leave the rule to the default of Pass through all claim values.




Finally, click OK to create the claim rule, and then OK again to finish creating rules.



Step 3 - Adjusting the trust settings


You still need to adjust a few settings on your relying party trust. To access these settings, select Properties from the Actions sidebar while you have the RPT selected.

In the Advanced tab, make sure SHA-256 is specified as the secure hash algorithm.




In the Endpoints tab, click on add SAML to add a new endpoint. 

For the Endpoint type, select SAML Logout. 

For the Binding, choose POST. 

For the Trusted URL, create a URL using:
  1. The web address of your ADFS server
  2. The ADFS SAML endpoint you noted earlier
  3. The string '?wa=wsignout1.0'
  The URL should look something like this: https://sso.yourdomain.tld/adfs/ls/?wa=wsignout1.0.


Confirm you changes by clicking OK on the endpoint and the RPT properties. You should now have a working RPT for Halo.

Note: Your instance of ADFS may have security settings in place that require all Federation Services Properties to be filled out and published in the metadata. Check with your team to see if this applies in your instance.  If it is, be sure to check the Publish organization information in federation metadata box.


Step 4 - Configuring Halo


Navigate to: ‘Configuration > Integrations > AD FS‘ within Halo.

Fill in your Login URL with the URL your users use to login to your AD FS server. Usually this follows the format: ‘https://sso.company.com/adfs/ls’.

The logout URL usually follows the format: ‘https://sso.company.com/adfs/ls/?wa=wsignout1.0’ .

Run this powershell command on your ADFS server to obtain the AD FS thumbprint: ‘Get-AdfsCertificate -CertificateType Token-Signing’.

It is best to leave the automatic redirect tick box unticked until logins and logouts have been tested.

Make sure the Thumbprint is entered fully in Uppercase Characters.



You should now have a working ADFS SSO implementation for Halo.


Popular Guides

Pin It on Pinterest