Kerberos and LDAP Jason Heiss February 2002 Why

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 user. Password, 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_krb 5 for any OS/application which supports PAM (Pluggable Authentication Modules) • Many common applications require a recompile to enable PAM (Open. SSH, 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/ldap 1. example. com • Realm – Typically domain name in all caps

Example Kerberos Transaction User password Service password se “U ted yp cr rd en wo t, ss ith ke pa tic ice ed w d ice rv ypt wor r rv se nc ass Se th e” wi T, e s p ’ m r a rn TG use ” ce Kerberos Server Service password vi er “S Encrypted service ticket TGT User password User Service request and service ticket

LDAP Basics

Schemas • LDAP uses schemas to define what attributes an object can and must have – posix. Account object class corresponds to an entry in a passwd file – posix. Group corresponds to a group • The same object can implement multiple object classes – uid=jheiss, ou=people, dc=example, dc=com might be a posix. Account, inet. Org. Person and pilot. Person

Schema Examples attributetype ( 0. 9. 2342. 19200300. 1. 1 NAME ( 'uid' 'userid' ) DESC 'RFC 1274: user identifier' EQUALITY case. Ignore. Match SUBSTR case. Ignore. Substrings. Match SYNTAX 1. 3. 6. 1. 4. 1. 1466. 115. 121. 1. 15{256} ) objectclass ( 1. 3. 6. 1. 1. 1. 2. 0 NAME 'posix. Account' SUP top AUXILIARY DESC 'Abstraction of an account with POSIX attributes' MUST ( cn $ uid. Number $ gid. Number $ home. Directory ) MAY ( user. Password $ login. Shell $ 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 object. Class: person object. Class: inet. Org. Person object. Class: posix. Account common. Name: Jason Heiss mail: jheiss@example. com home. Phone: 111 -222 -3333 given. Name: Jason surname: Heiss uid: jheiss user. Password: {KERBEROS}jheiss@EXAMPLE. COM login. Shell: /bin/bash uid. Number: 500 gid. Number: 100 home. Directory: /home/jheiss

LDIF Example: Group dn: cn=users, ou=group, dc=example, dc=com cn: users object. Class: posix. Group user. Password: {crypt}* gid. Number: 100 member. Uid: jheiss member. Uid: 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_krb 5 • Included with Red Hat, Free. BSD, Solaris, possibly others • Open Source versions available from Red Hat (recommended), Linux PAM project – See references

Kerberos Servers • Edit /etc/krb 5. conf – Realm, servers – Generally identical on all Kerberized systems in realm • Edit /var/kerberos/krb 5 kdc/kdc. conf – Realm – Needed on KDCs only • /usr/kerberos/sbin/kdb 5_util create –s • Edit /var/kerberos/krb 5 kdc/kadm 5. acl */admin@REALM *

Kerberos Servers, cont. • Configure init to start daemons – kadmin (master KDC only) – krb 5 kdc (all KDCs) • /usr/kerberos/sbin/kadmin. local –q “addprinc jheiss/admin” • Add additional principals as needed with kadmin • Logs – /var/log/krb 5 kdc. log – /var/log/kadmind. log

Kerberos Replication • Create host principals for slave KDCs – addprinc –randkey host/hostname • Edit /var/kerberos/krb 5 kdc/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/krb 5. conf from server – /etc/krb 5. conf on Solaris using SEAM

PAM on Kerberos Clients • Red Hat – Copy files as needed from /usr/share/doc/pam_krb 5*/pam. d to /etc/pam. d – gdm, login, passwd, sshd, 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_krb 5 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 – Open. SSL – SASL (1. x until Open. LDAP 2. 1. x is available) – Open. LDAP • Clients – All of the above plus nss_ldap and pam_krb 5

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 x 509 v 3 Subject Alternative Name field • Within usr_cert section of openssl. cnf: – subject. Alt. Name=DNS: ldap 1. example. com • Open. SSL 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. keytab

LDAP Server Configuration • Edit /etc/openldap/slapd. conf – – ACLs SSL cert suffix rootdn and rootpw • Configure init to start slapd – KRB 5_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 “Start. TLS”

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: organizational. Unit ou: People dn: uid=jheiss, ou=people, dc=example, dc=com object. Class: posix. Account common. Name: Jason Heiss surname: Heiss uid: jheiss user. Password: {KERBEROS}jheiss@EXAMPLE. COM login. Shell: /bin/bash uid. Number: 500 gid. Number: 100 home. Directory: /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 base ssl tls_checkpeer tls_cacertfile ldap 1. example. com ldap 2. example. com dc=example, dc=com start_tls yes /etc/ssl/ca-cert. pem • Edit /etc/openldap/ldap. conf URI ldaps: //ldap 1. example. com/ ldaps: //ldap 2. 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) username: uid: :

LDAP Management • Open. LDAP 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 • Open. LDAP – echo subscribe | mail openldap-softwarerequest@openldap. org • nss_ldap – echo subscribe | mail nssldaprequest@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 Open. LDAP ldap. conf’s – Sample LDIF – List of Open. LDAP 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/dsseam/ • Encryption modules necessary for Kerberized NFS: http: //www. sun. com/software/solaris/encryption/download. html • Full SEAM package: http: //www. sun. com/bigadmin/content/admin. Pack/

References • pam_krb 5 – Red Hat • /usr/share/doc/pam_krb 5 -*/README on a Red Hat box – Linux PAM Project: http: //www. advogato. org/proj/pam_krb 5/ • SASL: http: //asg. web. cmu. edu/sasllibrary. html • LDAP – Open. LDAP: http: //www. openldap. org/