Understanding External Authentication

The DirX Directory service can use external services such as Windows or RACF to authenticate the users that perform a bind to the directory. In external authentication, the DirX Directory service forwards an LDAPv3 bind request performed with simple bind credentials (distinguished name (DN) and a password) to an external authentication service via the external service’s protocol, for example, via the Kerberos protocol used in Windows domains. This action links the DSA to the external service’s login facility, which performs the client authentication procedure. On success, a mapping procedure determines the authorization identity used for access control decisions in subsequent directory operations. The following figure illustrates the process.

Performing External Authentication
Figure 1. Performing External Authentication

As shown in the figure, the DirX Directory service checks an incoming simple bind request against local configuration information contained in an external authentication configuration file to determine if the bind request matches the pre-requisites for external authentication specified in the file and either authenticates the request locally according to the X.500 bind procedure - the DSA checks the DN and user password transmitted in the bind credentials against the DirX Directory database - or forwards the credentials to an external authentication service. The local configuration also describes mapping rules to be applied to the DN prior to forwarding it to the external service and/or rules to be applied to map the externally authenticated DN onto the X.500 access control identity after successful external authentication.

Why Use External Authentication?

External authentication permits users to establish authenticated connections to the directory service (and thus to have access to entries in the DIT) without the need for special set of directory service credentials.The target is not to provide a single-sign-on service.

What Kinds of Bind Requests Can Be Externally Authenticated?

In general, only simple LDAPv3 bind operations targeted to the DirX Directory LDAP server and performed over LDAP or SSL/TLS-protected LDAP can be forwarded for external authentication.Bind requests performed using another credential choice – like the simple protected bind operations performed directly over DAP by the dirxcp command line tool – are not subject to forwarding, nor are bind operations performed via RPC by the administrative command line tool dirxadm.

How Is External Authentication Controlled?

The information that controls how external authentication is performed is stored in the external authentication configuration file install_path/server/conf/dirxextauth.cfg.The DirX Directory DSA looks for this file on startup and follows the configuration information specified in the file.You must create this file to enable external authentication.

The external authentication configuration file contains information about:

  • The external authentication service to use

  • The LDAP servers that are allowed to forward simple bind requests for external authentication

  • The procedure to use if an external authentication fails

  • The conditions that must be met in order to forward a particular bind and the rules for constructing the target system’s account name.

The DirX Directory External Authentication provides detailed usage information about the external authentication configuration file and its parameters and provides some examples.

What External Authentication Services are Supported?

The DirX Directory service currently supports the following external authentication services:

  • Windows authentication, where the DirX Directory service runs on a Windows platform and the DirX Directory DSA process checks incoming bind requests and conditionally forwards them to the Windows domain controller by calling the Windows LogonUser API.

  • RACF authentication, where the DirX Directory service is integrated with the RACF service via LDAPv3 access to the Secure-Way LDAP server running on a RACF host.

Note that the DirX Directory service can handle only one external authentication service at a time.

How Does External Authentication to Windows Work?

When you configure for Windows external authentication, you specify the OID of an attribute type that holds an entry’s Windows account information - the domain name and the username – in a parameter in the configuration file (named WIN_ACCOUNT_AT). This attribute type must be indexed and its syntax must be Directory String.

The DirX Directory DSA supports two strategies for determining whether a particular bind request is subject to forwarding to Windows:

  • Credentials-DN-Strategy - the bind credentials contain the Windows user and domain name and the mapping onto an X.500 entry DN is performed after the external authentication succeeds. If the configuration enables this strategy, each simple bind request that fulfills the following condition is forwarded to Windows: the DN in the credentials consists of one RDN and the type of this RDN is the WIN_ACCOUNT_AT attribute type.

    The DN supplied in the bind credentials is converted into a Windows user name and domain name. If Windows is able to authenticate that user with the user password provided in the bind credentials, the DSA maps the Windows user/domain name onto a X.500 access control identity: the DSA searches its local DIT to retrieve the entry that holds the specified WIN_ACCOUNT_AT value. If this search returns exactly one entry, its DN is the X.500 access control identity, otherwise the external bind procedure fails.

  • Attribute-Entry-Strategy - the bind credentials contain the X.500 entry DN and the mapping onto the Windows user and domain name is performed based on the value of the entry’s WIN_ACCOUNT_AT attribute before the external authentication function is called. If the configuration enables this strategy, each simple bind request causes the DSA to read the WIN_ACCOUNT_AT attribute of the entry in the local DIT that is named by the DN specified in the bind credentials. If the entry stores exactly one value in the Windows account attribute, this value is converted into a Windows username and domain name. The retrieved data, username and domain name and the bind password are delivered to the Windows authentication service. On success, the entry named by the original bind DN is considered to be the X.500 access control identity.

The Windows authentication service runs on a Windows domain controller. If the DSA is expected to authenticate users who are registered in domains other than the one in which the DSA is located, an inter-domain trust relationship must be established between the affected Windows domains.

How Does RACF Authentication Work?

The DSA decides whether to forward a particular simple bind request based on configurable conditions that concern:

  • The DN contained in the incoming bind credentials

  • The attribute information stored in the entry specified by the DN contained in the incoming bind credentials

A set of mapping parameters in the external authentication configuration file controls the conversion from the incoming DN to the account name recognized by the external RACF system.

The DirX Directory DSA supports

  • either dynamic DN mapping which involves DN resolution performed by the remote RACF LDAP server based on RDN values from the incoming bind operation

  • or local DN mapping based on attributes stored at the entry in the DIT of the local DSA.

The bind operation may also invoke a change-password operation on the RACF system depending on the content of the user password in the bind credentials.