Enabling authentication chaining between RADIUS and LDAP for HTTP access services
With HCL SafeLinx, RADIUS authentication profiles that are used by HTTP access services can be linked to existing LDAP authentication profiles. Enabling this type of authentication chaining allows SafeLinx to verify a user's LDAP credentials before it processes the RADIUS authentication. You can specify the LDAP user ID attribute that you want SafeLinx to use in generating LTPA tokens for single sign-on. RADIUS to LDAP authentication chaining is supported for HTTP access services only.
When authentication chaining is configured, user requests to sign in to the HTTP access service are initially processed through the primary RADIUS authentication profile. The RADIUS authentication method on the SafeLinx Server receives the client authentication request and automatically passes the request to the LDAP authentication method. If the LDAP lookup fails, access is denied and an error is returned. If the LDAP lookup is successful, RADIUS authentication proceeds. If the RADIUS authentication succeeds, the SafeLinx Server generates an LTPA SSO token from the value of the user ID attribute that it retrieved from the LDAP server.
Typically, LTPA tokens carry the value of a user's full Distinguished Name (DN), but you can select a different attribute to retrieve from the user record. For example, for a Domino® LDAP directory, you might specify the attribute NotesId.
The SafeLinx Server caches the value of the specified user ID attribute in the Principal user account attribute of the user's SafeLinx record. SafeLinx always uses the cached value, rather than looking it up the value in the directory, so lookups occur only if no value exists. By default, SafeLinx clears the Principal user account value only if a user fails authentication. In that case, the next time that the user attempts to sign in, an LDAP search is required. If you want, you can force SafeLinx to query LDAP for the user attribute every time a user signs in. To force LDAP queries every time a user attempt to authenticate, disable caching by clearing the field Cache user's enterprise distinguished name on the General tab of the LDAP bind authentication profile.
To enable authentication chaining between a RADIUS server and an LDAP server, complete the following procedure:
- From the SafeLinx Administrator Resources pane, expand the OU in which the authentication profile is defined, right-click Authentication profile, and then click Open.
- From the Authentication profile window, select the RADIUS authentication profile that you want to configure and then click Properties.
- Click the LTPA/SSO tab, select Enable LTPA, and configure the settings for using LTPA in your environment. For more information about using LTPA with SafeLinx, see Lightweight third-party authentication support.
- In the LTPA user token identification field, select the attribute that SafeLinx uses to generate the token.
- In the LDAP-bind authentication field, click the name of the LDAP-bind authentication profile you want to use with this RADIUS profile.
- Optional: Open the properties pages for the
LDAP-bind authentication profile that you selected in Step 5, click
the LDAP tab, and select Disable
If you enable authentication chaining, the RADIUS authentication profile automatically validates the user ID and password through the configured LDAP server. Depending on your requirements, you might want to disable password verification in the LDAP profile to eliminate a redundant authentication check. If the following conditions apply to your environment, you might want to disable password verification in the LDAP-bind profile:
- The RADIUS server authenticates against the same LDAP server that is referenced in the LDAP-bind profile
- Your organization's security policy considers that the RADIUS credentials are sufficient for authentication
- The credentials that users submit to authenticate with the RADIUS server differ from the credentials that are used to authenticate with the LDAP server. SafeLinx challenges devices for one set of credentials only. Unless the RADIUS and LDAP credentials are synchronized, one set fails if you require redundant authentication.