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

KerberosServer

Service

User“Usernam

e”

TGT, encrypted with

user’s passwordTGT

“Service”

Service ticket, encrypted

with service password

Encryptedservice ticket

Userpassword

Userpassword

Servicepassword

Servicepassword

Service request andservice ticket

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=comobjectClass: personobjectClass: inetOrgPersonobjectClass: posixAccountcommonName: Jason Heissmail: jheiss@example.comhomePhone: 111-222-3333givenName: Jasonsurname: Heissuid: jheissuserPassword: {KERBEROS}jheiss@EXAMPLE.COMloginShell: /bin/bashuidNumber: 500gidNumber: 100homeDirectory: /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=comobjectclass: organizationo: Example, Inc.

dn: ou=people,dc=example,dc=comobjectclass: organizationalUnitou: People

dn: uid=jheiss,ou=people,dc=example,dc=comobjectClass: posixAccountcommonName: Jason Heisssurname: Heissuid: jheissuserPassword: {KERBEROS}jheiss@EXAMPLE.COMloginShell: /bin/bashuidNumber: 500gidNumber: 100homeDirectory: /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.combase dc=example,dc=comssl start_tlstls_checkpeer yestls_cacertfile /etc/ssl/ca-cert.pem

• Edit /etc/openldap/ldap.confURI 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/