Tech2Tech
Applied Solution 2
Authentication made easy
LDAP simplifies authorization for multiple systems and applications.
by Jim Browning
Large enterprises face significant challenges when managing high volumes of users, systems and applications. Timely provisioning and de-provisioning of user attributes, more effective governance processes for user authorizations, and auditing for compliance with required standards, laws and regulations are just some of the issues.
To meet these challenges, many enterprises have implemented centralized user and identity-management systems. Such processes significantly reduce the cost of user management and offer stronger network security as well as increased separation of security management duties.
LDAP directory integration
Information regarding an enterprise’s users, systems and applications is commonly organized in a directory database. The database, which is highly optimized for read and advanced search operations, contains a set of objects with attributes arranged in a logical and hierarchical manner. This allows information to be centrally managed while access to the data is consistent and controlled through the lightweight directory access protocol (LDAP). The protocol defines an Internet industry standard for querying and modifying information in a directory.
Best practices suggest that organizations with multiple systems and applications should integrate their authorization information for database users across the enterprise to ensure consistency and security.
The LDAP integration enables the authentication of a Teradata Database user’s identity and password by an external directory service, with database access authorized based on a directory security group membership. By providing an enterprise user name and password, the user initiates a login, which is authenticated through a secure bind to the external directory. This authentication allows the same user name and password to be applied to a Teradata Database logon and other enterprise applications and systems.
Integrating a Teradata Database with an external directory infrastructure requires the configuration of the Teradata generic security services subsystem. The subsystem supports several different security mechanisms that provide authentication, confidentiality (encryption) and integrity security services for a database session. Properties in the configuration file (TdgssUserConfigFile.xml) define the LDAP mechanism and must be edited to provide information about the LDAP environment, enabling the subsystem to:
- Find directory servers
- Access the servers in compliance with site-specific security requirements
- Locate information in the directory with efficiency
While configuration of the subsystem properties is straightforward, special consideration should be given to failover of directory services, authentication of users across multiple domains, and properly securing directory communications.
Because the directory will become the primary source for user authentication, multiple directory servers must be available to provide a failover capability. The LdapServerName property identifies directory servers to be employed by the subsystem and can be configured to specify a list of available LDAP servers. However, a better practice is to configure the LdapServerName property as follows to use a service resource record:
LdapServerName="_ldap._tcp.<domain_name>"
The service resource record provides an LDAP servers list, specifying a “priority” and “weight” for each. A server is then randomly selected to handle an authentication request. Besides providing for failover support, this process also load-balances requests across multiple servers.
It is not uncommon for an enterprise to define users in various active directory domains. For these environments, the best practice is to configure the subsystem to use the global catalog. The catalog contains a searchable, partial representation of every object in a multi-domain forest. Using a global catalog makes the directory structure transparent and enables the subsystem LDAP server to authenticate users in any domain without requiring a referral to different directory servers. Global catalog servers can also be located by applying this service resource record:
LdapServerName="_gc._tcp.<domain_name>"
Passwords can be transmitted over a network to the LDAP server, so it is important to establish a secure connection between the Teradata and directory servers. The strong encryption features of the Secure Socket Layer (SSL) protocol ensure the integrity and confidentiality of any transferred data by easily configuring the LdapServerName property:
LdapServerName="_gcs._tcp.<domain_name>
SSL certificates offer additional security. A directory administrator must provide a copy of all required certificates, which must be installed on each Teradata node. Before authentication requests can be sent to the certificates, Teradata generic security services properties are configured to identify them and enforce their use:
LdapClientTlsReqCert="demand"
LdapClientTlsCACertDir="/opt/teradata/tdat/tdgss/site/ssl/cacerts/"
The easy integration of a Teradata Database with a corporate LDAP directory infrastructure ensures that only authorized users have access to it.
Single sign-on
The LDAP authentication process requires a valid user name and password for every logon request. Conversely, the single sign-on (SSO) process enables users to seamlessly access all corporate Teradata systems without providing additional credentials once they have been authenticated to a Microsoft active directory domain.
When a user is authenticated in the SSO process, a “ticket granting ticket” is cached on the client system. A logon request initiated by the user (providing no user name or password) generates a “service ticket.” The system forwards the service ticket request to the database where it is validated before a database session is established. (See figure.)
Click to enlarge
Kerberos is an industry-standard network authentication protocol that enables mutual authentication between two computer systems. Windows Clients and the Teradata Database employ the Kerberos protocol to transparently authenticate a user’s identity, package the user’s name and credentials in an encrypted data structure called a ticket, and securely deliver those credentials from the client to the database.
Enabling SSO technology requires the Teradata system to be integrated into each active directory domain used to access the database. The integration is done by creating computer components and user accounts in the active directory that corresponds to each Teradata node. The user accounts and associated passwords are required to generate the keys that secure the Kerberos tickets.
When a user initiates an SSO request, the Teradata client software constructs a service principle name based upon the Teradata node selected for the connection, and requests a ticket for that service. Each service principle name registered in the active directory will adhere to the following construction convention:
In this instance, “Teradata” is the service name. The official name of the Teradata node, as determined by a domain name system lookup, will replace <host_name>.
A tool such as the Windows ktpass program generates a Kerberos key for each service principle name on the active directory server. To complete the integration, these keys are exported from the directory server and merged into the Kerberos keytab file on each Teradata node.
SSO not only simplifies the logon process for database users but also improves network performance because Kerberos tickets are cached and reused as needed.
Important technologies
LDAP directory integration and SSO are two separate, distinct and sometimes confusing technologies. However, both enable external authentication of user access to a Teradata Database and both play important roles in the effective integration of Teradata systems with corporate security processes and infrastructure.
Jim Browning is the enterprise security architect for Teradata Research and Development.