HP-UX Directory Server Administrator Guide HP-UX Directory Server Version 8.1 (5900-3098, May 2013)

NOTE:
Kerberos realms are only supported for GSS-API authentication and encryption, not for DIGEST-MD5.
Realms are used by the server to associate the DN of the client in the following form, which looks
like an LDAP DN:
uid=user_name/[server_instance],cn=realm,cn=mechanism,cn=auth
For example, Mike Connors in the engineering realm of the European division of example.com
uses the following association to access a server in the US realm:
uid=mconnors/cn=Europe.example.com, cn=engineering,cn=gssapi,cn=auth
Babara Jensen, from the accounting realm of US.example.com, does not have to specify a
realm when to access a local server:
uid=bjensen,cn=accounting,cn=gssapi,cn=auth
If realms are supported by the mechanism and the default realm is not used to authenticate to the
server, then the realm must be specified in the Kerberos principal. Otherwise, the realm can be
omitted.
NOTE:
Kerberos systems treat the Kerberos realm as the default realm; other systems default to the server.
13.1.4.2 About the KDC server and keytabs
Kerberos is a protocol that allows users or servers to authenticate to a server securely over an
insecure connection. As with protocols like TLS and SSL, Kerberos generates and issues session
keys that encrypt information. A Kerberos server, then, has two functions: as an authenticating
server to validate clients and as a ticket granting server.
Because of this, the Kerberos server is called a key distribution center or KDC.
See the operating system documentation for information on installing and configuring a Kerberos
server.
When a client authenticates to the Directory Server using GSS-API, the KDC sends a session key,
followed by a ticket granting ticket (TGT). The TGT contains the client's ID and network address,
a validity period, and the session key. The ticket and the ticket's lifetime are parameters in the
Kerberos client and server configuration. In many systems, this TGT is issued to the client when the
user first logs into the operating system.
Command-line utilities provided with the operating system (including kinit, klist, and
kdestroy) can acquire, list, and destroy the TGT. These tools usually use a file called a keytab
to the issued keys. This file is created by the Kerberos administrator by exporting the key from the
KDC.
In order to respond to Kerberos operations, the Directory Server requires access to its own
cryptographic key. The Kerberos key is written in the keytab file. The keytab gives the credentials
that the Directory Server uses to authenticate to other servers. Directory Server can use the system
default keytab file (typically /etc/krb5.keytab) or it can assign a keytab through the
KRB5_KTNAME environment variable in its startup script (/etc/opt/dirsrv/config/dirsrv):
KRB5_KTNAME=/etc/opt/dirsrv/ds.keytab ; export KRB5_KTNAME
Setting the variable in the Directory Server start script ensures that the variable is properly set each
time Directory Server starts.
When the Directory Server authenticates to the server, it is as if it is running a kinit command
to initiate the connection:
kinit -k -t /etc/opt/dirsrv/ds.keytab ldap/FQDN@REALM
The Directory Server uses the service name ldap. Its Kerberos principal is
ldap/host-fqdn@realm, such as ldap/host1.corp.example.com/EXAMPLE.COM. The
504 Managing SASL