Active Directory (AD) integration

In this Article


Finalsite’s Active Directory integration is used to synchronize user accounts between a school’s Active Directory system and Finalsite. This is most commonly useful for Faculty/Student account creation. We synchronize a small set of datapoints that are available in Active Directory. The mapping is flexible so it can be modified. If additional datapoints are required/desired, we can add them, in most cases.

The fields we currently sync are:

  • GivenName

  • Sn

  • Cn

  • Mail

  • telephoneNumber

  • userPrincipalName

  • wWWHomePage

  • Department

  • sAMAccountName

  • memberOf

  • objectGUID (primary identifier)

  • Title

  • Company

Note: The integration is also able to create Admin User accounts for users who need to be able to log in to Finalsite as a Site Administrator. This falls under the same “Data Filtering” principles discussed below: we will need an authoritative attribute/OU to be able to set these reliably in an automated fashion.

Data filtering and targeting

In order to properly target your data, users need to be setup in particular OUs that we can target. Ideally, create a single or multiple OUs specifically for Finalsite integration needs. We do have some flexibility in setting the filter for the query, and some additional options in the custom mapping. However, we are not able to specifically target only certain members contained in an OU unless we have a consistent datapoint to base that on. Tidy organization of the users you intend to sync will help ensure a smooth deployment and desired sync behaviors.

Deployment process

In order to test the integration prior to deployment, we will set up a clone site so we can ensure we are targeting the appropriate users and mapping the data as desired.  If you have existing constituents in roles that we will be synchronizing, there may need to be some work to add the unique identifier from AD (objectGUID) as an Import ID to those users to avoid duplication of accounts when the integration is deployed.

Account access

We will need you to work with us to ensure we have an account that can perform the queries needed in your AD system. We also require that the connection is done over SSL with a valid SSL certificate from a trusted certificate authority (not self-signed) to ensure sensitive data is kept secure.

In order to test and subsequently implement the LDAP integration, you will need to provide Finalsite with the following information so we can configure the settings in Integrated Services Manager:

  • The FQDN of your server (e.g. ldap.finalsite.com)

  • The port number you have chosen (default: 636 for LDAP over SSL)

  • The full DN of your test user (e.g. cn=FinalsiteUser,ou=Users,dc=finalsite,dc=com)

Alternatively (AD only), provide the userPrincipalName of your test user (e.g. John.Doe@finalsite.com). Please note the userPrincipalName is NOT necessarily the user's email address. We also require the test user's password.

It is also recommended that you whitelist these IP subnets as a trusted source for your firewall configuration:

  • 34.73.130.72/29 - Production Range for access for your live site

  • 34.75.25.79/32 - Staging environment for deployment efforts

  • 34.73.80.239 - Staging environment for deployment efforts

ADFS authentication

Finalsite has recently added a way to allow constituents/users authenticate into Finalsite using your in-house ADFS system as the Identity Provider. This is is configurable by admin group or constituent role, so there is some flexibility in how your users will authenticate. This is done using a SAML 2.0 connection.

In general, to configure this integration, the appropriate metadata and keys need to be shared between Finalsite and you. We configure the integration on our end and ensure we are matching the appropriate account datapoints (typically, username). As there are a number of ways ADFS systems can vary, it may take some back and forth to ensure all is configured properly so it is best to include your IT team directly if looking to configure and deploy this integration. Please note that this feature does not provision accounts or set permissions. We recommend utilizing the Active Directory integration for these features.

In response to feedback about having to enter the username a second time after being redirected, we recently released the ability to trigger login via external services (ADFS, SAML) through a direct link.

To create the external login link, go to Integrated Services Manager > Authentication and choose the appropriate authentication configuration. You will find the URL to use for your link in the "Direct SAML login URL" field.

Location of Direct SAML login URL highlighted on Authentication configuration details screen

Use that URL to set up a link on your site and/or login page to direct users with that authentication method to begin the login process that way.

An important thing to note is that, at this time, this won't intelligently redirect users who clicked on a direct link to a protected page while not logged into Finalsite. Users who click the direct SAML link to login with the external source, even when they encounter the login page via a different protected page, will always be redirected to their default landing page.

Please also note that this is for constituent logins and not for admin login.

Additional features

LDAP authentication

You can currently use the integration in tandem with our LDAP Authentication feature so that users can log into Finalsite via your LDAP server. This keeps management of user credentials in Active Directory.

“Off feed” behavior with off-feed utility

This integration can utilize the off-feed utility.

Was this article helpful?
2 out of 5 found this helpful

Comments

0 comments

Please Sign in to leave a comment if you don't see the comment box below.