Kerberos and LDAP

Jason Heiss
February 2002
 Why is everybody still using NIS?

• NIS is easy to setup

• Easy to administer
• Scales fairly well
• Widely supported (clients and servers)
 Goals
• Replace NIS with something secure
– Weakly crypted passwords (and everything
else) sent over the network in the clear
– Difficult to firewall
– No system authentication
• Provide additional directory services
– Replace/supplement paper staff directory
 Other Options
• Copy local passwd file
– Error-prone
– Requires root-level trust between clients and
server
• NIS+
– Complicated
– Limited client support
– Dead
 LDAP
• LDAP is a directory access protocol
• Up to the implementation to use whatever
backend it wants
• LDAP can be used to store any form of
information, but designed for directories
– Small bits of data
– Mostly read access
 Goals Revisited
• Security
– Clients authenticate server
– Encrypt data in transit
– Simplify firewalling
• Administration
– Easy to configure
– Easy to maintain
• Scalability
• Widespread client support
 LDAP Security
• Authentication
– LDAP clients authenticate server by ensuring server
has an SSL certificate signed by a CA they trust
• Encryption
– SSL
• Access control
– ACLs based on Kerberos principal user authenticates
with
– Useful for non-NIS data like home phone number
 Scalability and Client Support
• Scalability
– Similar model to NIS for simple situations
• Master and replicas
– Hierarchical relationships possible in larger
environments
• Client support
– nss_ldap module for any OS which supports
Name Service Switch (Solaris or GNU)
– BIND IRS (NSS work-alike from BIND 8)
 Why not LDAP?
• Administration
– Initial configuration complicated
• SSL certificate management
• Schemas
• Kerberos
– Ongoing management complicated
• NIS+ itis
– No vi; add/change/delete via command line utilities
– Command line utilities take bewildering array of options
 Why Kerberos
• LDAP is designed for public information
– ACLs can protect userPassword, but…
• Kerberos supports password security
– Dictionary checks of new passwords
– Password expiration
• Kerberos useful for other services
– Windows authentication
– NFS authentication and encryption
– AFS
 Kerberos Client Support
• System logins
– pam_krb5 for any OS/application which supports PAM
(Pluggable Authentication Modules)
• Many common applications require a recompile to enable
PAM (OpenSSH, sudo, xlockmore)
– Replacement binaries for /bin/login, etc.
• Many applications with native Kerberos support
– Quite a few only support Kerberos IV, which requires
enabling Kerberos IV support on server
 Summary of Pros and Cons
• Vastly improved security
• Complicated configuration and
management
• Do you have time to invest in initial setup?
– Can you afford not to?
• Friendly tools can ease ongoing
administration
Kerberos Basics
 Kerberos
• Stores username/password pairs
– Usernames are called principals
– Kerberos database equivalent to /etc/shadow
• Passwords, encrypted or not, are almost
never sent across the network
• Server encrypts keys with user’s password,
other folks can’t decrypt/use them without
the password
 Kerberos
• When user authenticates, they are given a “ticket”
– Tickets are generally good for 8 hours
– Useful for things like authenticated NFS, IMAP, etc.
• Kerberos performs authentication, not
authorization
– Kerberos tells you if user claiming to be X really is or
not
– It is up to the client to decide if user X is allowed to do
something
 Terms
• Principal
– name/instance@realm
– Examples
• jheiss@EXAMPLE.COM
• jheiss/admin
• host/foobar.example.com
• ldap/ldap1.example.com
• Realm
– Typically domain name in all caps
 Example Kerberos Transaction
Service Service
User password password
password
Kerberos Service
Se th
Server
rv se
wi T, e ’s p
ice rv ypt wor
TG se

tic ice ed w d
k e pa
u

t, ss ith
nc ass

en wo
r
r

cr rd
“U erv

yp Service request and

se

ted
rn
“S

service ticket
am
e”
ice
”

Encrypted
TGT
service ticket

User User
password
LDAP Basics
 Schemas
• LDAP uses schemas to define what attributes an
object can and must have
– posixAccount object class corresponds to an entry in a
passwd file
– posixGroup corresponds to a group
• The same object can implement multiple object
classes
– uid=jheiss,ou=people,dc=example,dc=com might be a
posixAccount, inetOrgPerson and pilotPerson
 Schema Examples
attributetype ( 0.9.2342.19200300.100.1.1
NAME ( 'uid' 'userid' )
DESC 'RFC1274: user identifier'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' SUP top

AUXILIARY
DESC 'Abstraction of an account with POSIX attributes'
MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
MAY ( userPassword $ loginShell $ gecos $ description ) )
 Distinguished Names
• Each object in the LDAP directory has a
DN
– uid=jheiss,ou=people,dc=example,dc=com
– cn=users,ou=group,dc=example,dc=com
 LDIF Example: User
dn: uid=jheiss,ou=people,dc=example,dc=com
objectClass: person
objectClass: inetOrgPerson
objectClass: posixAccount
commonName: Jason Heiss
mail: jheiss@example.com
homePhone: 111-222-3333
givenName: Jason
surname: Heiss
uid: jheiss
userPassword: {KERBEROS}jheiss@EXAMPLE.COM
loginShell: /bin/bash
uidNumber: 500
gidNumber: 100
homeDirectory: /home/jheiss
 LDIF Example: Group
