Kerberos and LDAP

1. Kerberos and LDAP Jason Heiss February 2002

2. Why is everybody still using NIS? • NIS is easy to setup • Easy to administer • Scales fairly well • Widely supported (clients and servers)

3. 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

4. Other Options • Copy local passwd file • Error-prone • Requires root-level trust between clients and server • NIS+ • Complicated • Limited client support • Dead

5. 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

6. Goals Revisited • Security • Clients authenticate server • Encrypt data in transit • Simplify firewalling • Administration • Easy to configure • Easy to maintain • Scalability • Widespread client support

7. 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

8. 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)

9. 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

10. 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

11. 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

12. 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

13. Kerberos Basics

14. 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

15. 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

16. 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

17. Example Kerberos Transaction Service password Service password User password Kerberos Server Service Service ticket, encrypted with service password TGT, encrypted with user’s password Service request and service ticket “Username” “Service” Encrypted service ticket TGT User password User

18. LDAP Basics

19. 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

20. 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 ) )

21. 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

22. 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

23. LDIF Example: Group dn: cn=users,ou=group,dc=example,dc=com cn: users objectClass: posixGroup userPassword: {crypt}* gidNumber: 100 memberUid: jheiss memberUid: bob

24. 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

25. Kerberos Implementation

26. 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

27. 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 *

28. 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

29. 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

30. 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

31. Kerberos Client • Copy /etc/krb5.conf from server • /etc/krb5/krb5.conf on Solaris using SEAM

32. 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

33. 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

34. Testing • As user: • kinit • klist • Test admin functionality • kadmin • addprinc • delprinc

35. Kerberos Management • kadmin • addprinc • delprinc • listprincs • ktadd • ktremove • ktutil • rkt • list • quit • Easy to integrate into existing user management tool • See references for details

36. 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

37. LDAP Implementation

38. 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

39. 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

40. 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

41. 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:///"

42. 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”

43. Additional LDAP Server Config • Packet Filtering • LDAP, LDAP w/ TLS • 389/tcp • LDAPS • 636/tcp

44. 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

45. 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

46. 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

47. 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

48. 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

49. 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

50. 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