Docstoc

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)
                    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
            Server




                                     Service request and
                                        service ticket


   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/

				
DOCUMENT INFO