Kerberos and LDAP - PowerPoint

Document Sample
Kerberos and LDAP - PowerPoint Powered By Docstoc
					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)
• 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
• NIS+
  – Complicated
  – Limited client support
  – Dead
• 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
  – 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
• 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
Kerberos Basics
• 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
• 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
   – Kerberos tells you if user claiming to be X really is or
   – It is up to the client to decide if user X is allowed to do
• Principal
  – name/instance@realm
  – Examples
     •   jheiss@EXAMPLE.COM
     •   jheiss/admin
     •   host/
     •   ldap/
• Realm
  – Typically domain name in all caps
 Example Kerberos Transaction
            Service                            Service
  User     password                           password
           Kerberos                     Service

                                     Service request and
                                        service ticket

  service ticket

                     User     User
LDAP Basics
• 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
   – 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{256} )

objectclass ( NAME 'posixAccount' SUP top
  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
  – 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
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
  – Lightweight Directory Access Protocol
  – Simple Authentication and Security Layer
  – Generic Security Services Application Programming
  – Pluggable Authentication Module
  – Name Service Switch
Kerberos Implementation
• 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
• 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
   – 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
• 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 configured to change password in Kerberos
• Non-PAM
  – Users need to use kpasswd
LDAP Implementation
• 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.
   – If possible, list user-friendly name in x509v3 Subject
     Alternative Name field
      • Within usr_cert section of openssl.cnf:
      • 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
  – 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
      • I.e. HTTPS
• IETF-approved way of connecting
   – Application connects to standard port, requests SSL
   – Commonly called “StartTLS”
Additional LDAP Server Config
• Packet Filtering
     • 389/tcp
     • 636/tcp
          LDAP Replication
• slurpd watches for changes, pushes to
• 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
• 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
  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:// ldaps://
  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
• 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/
   – Edit /etc/security/access.conf
      • See /usr/share/doc/pam-*/txts/README.pam_access for
• Solaris
   – Add entries to /etc/project after removing default
     entries (except user.root)
           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
• Kerberos
  – comp.protocols.kerberos
• OpenLDAP
  – echo subscribe | mail openldap-software-
• nss_ldap
  – echo subscribe | mail nssldap-
   – 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
• Friendly Kerberos introduction:
• Kerberos
  – MIT:
  – Heimdal:
  – SEAM:
     • Encryption modules necessary for Kerberized NFS:
     • Full SEAM package:
• pam_krb5
   – Red Hat
      • /usr/share/doc/pam_krb5-*/README on a Red Hat box
   – Linux PAM Project:
   – OpenLDAP: