Key

This line was added.

This line was removed.

Formatting was changed.

Tip

icon

false

Path to function: Management >Connections > Add > LDAP

OpenAthens can connect directly to an LDAP server so that you do not have to issue accounts yourself. It can connect to anything that uses the personal accounts for your users (you will still need your OpenAthens administrator account though). Anything that uses standard LDAP protocols so includes things such as ActiveDirectory and OpenLDAP.

To connect your LDAP:

...

is acceptable so this works very well with ActiveDirectory too.

As well as the ability to use local accounts instead of maintaining a separate set of credentials, accesses to federated resources that already involve discovery (identifying the users' home organisation) will take the user directly to your LDAP login at our authentication point - no further discovery is required.

When you're ready to go live, check both the live and visible boxes and then save. Your new connection should be available on the authentication point in a few seconds.

Testing

Since OpenAthens accounts will still work if entered (see below), some sites are happy to test by setting the connector to live & visible for periods of time. You can also use debug mode to make all connections visible and selectable by you without anything being visible to your end-users.

How to use LDAP alongside OpenAthens accounts or other connections

If this is your only local connection, once you set this as both live and visible it becomes the expected way for users to sign into OpenAthens where the system knows the user is yours - e.g. where the user has selected your organisation from a WAYF on a federated resource or remembers a users previous choice. Where the system does not know the user is yours only the OpenAthens account login will appear, but the user can find you via the search box - once selected the user is taken to your connection.

Users with OpenAthens accounts from your organisation can still sign in by entering their username and password in the same login box as the LDAP accounts. This may affect your choice of label text.

Should you need to show more than one LDAP option, the user will see a drop down list above the credentials boxes. This will contain all LDAP connections set as live and visible.

Image Added

If you need a mix of LDAP and SAML connections - e.g. LDAP for students and ADFS for staff, this is presented as a selection box in an overlay. Local connections are remembered if the user goes on to successfully sign in using it; if the user does not successfully sign in for any reason, the authentication point will forget their preference and present the chooser again next time (this is to prevent users who select the wrong option from getting stuck at a login they cannot use).

Image Added

In these cases, selecting the OpenAthens option will show the first LDAP connection and the OpenAthens credentials will be accepted there.

The address where OpenAthens can connect to your server. This address will need to be accessible by our services from outside of your network.

Server port

The port that your server uses for LDAP traffic. Standard ports are selected when you change protocol. You can specify a non-standard port if

nessisary

necessary but this can affect security.

Connection type

The form of security used. StartTLS is the standard but ldaps:// can be chosen

for older systems

if you prefer.

The minimum supported version of TLS is 1.2.

Admin bind DN

The full distinguished name of a user that can connect and view all the users you need to authenticate, e.g:

cn=openathens,cn=users,dn=ad,dn=yourdomain,dn=net

Bind password

The password for the user specified in the admin bind

Base DN

The distinguished name of your directory, e.g:

dn=ad,dn=yourdomain,dn=net

Filter

Allows you to specify the username field

and optionally include other requirements.

Status

Live

, plus limitations where necessary. The field you identify as =${uid} will be used as the username in login dialogs

Display name attribute

This defaults in AD to be 'sAMAccountName' and in LDAP to 'cn'. It is the value displayed in account lists and in audit. You can choose any attribute.

Unique user attribute

This should be an attribute that will always be unique to that user and it is used in the generation of targetedIDs and statistics. It defaults in AD to 'objectGUID' and in LDAP to 'cn'. If you are migrating from another local authentication system, you may want this to match your old setting.

Pseudonymous identifiers are recommended where they are available.

Salt value

The salt used to generate a targetedID for users authenticated by this connection.

Example filters

Instead of specifying only a username field, the use of a filter allows compatibility with a greater variety of LDAP structures - e.g. where including all valid users requires binding to a node that will also include invalid users, the filter can be set to exclude the invalid users.

cn=${uid} - The default LDAP filter using common name as the username

(&(objectCategory=Person)(sAMAccountName=${uid})) - The Default ActiveDirectory filter uses the Windows login as the username and requires the user to have an object category of person.

Technical information for your IT team:

There is a read-only admin bind to your directory to check status and read the available attributes for mapping

During user authentications

There is a read-only admin bind to your directory to discover the FQDN of the user based on whichever attribute you have defined as the userID

Once the user's FQDN is known, it is used with the user's password to bind for authentication and request of any mapped attributes

Connections from us will come from the following IP addresses (35.189.71.17 and 35.224.184.162) and changes to these would be communicated in advance.

The admin bind used MUST have sufficient access to search for accounts and read the FQDN of any user account (that should have access).

The admin bind used SHOULD have sufficient access to read all mappable attributes for user accounts so that typeaheads work when setting up mappings and permission set rules.

The only significant difference between StartTLS and ldaps:// in operation is that with StartTLS you only need to listen on one port instead of two.

Anything to watch out for?

AD will truncate sAMAccountName before release if it is over 20 characters. This may affect your choice of unique user attribute.

TLS versions before 1.2 are not supported.

Pseudonymous?

Pseudonymous identifiers such as objectGUID are recommended for the unique user attribute to avoid potential problems with data protection legislation as that identifier will live on for a time in the audit trail after other mapped attributes are cleared.