dn: cn=users,ou=group,dc=example,dc=com
cn: users
objectClass: posixGroup
userPassword: {crypt}*
gidNumber: 100
memberUid: jheiss
memberUid: bob
 Alphabet Soup
• LDAP
– Lightweight Directory Access Protocol
• SASL
– Simple Authentication and Security Layer
• GSSAPI
– Generic Security Services Application Programming Interface
• PAM
– Pluggable Authentication Module
• NSS
– Name Service Switch
Kerberos Implementation
 Software
• Servers
– Kerberos
• MIT (Recommended)
• Heimdal
• SEAM
• Clients
– pam_krb5
• Included with Red Hat, FreeBSD, Solaris, possibly others
• Open Source versions available from Red Hat (recommended),
Linux PAM project
– See references
 Kerberos Servers
• Edit /etc/krb5.conf
– Realm, servers
– Generally identical on all Kerberized systems in realm
• Edit /var/kerberos/krb5kdc/kdc.conf
– Realm
– Needed on KDCs only
• /usr/kerberos/sbin/kdb5_util create –s
• Edit /var/kerberos/krb5kdc/kadm5.acl
*/admin@REALM *
 Kerberos Servers, cont.
• Configure init to start daemons
– kadmin (master KDC only)
– krb5kdc (all KDCs)
• /usr/kerberos/sbin/kadmin.local –q “addprinc
jheiss/admin”
• Add additional principals as needed with kadmin
• Logs
– /var/log/krb5kdc.log
– /var/log/kadmind.log
 Kerberos Replication
• Create host principals for slave KDCs
– addprinc –randkey host/hostname
• Edit /var/kerberos/krb5kdc/kpropd.conf on slave
KDCs
– Add entry for every KDC host principal
• Configure init to start kpropd -S on slave KDCs
• Add cronjob on master KDC to dump database
and run kprop regularly
– See references for link to example script
 Kerberos Packet Filtering
• 88/udp
– Clients <-> KDCs
– Regular authentication traffic
• 749/tcp
– Clients -> master KDC
– Password changes, add/change/delete principals
• 754/tcp
– Master KDC -> Slave KDCs
– Database replication
 Kerberos Client
• Copy /etc/krb5.conf from server
– /etc/krb5/krb5.conf on Solaris using SEAM
 PAM on Kerberos Clients
• Red Hat
– Copy files as needed from
/usr/share/doc/pam_krb5*/pam.d to /etc/pam.d
– gdm, login, passwd, sshd, su, sudo, xdm, xlock
• Solaris
– SEAM
– See references for example pam.conf
 Host Principal for PAM
• Some references that without it, PAM can’t
verify Kerberos server
• Support
– Red Hat’s pam_krb5 supports it
• keytab and required_tgs config options
• No evidence that RH does anything different when
configured to use it
– No evidence that SEAM support it
 Testing
• As user:
– kinit
– klist
• Test admin functionality
– kadmin
• addprinc
• delprinc
 Kerberos Management
• kadmin
– addprinc
– delprinc
– listprincs
– ktadd
– ktremove
• ktutil
– rkt
– list
– quit
• Easy to integrate into existing user management tool
– See references for details
 User Password Management
• Custom centralized password program
– Least confusing if you have more than one password
database (NIS, Windows, Samba, etc.)
– See references for more information on integrating
Kerberos into one of these
• PAM
– PAM configured to change password in Kerberos
• Non-PAM
– Users need to use kpasswd
LDAP Implementation
 Software
• Servers
– Kerberos
– OpenSSL
– SASL (1.x until OpenLDAP 2.1.x is available)
– OpenLDAP
• Clients
– All of the above plus nss_ldap and pam_krb5
 LDAP Servers, Prep Work
• Create user and group (ldap/ldap)
• Make/buy signed SSL certificate
– CN in SSL certificate should be canonical name of server as
reported by reverse DNS
• I.e. moonshine.example.com
– If possible, list user-friendly name in x509v3 Subject
Alternative Name field
• Within usr_cert section of openssl.cnf:
– subjectAltName=DNS:ldap1.example.com
• OpenSSL doesn’t have support for prompting for this field, so you’ll
have to edit openssl.cnf for each cert you generate
– chmod 640 slapd-key.pem; chgrp ldap slapd-key.pem
 LDAP Servers, Prep Work
• Create service principal
– kadmin –q “addprinc ldap/hostname”
– kadmin –q “ktadd –k /etc/openldap/ldap.keytab
ldap/hostname”
– chmod 640 ldap.keytab; chgrp ldap ldap.keytab
 LDAP Server Configuration
• Edit /etc/openldap/slapd.conf
– ACLs
– SSL cert
– suffix
– rootdn and rootpw
• Configure init to start slapd
– KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab“ /
usr/sbin/slapd -u ldap -g ldap -h "ldap:/// ldaps:///"
 SSL and TLS
