Lightweight Directory Access Protocol (LDAP) is an internet standard that provides access to information from different computer systems and applications. LDAP uses a set of protocols to access information directories and retrieve information. A directory is like a database but contains information that is more descriptive and attribute-based. Information in a directory is generally read more often than it is written or modified. LDAP allows an application, running on a school's computer platform, to obtain information such as usernames and passwords.

Centralizing this type of information simplifies your job by providing a single point of administration. User information is provided in a single location, reducing the storage of duplicate information. This, in turn, reduces maintenance needs. LDAP authentication also enables users to have a single login and password to access a number of different applications.

More on creating authentication providers

About LDAPS and LDAP with StartTLS

Previous versions of Learn allowed adding plain LDAP without encryption ("NoSSL.") Beginning in 3900.84, new "NoSSL" providers can't be created and while existing ones will keep working, if updated to use LDAPS/StartTLS it won't be possible to change them back to NoSSL. Anthology recommends customers still using NoSSL promptly migrate to a secure configuration.

The original version of LDAP dates to the 1980s and did not support any connection security. LDAPS was the first attempt to bolt-on what was then known as "SSL" (today: TLS.) LDAPS uses a special secure-only port. Connection establishment requires use of the correct port depending on if it is secure or insecure. This became less relevant over time as use of insecure connectivity declined.

LDAPS was never formally standardized. The IETF standardized "LDAP with encryption" through a completely different approach in RFC 2830 using StartTLS. In this arrangement, the LDAP server only listens to one port. The LDAP client connects without security, then sends a "STARTLS" command and the LDAP server and client negotiate TLS.

The choice of LDAPS or StartTLS needs to be made by each institution according to its needs and what is supported by your directory server or other architectural considerations. If either option can be chosen, generally StartTLS is preferred because it was standardized by IETF and is newer. Some security experts consider LDAPS to be outdated, and to have been implicitly deprecated by the dissemination of RFC 2830 but there is not a uniform consensus.

Security Prerequisites

You need a commercially-signed certificate with a complete chain of trust to a Certificate Authority trusted by the Java 11 default "CACerts" keystore, or the connection will fail. Additional certificates may not be installed in the keystores. Self-signed certificates are not supported.

Your Certificate Authority (CA) will usually sign your certificate not with its highly trusted root certificate, but an intermediate certificate itself signed by this root. This intermediate must be sent together with the server certificate because its presence is required to complete the chain of verification to a root of trust. Typically, this is done by appending the intermediary certificates to the server certificate. Consult the documentation for your LDAP directory server and that of your certificate issuer for more information.

  • The LDAP directory server and all middleboxes need to support cipher suites accepted by Java 11 and higher. For example: TLS 1.0 is no longer supported.
  • The LDAP directory server and all middleboxes need to accept incoming connections from the SaaS egress IPs for your region. Contact Blackboard Support for this information.

Configure an LDAP Provider

  1. Provide your LDAP Server URL, for example, ldaps:// for LDAPS or ldap:// for LDAP with StartTLS.
  2. Set the SSL Version to StartTLS or LDAPS.
  3. Provide the Base Search DN-the starting point in the LDAP directory structure for searching for a Learn user. A subtree search is performed from here, for example, dc=people,dc=example,dc=edu. You can create and configure two entirely separate LDAP providers with different Base Search DNs that point to the same physical LDAP server. You might do this if you want to reduce the load on the LDAP server by 'branding' to, then setting up the LDAP provider to search only dc=people,dc=education, dc=example,dc=edu instead of the whole tree.

    You can add multiple LDAP providers with the same Base Search DNs that point to different physical servers. If one LDAP server is unresponsive, the framework queries the next one. More on provider order.

  4. Provide the Search Attribute-the LDAP attribute containing the value that maps to the Learn Username or Batch Uid set in the Create Provider step. This property is domain specific. For Active Directory (AD), the property used is typically sAMAccountName, and for Novell, typically uid. For Active Directory, most clients integrating use sAMAccountName as the Search Attribute. This maps to the old style (pre-win2k) login name that has a maximum of 20 characters. Your AD Domain administrator is able to confirm if this is the correct attribute or if you can or should use userPrincipalName.

    Some LDAP servers such as Active Directory require a privileged user to connect to the directory. The LDAP provider requires the Distinguished Name (DN) and password for the user. The two usual options for connecting using a privileged user include:

    • Create a new user within the directory. Assign this user the right of read access only. Use this user account as the privileged user.
    • Use an existing directory user as the privileged user.

    This account needs to access the LDAP server for each user that attempts to log in to Blackboard. As a best practice, select the User can't change password and Password Never Expires options.

    This is what is referred to as a service account so the LDAP administrator may have a special location in the directory for these types of accounts.

    When first setting up the account, use a basic password, and only after you have confirmed the configuration is working, change the password to something stronger. Keep in mind that issues can occur with special characters such as # and @.

  5. Optionally, set the:
    • Search Using Privileged User as Yes. The default is No. When searching for the FDN of the user to authenticate, the LDAP provider binds to the LDAP server as a privileged (specified) user.
    • Provide the Privileged User DN. If the Search Using Privileged User is set to Yes, this must be set. For example: cn=BlackboardLDAP,ou=Special Users, dc= example,dc=edu or
    • Provide the Privileged User Password. If the Search Using Privileged User is set to Yes, this must be set. This represents the password of the user in Privileged User DN.
  6. Optionally, set the Advanced Settings.
    • Connection Timeout needs a minimum of 15000 milliseconds. This represents the time in milliseconds to wait before canceling an LDAP request.
    • Dereference Aliases as Always, Finding, or Searching. The default is Never. This property defines how aliases are dereferenced during search operations.
      • Never: Never dereference aliases.
      • Always: Always dereference aliases.
      • Finding: Dereference aliases only during name resolution-that is, while locating the target entry.
      • Searching: Dereference aliases once name resolution is completed-that is, after locating the target entry.
    • Referrals as Follow or Throw. The default is Ignore. This property specifies how referrals should be handled by the provider.
      • Ignore: Ignore referrals if they appear in results.
      • Follow: Automatically follow any referrals.
      • Throw: Throw a Java ReferralException for each referral. This results in an error condition.
    • Referral Limit as 5 is the default. This property specifies maximum number of referrals to follow. A setting of zero is an invalid value. You can set this property only if the Referrals property is set to Follow or Throw.
  7. Select Submit to save the configuration.

    Before making the new authentication provider Active, select Test Connection Settings from the contextual menu to confirm that the configuration works as expected.