LDAP-UX Client Services B.04.10 with Microsoft Windows Active Directory Server Administrator's Guide
How SASL GSSAPI Works
Figure 7-1 SASL GSSAPI Environment
KDC Server
AS TGS
LDAP-UX Client Services
Windows 2000/
2003 Active
Direcotory
1
234
6
5
The following describes how LDAP-UX binds a client using SASL GSSAPI to the LDAP directory
server shown in Figure 4-1:
1. The LDAP-UX Client Service sends the principal name and password to the Authentication
Server (AS).
2. The AS validates the principal and sends a Ticket Granting Ticket (TGT) and associated session
key to the LDAP-UX Client Services. LDAP-UX Client Services stores the TGT and session key
information in the credential cache, /etc/opt/ldapux/krb5cc_ldap_gssapi.
3. LDAP-UX Client Services uses the TGT and requests a service ticket from Ticket Granting
Service (TGS).
4. TGS sends the service ticket and other information to LDAP-UX Client Services.
5. LDAP-UX Client Services sends the service ticket and binds to the LDAP directory server.
6. LDAP-UX Client Services verifies the received information and authenticates the LDAP client.
Proxy User
SASL/GSSAPI authentication is only for proxy user authentication for name service subsystem.
When proxy is configured, you use either a user or service principal as a proxy user.
User Principal
The user principal must be configured in the KDC. The user principal can be specified with a
realm (for example, user1@CUP.HP.COM) or without a realm (for example, user1). When no
realm is specified, the realm information is retrieved from /etc/krb5.conf. The credential
(password) is the same one used to create the user principal in the KDC.
Service/Host Principal
A Kerberos keytab file contains service or host principals and associated keys information. Users
can choose to bind using the service or host keys. The keytab file may contain multiple principals
and keys. Users may configure which service key to use. For example, the following
/etc/krb5.keytab file contains two principal:
SASL GSSAPI Support 103