• SSL/TLS is a generic method of encrypting
application-layer network traffic using x.509 certs
for authentication
• “Netscape” way of connecting
– Application connects to alternate port for SSL
communication
• I.e. HTTPS
• IETF-approved way of connecting
– Application connects to standard port, requests SSL
– Commonly called “StartTLS”
Additional LDAP Server Config
• Packet Filtering
– LDAP, LDAP w/ TLS
• 389/tcp
– LDAPS
• 636/tcp
 LDAP Replication
• slurpd watches for changes, pushes to
replicas
• Acts as LDAP client, and thus needs
Kerberos ticket, not keytab
– Need cronjob to keep ticket current
• Replicas must have ACLs which allow
modification by whatever principal slurpd is
configured to use
 LDIF Example
dn: dc=example,dc=com
objectclass: organization
o: Example, Inc.

dn: ou=people,dc=example,dc=com
objectclass: organizationalUnit
ou: People

dn: uid=jheiss,ou=people,dc=example,dc=com
objectClass: posixAccount
commonName: Jason Heiss
surname: Heiss
uid: jheiss
userPassword: {KERBEROS}jheiss@EXAMPLE.COM
loginShell: /bin/bash
uidNumber: 500
gidNumber: 100
homeDirectory: /home/jheiss
 Initial Database Population
• ldapadd -x -D
“cn=Manager,dc=example,dc=com” -W -f
initial.ldif
• Remove rootdn and rootpw from slapd.conf
and restart
• All future edits should be authorized via
ACLs in slapd.conf
 Testing Server
• Test in stages
– kinit
– ldapsearch -H ldap://hostname/ -x
– ldapsearch -H ldaps://hostname/ -x
– ldapsearch -H ldap://hostname/ -ZZ -x
– ldapsearch -H ldap://hostname/
– ldapsearch -H ldaps://hostname/
– ldapsearch -H ldap://hostname/ -ZZ
 LDAP Clients
• Install nss_ldap
• Edit /etc/ldap.conf
host ldap1.example.com ldap2.example.com
base dc=example,dc=com
ssl start_tls
tls_checkpeer yes
tls_cacertfile /etc/ssl/ca-cert.pem
• Edit /etc/openldap/ldap.conf
URI ldaps://ldap1.example.com/ ldaps://ldap2.example.com/
BASE dc=example,dc=com
 Testing Client
• ldapsearch
– Makes sure /etc/openldap/ldap.conf is setup properly
and that connection to server is good
• id username
• getent passwd username
• If things don’t work
– Try turning of checkpeer in /etc/ldap.conf
– Try setting ssl to no in /etc/ldap.conf
– Try turning off nscd
 Troubleshooting
• Sample error messages
– ldap_sasl_interactive_bind_s: Local error
• ldap/hostname service principal not setup
• User doesn’t have ticket or ticket has expired
– ldap_sasl_interactive_bind_s: Can't contact
LDAP server
• Checking hostname from CN field of SSL cert failed
• See my web page in references for more
 Controlling Access
• Linux
– Add to /etc/pam.d/whatever
account required /lib/security/pam_access.so
– Edit /etc/security/access.conf
• See /usr/share/doc/pam-*/txts/README.pam_access for
syntax
• Solaris
– Add entries to /etc/project after removing default
entries (except user.root)
user.username:uid::::
 LDAP Management
• OpenLDAP tools
– ldapadd, ldapmodify, ldapdelete
– Not very user friendly
• Jason’s tools
– ldapcat, ldapedit, ldapposixadd
– Useful for folks used to NIS
• Integration into centralized tools
– Perl and Net::LDAP
• Sample code on web page
 Support
• Kerberos
– comp.protocols.kerberos
• OpenLDAP
– echo subscribe | mail openldap-software-
request@openldap.org
• nss_ldap
– echo subscribe | mail nssldap-
request@padl.com
 References
• http://ofb.net/~jheiss/krbldap/
– Kerberos replication script
– Sample SEAM pam.conf
– Examples of integrating Kerberos management into
existing tools
– Sample slapd.conf
– Sample nss_ldap and OpenLDAP ldap.conf’s
– Sample LDIF
– List of OpenLDAP error messages
– LDAP tools and sample Net::LDAP code
 References
• Friendly Kerberos introduction:
http://web.mit.edu/kerberos/www/dialogue.html
 References
• Kerberos
– MIT: http://web.mit.edu/kerberos/www/
– Heimdal: http://www.pdc.kth.se/heimdal/
– SEAM: http://www.sun.com/software/solaris/ds/ds-
seam/
• Encryption modules necessary for Kerberized NFS:
http://www.sun.com/software/solaris/encryption/download.html
• Full SEAM package:
http://www.sun.com/bigadmin/content/adminPack/
 References
• pam_krb5
– Red Hat
• /usr/share/doc/pam_krb5-*/README on a Red Hat box
– Linux PAM Project:
http://www.advogato.org/proj/pam_krb5/
• SASL: http://asg.web.cmu.edu/sasl/sasl-
library.html
• LDAP
– OpenLDAP: http://www.openldap.org/