Authentication

To log in to a Dimensions CM client, you provide a username and password or use a smart card. The server can be configured to validate these credentials using different authentication systems.

Native authentication

The default configuration for authentication uses the server’s native operating system authentication mechanisms to validate user credentials.

UNIX Uses the POSIX standard getpwnam, getspnam, and crypt functions to encrypt the password provided by the client and compare it to the value stored in the system’s password file. If the values match, the user is successfully authenticated.
Windows

Queries the user account information using the NetGetUserInfo function provided by the Microsoft Platform SDK. The queried domain controller depends on how the system is configured.

  • If a domain name was specified as part of the username (mydomain\myuser), CM queries the domain controller for that domain and calls NetGetUserInfo against that domain controller.

  • If the server is configured to authenticate against a given domain name (using the DM_LOGON_DOMAIN parameter), CM looks up the domain controller for that specific domain and calls NetGetUserInfo against that domain controller.

  • If no domain was specified in the username and no domain name has been configured, Dimensions CM queries the primary domain controller for the server.

After obtaining the account information, Dimensions CM verifies if the user's password has expired and, if necessary, allows the user to change it. CM then calls the Microsoft Win32 API function LogonUser and passes it the default logon provider and a logon type of LOGON32_LOGON_NETWORK. If the LogonUser function succeeds, the user's credentials are validated and the user can access Dimensions CM.

Dimensions z/OS On a Dimensions z/OS agent machine, the POSIX getpwnam and crypt functions are used the same as on UNIX. These system calls then authenticate users against the chosen security system (RACF, TopSecret etc).

Back to top

Single Sign-On

Dimensions CM supports Single Sign-On (SSO). For details, see the following documentation:

Back to top

LDAP‌

A Dimensions CM server can be configured to authenticate users with a Lightweight Directory Access Protocol (LDAP) server, for example, Microsoft Active Directory Server or OpenLDAP directory server.

Enterprise customers use these directory servers to centralize their user account information. Dimensions uses the OpenLDAP API to communicate between the pool manager and the LDAP server. To authenticate using LDAP, Dimensions CM identifies the DN (Distinguished Name) for the user and "bind" to the LDAP directory server using that name and the associated password.

LDAP is a highly configurable directory server, and Dimensions CM provides the following ways to identify a user’s DN:

Search for a matching DN

This is typically the most common way of authenticating using LDAP. The CM server searches the LDAP directory for a DN that has a particular attribute value and then binds using that DN.

You need to configure a bind user, which is the DN of a user who has authority to search the directory and register their password using the dmpasswd utility. Dimensions CM "binds" initially as that user and performs a search (from a given point in the LDAP directory tree) to find a DN where a specific attribute has the value set to the name of the user logging into Dimensions CM. If a match is found Dimensions CM binds using that DN. If binding is successful the user is authenticated successfully and can access Dimensions CM.

Search anonymously for a matching DN If you do not configure a bind user but configure Dimensions CM to perform an LDAP search, the search is performed anonymously. It functions as described above, but you need to enable anonymous searches on your LDAP server.
Construct a specific DN Enables you to configure Dimensions CM to construct a specific DN instead of searching to find one. Configure the base of the DN and an attribute to use as the RDN (Relative Distinguished Name). Dimensions CM forms a DN by specifying the RDN, followed by the user's name, and then the base. Dimensions CM tries to bind to that DN using the password provided when the user logged in. If binding is successful the user is authenticated successfully and can access Dimensions CM.

For more details about configuring LDAP, see Administration.

Back to top

Pluggable authentication modules

On Solaris and Linux, Dimensions CM also supports authentication using Pluggable Authentication Modules (PAM) which allows many common authentication systems to be supported. The Dimensions CM PAM implementation only supports authentication modules that require username and password (the PAM LDAP module). Modules that require more data to authenticate the user are not supported.

With PAM authentication, the pool manager calls PAM APIs to authenticate the user, passing the username and password when required. PAM calls the authentication module that has been configured for the Dimensions service in /etc/ pam.conf. Dimensions CM uses a PAM service called dimensions_cm that is configurable. If the PAM conversation succeeds the user is authenticated successfully and can access Dimensions CM.

For more details about configuring PAM, see Administration.

Back to top

Common access cards

Dimensions CM supports user authentication with the United States Department of Defense (DoD) Common Access Cards (CAC). Users present their CAC card to the card reader, select a certificate to identify themselves, and enter their card PIN number.

Dimensions CM validates users as follows:

  1. The Dimensions CM server sends a cryptographic nonce to the client, which is then securely signed with the private key held on the CAC card via the PKCS#11 API.

  2. The signed nonce is sent to the Dimensions CM server along with the user’s public x509 certificate.

  3. The server verifies that the nonce was signed by the bearer of the public certificate (proving that the user has the correct CAC card).

  4. The SSO server validates the certificate, for example, checks that it has not expired, that it is signed by a trusted Certificate Authority (CA), and is not included in a Certificate Revocation List (CRL).

  5. The SSO server uses the subject name from the certificate to locate a matching LDAP user account. If the certificate is valid and trusted, comes from the bearer of the CAC card, and has a matching LDAP entry, then authentication is complete.

For more details about configuring CAC, see Administration.

Back to top

See also: