Diff for /wikisrc/tutorials/openldap_authentication_on_netbsd.mdwn between versions 1.1 and 1.4

version 1.1, 2011/11/20 21:35:54 version 1.4, 2014/06/04 20:56:19
Line 1 Line 1
 **Contents**  **Contents**
   
 [[!toc levels=3]]  [[!toc levels=3]]
   
 #  Author's note  #  Author's note 
   
 This document really describes (what I remember of installing) my system, with tidbits I've forgotten from various sources on the net. I can't guarantee that following this document you'll get a working system, but I hope it will provide some insights into how the thing is supposed to work.  This document really describes (what I remember of installing) my system, with tidbits I've forgotten from various sources on the net. I can't guarantee that following this document you'll get a working system, but I hope it will provide some insights into how the thing is supposed to work. 
   
 Staffan Thom´en <duck@shangtai.net>  Staffan Thom´en <duck@shangtai.net>
   
 #  Server setup  #  Server setup 
   
 First things first, you'll need to set up an openldap server somewhere, this is fairly straightforward, as it's available in pkgsrc. The tricky bit is really configuring the ACL:s, since the openldap logs are incredibly hard to read. Generally it's probably a good idea to firewall it from outside and worry about the ACL setup later if you want to do things like let other departments to see your users or let the public see contact information for example.  First things first, you'll need to set up an openldap server somewhere, this is fairly straightforward, as it's available in pkgsrc. The tricky bit is really configuring the ACL:s, since the openldap logs are incredibly hard to read. Generally it's probably a good idea to firewall it from outside and worry about the ACL setup later if you want to do things like let other departments to see your users or let the public see contact information for example. 
   
 An example config file is included in the package (${LOCALBASE}/etc/opeldap/slapd.conf), and the only thing that really has to be added is to include some schemas for user authentication:  An example config file is included in the package (${LOCALBASE}/etc/opeldap/slapd.conf), and the only thing that really has to be added is to include some schemas for user authentication: 
          
     cosine.schema      cosine.schema
     inetorgperson.schema      inetorgperson.schema
     nis.schema      nis.schema
          
   
 These are (in pkgsrc-2008Q2) installed in ${LOCALBASE}/share/examples/openldap/schema, and can just be included from there, and tells the server which record keys (as in key-value pairs) it shall accept.  These are (in pkgsrc-2014Q1) installed in ${LOCALBASE}/share/examples/openldap/schema, and can just be included from there, and tells the server which record keys (as in key-value pairs) it shall accept. 
   
 And that really is it for the server bit. Next comes testing it out with a few ldap commands.  And that really is it for the server bit. Next comes testing it out with a few ldap commands. 
   
 The basic commands of talking directly with the ldap database are ldapadd, ldapmodify and ldapsearch. These are in the openldap-client package, so you won't have to install the entire server on a client machine.  The basic commands of talking directly with the ldap database are ldapadd, ldapmodify and ldapsearch. These are in the openldap-client package, so you won't have to install the entire server on a client machine. 
   
 Options you'll be using alot like -b (base) and -H (host URI) can conveninently be stuck in a client configuration file, ${LOCALBASE}/etc/openldap/ldap.conf, which will save you time and aggravation from having to type them all the time.  Options you'll be using alot like -b (base) and -H (host URI) can conveninently be stuck in a client configuration file, ${PKG_SYSCONFBASE}/openldap/ldap.conf, which will save you time and aggravation from having to type them all the time. 
   
 To talk to your ldap server, try running ldapsearch;  To talk to your ldap server, try running ldapsearch; 
          
     % ldapsearch -H ldap://my.server/      % ldapsearch -H ldap://my.server/
          
   
 This really means dump everything, but since we've nothing in the database it will respond with an error.  This really means dump everything, but since we've nothing in the database it will respond with an error. 
   
 To set this database up for user authentication, we'll need to lay down some structure. LDAP is generally a hierachial database of records with key-value pairs. We'll first need to tell it about our organisation and then add a user.  To set this database up for user authentication, we'll need to lay down some structure. LDAP is generally a hierachial database of records with key-value pairs. We'll first need to tell it about our organisation and then add a user. 
   
 Here we'll be using ldapadd, which reads a format called ldif. It is a flat text format that looks something like this:  Here we'll be using ldapadd, which reads a format called ldif. It is a flat text format that looks something like this: 
          
      dn: cn=example,dc=org       dn: cn=example,dc=org
      objectClass: dcObject       objectClass: dcObject
      objectClass: organization       objectClass: organization
      objectClass: top       objectClass: top
      o: Example Organisation       o: Example Organisation
      dc: example       dc: example
          
          
      dn: ou=groups,dc=example,dc=org       dn: ou=groups,dc=example,dc=org
      objectClass: top       objectClass: top
      objectClass: organizationalUnit       objectClass: organizationalUnit
      ou: groups       ou: groups
          
          
      dn: ou=people,dc=example,dc=org       dn: ou=people,dc=example,dc=org
      objectClass: top       objectClass: top
      objectClass: organizationalUnit       objectClass: organizationalUnit
      ou: people       ou: people
          
   
 The text above define three records, they start with a distinguished name of the record (dn:), which is a unique identifier for the record.  The text above define three records, they start with a distinguished name of the record (dn:), which is a unique identifier for the record. 
   
 "cn=example,dc=org" is the root of this organisation, with a common name (cn) example and a domain component (dc) of org. Next come the objectClass lines which tells us that this is domain component object, an organisation object and a top-level object. We then have an organisation (o:) line which is a descriptive text and finally a domain component line (dc:) which is the stored value for the dc (same as in the distinguished name).  "cn=example,dc=org" is the root of this organisation, with a common name (cn) example and a domain component (dc) of org. Next come the objectClass lines which tells us that this is domain component object, an organisation object and a top-level object. We then have an organisation (o:) line which is a descriptive text and finally a domain component line (dc:) which is the stored value for the dc (same as in the distinguished name). 
   
 Following this are two records which define something called in ldap terms organisational units, and as you see from the dn:, essentially two branches of the main tree. They are here to be used for the user groups (yes, like /etc/groups) and the actual users.  Following this are two records which define something called in ldap terms organisational units, and as you see from the dn:, essentially two branches of the main tree. They are here to be used for the user groups (yes, like /etc/groups) and the actual users. 
   
 If you want you can just stick all of this in one file (even the user below) and add it with ldapadd -f file.ldif, this will create the initial structure of your database.  If you want you can just stick all of this in one file (even the user below) and add it with ldapadd -f file.ldif, this will create the initial structure of your database. 
   
 Adding a group and then a user user is no more difficult, you just have to fill out the right fields.  Adding a group and then a user user is no more difficult, you just have to fill out the right fields. 
          
     dn: cn=ldapusers,ou=groups,dc=example,dc=org      dn: cn=ldapusers,ou=groups,dc=example,dc=org
     objectClass: top      objectClass: top
     objectClass: posixGroup      objectClass: posixGroup
     cn: ldapusers      cn: ldapusers
     gidNumber: 101      gidNumber: 101
     memberUid: bill      memberUid: bill
     memberUid: george      memberUid: george
          
   
 A group named ldapusers with the number 101, and the secondary users bill and george (these are of course not required).  A group named ldapusers with the number 101, and the secondary users bill and george (these are of course not required). 
          
     dn: uid=test,ou=people,dc=example,dc=org      dn: uid=test,ou=people,dc=example,dc=org
     objectClass: top      objectClass: top
     objectClass: posixAccount      objectClass: posixAccount
     objectClass: inetOrgPerson      objectClass: inetOrgPerson
     uid: test      uid: test
     uidNumber: 2000      uidNumber: 2000
     gidNumber: 101      gidNumber: 101
     o: Example Organisation      o: Example Organisation
     cn: Test User      cn: Test User
     givenName: Test      givenName: Test
     sn: User      sn: User
     gecos: Test User,3b,+358800128128,+35801234567      gecos: Test User,3b,+358800128128,+35801234567
     loginShell: /bin/ksh      loginShell: /bin/ksh
     homeDirectory: /home/test      homeDirectory: /home/test
     mail: test@example.org      mail: test@example.org
     displayName: El Magnifico Test User      displayName: El Magnifico Test User
          
   
 A user with the uid test, belonging to group ldapusers (101); o: is the same as the root record above and the others apart from sn (surname) is fairly obvious. The GECOS field contains comma separated values, apparently it's pulled straight into the client system.  A user with the uid test, belonging to group ldapusers (101); o: is the same as the root record above and the others apart from sn (surname) is fairly obvious. The GECOS field contains comma separated values, apparently it's pulled straight into the client system. 
   
 The fields actually required by the schemes are:  The fields actually required by the schemes are: 
          
     uid      uid
     uidNumber      uidNumber
     gidNumber      gidNumber
     cn      cn
     sn      sn
     homeDirectory      homeDirectory
          
   
 LDAP can store multiple roots and each user entry for example can be more than just the login information, as above it also mentions email, phone numbers and so on for our test user, and it can also include binary data like a mugshot and them playing the corporate theme on banjo. As far as authentication is concerned, we've got what we want though.  LDAP can store multiple roots and each user entry for example can be more than just the login information, as above it also mentions email, phone numbers and so on for our test user, and it can also include binary data like a mugshot and them playing the corporate theme on banjo. As far as authentication is concerned, we've got what we want though. 
   
 So far so good, this should not cause much trouble to set up, I believe I've covered everything required; the thing I had most problem with in relation to the database itself was that it was so unstructured, you have to provide all the structure yourself.  So far so good, this should not cause much trouble to set up, I believe I've covered everything required; the thing I had most problem with in relation to the database itself was that it was so unstructured, you have to provide all the structure yourself. 
   
 #  Client Setup  #  Client Setup 
   
 In order to log in on a NetBSD system we need to provide two things, a way for the system to authenticate you and a way for it to find out what your group, user id, etc. is.  In order to log in on a NetBSD system we need to provide two things, a way for the system to authenticate you and a way for it to find out what your group, user id, etc. is. 
   
 The first part of this, authentication is taken care of by PAM (or possibly by some BSD auth scheme, but this is not yet implemented as far as I know.)  The first part of this, authentication is taken care of by PAM (or possibly by some BSD auth scheme, but this is not yet implemented as far as I know.) 
   
 The second part is done via libc and the NSS subsystem.  The second part is done via libc and the NSS subsystem. 
   
 In order to do this, we need to provide some plugins for either system that enables LDAP support in them. The plugins are in pkgsrc and are called  In order to do this, we need to provide some plugins for either system that enables LDAP support in them. The plugins are in pkgsrc and are called 
          
     security/pam-ldap      security/pam-ldap
          
   
 and  and 
          
     databases/nss_ldap      databases/nss_ldap
          
          
   The latest version of these packages (pkgrsc-2014Q2 and newer) will automatically created the necessary symbolic links in /usr/lib and /usr/lib/security to be able to use these modules. For older version you will have create a symbolic link from /usr/lib/nss_ldap.so.0 to ${LOCALBASE}/lib/nss_ldap.so.1 and from /usr/lib/security/pam_ldap.so to ${LOCALBASE}/lib/security/pam_ldap.so
 Once these are installed, you can either link them, copy or use in place from ${LOCALBASE}/lib and ${LOCALBASE}/lib/security into /usr/lib and /usr/lib/security respectively. I prefer to use symbolic links because then any upgrade I make will automatically have the latest version already in place.  
   Before we go any further, I'd like to introduce some security into the mix; up til now we've talked to the ldap server without any limitations and what's called anonymous binds, i.e. not logged in. 
 Before we go any further, I'd like to introduce some security into the mix; up til now we've talked to the ldap server without any limitations and what's called anonymous binds, i.e. not logged in.  
   XXX can anonymous binds actually write to a db without ACLs? 
 XXX can anonymous binds actually write to a db without ACLs?  
   This is an ldap user, just like the test user outlined above, since the ldap database can authenticate against itself. (You don't have to, but I haven't explored the other possibilities such as SASL) 
 This is an ldap user, just like the test user outlined above, since the ldap database can authenticate against itself. (You don't have to, but I haven't explored the other possibilities such as SASL)  
   So we'll create a user called nss 
 So we'll create a user called nss      
          dn: cn=nss,dc=example,dc=org
     dn: cn=nss,dc=example,dc=org      objectClass: top
     objectClass: top      objectClass: inetOrgPerson
     objectClass: inetOrgPerson      o: Example Organisation
     o: Example Organisation      cn: nss
     cn: nss      sn: manager
     sn: manager      
      
   We'll attach a password so that not just anyone can connect, and also change our LDAP configuration slightly so that we use encrypted passwords. 
 We'll attach a password so that not just anyone can connect, and also change our LDAP configuration slightly so that we use encrypted passwords.      
          userPassword: {SSHA}w5aocfmGgZqq3h8AjvaZiw8WKdrRTjTi
     userPassword: {SSHA}w5aocfmGgZqq3h8AjvaZiw8WKdrRTjTi      
      
   To generate this password I use (bundled with openldap-server) slapdpasswd 
 To generate this password I use (bundled with openldap-server) slapdpasswd      
          % slappasswd -h "{SSHA}"
     % slappasswd -h "{SSHA}"      
          
      
   And in slapd.conf add 
 And in slapd.conf add      
          passsword-hash {SSHA}
     passsword-hash {SSHA}      
      
   And of course you'll need to change the secret for the rootpw into something encrypted. 
 And of course you'll need to change the secret for the rootpw into something encrypted.  
   Note that the traffic between the ldap client and the server is still not (that is if you've been following this document) encrypted so this might be best to perform locally. 
 Note that the traffic between the ldap client and the server is still not (that is if you've been following this document) encrypted so this might be best to perform locally.  
   This user will be used for ACL filtering later. 
 This user will be used for ACL filtering later.  
   Next we'll need to configure the LDAP part of the plugins, a convenience here is that since both the plugins are made by the same people, they can share a configuration file. They will look for ${PKG_SYSCONFBASE}/nss_ldap.conf and ${PKG_SYSCONFBASE}/pam_ldap.conf, but linking them to the same file will let you have just one place to configure (and protect for your ldap user password) 
 Next we'll need to configure the LDAP part of the plugins, a convenience here is that since both the plugins are made by the same people, they can share a configuration file. They will look for ${LOCALBASE}/etc/nss_ldap.conf and ${LOCALBASE}/etc/pam_ldap.conf, but linking them to the same file will let you have just one place to configure (and protect for your ldap user password)  
   The important bits in this file is the base setting and the uri for your ldap server: 
 The important bits in this file is the base setting and the uri for your ldap server:      
          base dc=example,dc=org
     base dc=example,dc=org      
          
          uri ldap://my.server/
     uri ldap://my.server/      
      
   Next we need to tell it who it should contact the ldap database as: 
 Next we need to tell it who it should contact the ldap database as:      
          binddn cn=nss,dc=example,dc=org
     binddn cn=nss,dc=example,dc=org      
          
      And if you want to be able to change passwords as root without knowing the user's password in advance (with passwd, using ldapmodify you can still just set it, if you bind with the credentials to do it (see ACLs).) 
     bindpw unencrypted-password  
      I haven't mentioned this user before, it's the database's root user, allowed to do anything; 
       
 And if you want to be able to change passwords as root without knowing the user's password in advance (with passwd, using ldapmodify you can still just set it, if you bind with the credentials to do it (see ACLs).)      rootbinddn cn=root,dc=example,dc=org
       
 I haven't mentioned this user before, it's the database's root user, allowed to do anything;  
      The password for this will not be in this file, but in a separate file called ${PKG_SYSCONFBASE}/nss_ldap.secret or for pam; ${PKG_SYSCONFBASE}/pam_ldap.secret 
     rootbinddn cn=root,dc=example,dc=org  
        * ) not sure about this, but my system has both, linked together 
   
 The password for this will not be in this file, but in a separate file called ${LOCALBASE}/etc/nss_ldap.secret or for pam; ${LOCALBASE}/etc/pam_ldap.secret  Finally we will set the password exchange method to exop; 
       
   * ) not sure about this, but my system has both, linked together      pam_password exop
       
 Finally we will set the password exchange method to exop;  
      This is the OpenLDAP extended method and while the passwords will still be sent in the clear, they are encrypted with the database's scheme in the database. 
     pam_password exop  
      So while you can use ldapsearch to get the data (though ACLs can prevent this if properly set up) it will still only be a hash. 
   
 This is the OpenLDAP extended method and while the passwords will still be sent in the clear, they are encrypted with the database's scheme in the database.  That's it for configuring the plugins so far. 
   
 So while you can use ldapsearch to get the data (though ACLs can prevent this if properly set up) it will still only be a hash.  #  NSS 
   
 That's it for configuring the plugins so far.  The next change we will need to do is to enable the ldap module in nsswitch.conf: 
   
 #  NSS  Change 
       
 The next change we will need to do is to enable the ldap module in nsswitch.conf:      group:      files
       ...
 Change      passwd:     files
          
     group:      files  
     ...  To 
     passwd:     files      
          group:      files ldap
       ...
 To      passwd:     files ldap
          ...
     group:      files ldap      netgroup:   files ldap
     ...  
     passwd:     files ldap  This will enable you to have local accounts as well as LDAP users. You could test this out now, by running the getent program; 
          
       % getent group
 This will enable you to have local accounts as well as ldap users. You could test this out now, by running the getent program;      
      
     % getent group  Will present you with a list of all the groups in the system, with the ldap group 'ldapusers' we created earlier tacked on to the end of the list. 
          
       % getent passwd
 Will present you with a list of all the groups in the system, with the ldap group 'ldapusers' we created earlier tacked on to the end of the list.      
      
     % getent passwd  And this will show you the user list, with the ldap user 'test' at the end. 
      
   #  PAM 
 And this will show you the user list, with the ldap user 'test' at the end.  
   PAM keeps it's configuration files in /etc/pam.d/, these are divided into individual files per each pam service in the system; most are just including system but some need special attention. 
 #  PAM  
   On my system I have the following changes from the stock netbsd setup: 
 PAM keeps it's configuration files in /etc/pam.d/, these are divided into individual files per each pam service in the system; most are just including system but some need special attention.  
   ##  /etc/pam.d/sshd 
 On my system I have the following changes from the stock netbsd setup:      
       #
 ##  /etc/pam.d/sshd      # PAM configuration for the "sshd" service
          #
     # $NetBSD: sshd,v 1.5.2.2 2005/03/19 17:45:49 tron Exp $       
     #      # auth
     # PAM configuration for the "sshd" service      auth            required        pam_nologin.so  no_warn
     #      auth            sufficient      pam_krb5.so     no_warn try_first_pass
            auth            sufficient      pam_ldap.so     no_warn try_first_pass
     # auth      # pam_ssh has potential security risks.  See pam_ssh(8).
     auth            required        pam_nologin.so  no_warn      #auth           sufficient      pam_ssh.so      no_warn try_first_pass
     auth            sufficient      pam_ldap.so      auth            required        pam_unix.so     no_warn try_first_pass
     auth            sufficient      pam_krb5.so     no_warn try_first_pass       
     # pam_ssh has potential security risks.  See pam_ssh(8).      # account
     #auth           sufficient      pam_ssh.so      no_warn try_first_pass      account         required        pam_krb5.so
     auth            required        pam_unix.so     no_warn try_first_pass      account         required        pam_login_access.so
            account         required        pam_unix.so
     # account       
     account         required        pam_krb5.so      # session
     account         sufficient      pam_ldap.so      # pam_ssh has potential security risks.  See pam_ssh(8).
     account         required        pam_login_access.so      #session        optional        pam_ssh.so
     account         required        pam_unix.so      session         required        pam_permit.so
             
     # session      # password
     # pam_ssh has potential security risks.  See pam_ssh(8).      password        sufficient      pam_krb5.so     no_warn try_first_pass
     #session        optional        pam_ssh.so      password        sufficient      pam_ldap.so     no_warn try_first_pass
     session         sufficient      pam_ldap.so      password        required        pam_unix.so     no_warn try_first_pass
     session         required        pam_permit.so      
        
     # password  ##  /etc/pam.d/su 
     password        sufficient      pam_krb5.so     no_warn try_first_pass      
     password        sufficient      pam_ldap.so      #
     password        required        pam_unix.so     no_warn try_first_pass      # PAM configuration for the "su" service
          #
        
 ##  /etc/pam.d/su      # auth
          auth            sufficient      pam_rootok.so           no_warn
     # $NetBSD: su,v 1.5 2005/03/01 16:28:46 christos Exp $      auth            sufficient      pam_self.so             no_warn
     #      auth            sufficient      pam_ksu.so              no_warn try_first_pass
     # PAM configuration for the "su" service      #auth           sufficient      pam_group.so            no_warn group=rootauth root_only fail_safe authenticate
     #      auth            requisite       pam_group.so            no_warn group=wheel root_only fail_safe
            auth            sufficient      pam_ldap.so             no_warn try_first_pass
     # auth      auth            required        pam_unix.so             no_warn try_first_pass nullok
     auth            sufficient      pam_ldap.so       
     auth            sufficient      pam_rootok.so           no_warn      # account
     auth            sufficient      pam_self.so             no_warn      account         required        pam_login_access.so
     auth            sufficient      pam_ksu.so              no_warn try_first_pass      account         include         system
     auth            requisite       pam_group.so            no_warn group=wheel root_only fail_safe       
     #auth           sufficient      pam_group.so            no_warn group=rootauth root_only fail_safe authenticate      # session
     auth            required        pam_unix.so             no_warn try_first_pass nullok      session         required        pam_permit.so
            
     # account  
     account         required        pam_login_access.so  ##  /etc/pam.d/system 
     account         include         system      
            # $NetBSD: openldap_authentication_on_netbsd.mdwn,v 1.3 2014/05/31 17:49:28 tron Exp $
     # session      #
     session         required        pam_permit.so      # System-wide defaults
          #
        
 ##  /etc/pam.d/system      # auth
          auth            sufficient      pam_krb5.so             no_warn try_first_pass
     # $NetBSD: system,v 1.6 2005/03/03 02:12:32 christos Exp $      auth            sufficient      pam_ldap.so             no_warn try_first_pass
     #      auth            required        pam_unix.so             no_warn try_first_pass nullok
     # System-wide defaults       
     #      # account
            account         required        pam_krb5.so
     # auth      account         required        pam_unix.so
     auth            sufficient      pam_ldap.so      
     auth            sufficient      pam_krb5.so             no_warn try_first_pass      # session
     auth            required        pam_unix.so             no_warn try_first_pass nullok      session         required        pam_lastlog.so          no_fail no_nested
             
     # account      # password
     account         sufficient      pam_ldap.so      password        sufficient      pam_krb5.so             no_warn try_first_pass
     account         required        pam_krb5.so      password        sufficient      pam_ldap.so             no_warn try_first_pass
     account         required        pam_unix.so      password        sufficient      pam_unix.so             no_warn try_first_pass
          password        required        pam_deny.so             prelim_ignore
     # session      
     session         sufficient      pam_ldap.so  
     session         required        pam_lastlog.so          no_fail no_nested  The last bit here with pam_deny, is a bit special, it is what enables you to change passwords for both local users and those in the ldap database with the passwd command. pam_deny with the prelim_ignore flag is needed, else pam will will fail in the preliminary phase (it is always run trough twice) and you will not be able to change passwords. 
        
     # password  In order to use this you need to patch your pam_deny (/usr/src/lib/libpam/modules/pam_deny.c) with the patch by Edgar Fuß <ef@math.uni-bonn.de>: 
     password        sufficient      pam_ldap.so  
     password        sufficient      pam_krb5.so             try_first_pass  <http://mail-index.netbsd.org/tech-userlevel/2007/08/29/0001.html>
     password        sufficient      pam_unix.so             try_first_pass  
     password        required        pam_deny.so             prelim_ignore  The original message describing the problem is here: 
      
   <http://mail-index.netbsd.org/tech-userlevel/2007/08/25/0006.html>
 The last bit here with pam_deny, is a bit special, it is what enables you to change passwords for both local users and those in the ldap database with the passwd command. pam_deny with the prelim_ignore flag is needed, else pam will will fail in the preliminary phase (it is always run trough twice) and you will not be able to change passwords.  
   
 In order to use this you need to patch your pam_deny (/usr/src/lib/libpam/modules/pam_deny.c) with the patch by Edgar Fuß <ef@math.uni-bonn.de>:  ##  /etc/pam.d/system 
   
 <http://mail-index.netbsd.org/tech-userlevel/2007/08/29/0001.html>      #
       # PAM configuration for the "sudo" service
 The original message describing the problem is here:      #
       
 <http://mail-index.netbsd.org/tech-userlevel/2007/08/25/0006.html>      # auth
       auth            sufficient      pam_ldap.so             no_warn try_first_pass
       auth            required        pam_unix.so             no_warn try_first_pass nullok use_uid
 #  Securing your system      
       # account
 As far as the document goes now, this setup is unprotected in that anyone listening in to the packets travelling trough your network would be able to find the unencrypted messages of your ldap users. Not a happy thought.      account         required        pam_login_access.so
       account         include         system
 So we'll want to enable SSL encryption of the traffic between your clients and the server.      
       # session
 In order to do this you will need to create an SSL certificate for your server and also distribute it to the client machines, so that they will be able to certify the authenticity of the server.      session         required        pam_permit.so
       
 We'll also need to configure slapd to use it, I put my keys in the /etc/openssl hierachy, since it seemed made for it.  This file is only required if you want to use the "sudo" package from "pkgsrc".
      You will have to compile this package manually with "PKG_OPTIONS.sudo" set to
     TLSCipherSuite          HIGH:MEDIUM:+SSLv2  "pam" because it doesn't support PAM by default.
     TLSCertificateFile      /etc/openssl/certs/openldap.pem      
     TLSCertificateKeyFile   /etc/openssl/private/openldap.pem  #  Securing your system 
     TLSCACertificateFile    /etc/openssl/certs/openldap.pem  
      As far as the document goes now, this setup is unprotected in that anyone listening in to the packets travelling trough your network would be able to find the unencrypted messages of your ldap users. Not a happy thought. 
   
 And we'll also have to change the way slapd is started, so add this to your /etc/rc.conf  So we'll want to enable SSL encryption of the traffic between your clients and the server. 
      
     slapd_flags="-h ldaps://"  In order to do this you will need to create an SSL certificate for your server and also distribute it to the client machines, so that they will be able to certify the authenticity of the server. 
      
   We'll also need to configure slapd to use it, I put my keys in the /etc/openssl hierachy, since it seemed made for it. 
 Note that this will make slapd answer only to ldaps!      
       TLSCipherSuite          HIGH
 Next we'll need to change the clients setup so that they will use ldaps. Enable ssl in ${LOCALBASE}/etc/{nss_,pam_}ldap.conf;      TLSCertificateFile      /etc/openssl/certs/openldap.pem
          TLSCertificateKeyFile   /etc/openssl/private/openldap.pem
     ssl on      TLSCACertificateFile    /etc/openssl/certs/openldap.pem
          
   
 Next if you're like me using the ${LOCALBASE}/etc/openldap/ldap.conf file, telling the client libs where to find the cert file is enough, we don't have to put it in the nss/pam config:  Next we'll need to change the clients setup so that they will use encryption. Enable ssl in ${PKG_SYSCONFBASE}/{nss_,pam_}ldap.conf; 
          
     URI         ldaps://my.server      ssl start_tls
     TLS_CACERT  /etc/openssl/certs/openldap.pem  
      Next if you're like me using the ${PKG_SYSCONFBASE}/openldap/ldap.conf file, telling the client libs where to find the cert file is enough, we don't have to put it in the nss/pam config: 
       
 If you can still use getent, encryption is happening. You can of course also tcpdump your network traffic to see what's going on.      TLS_CACERT  /etc/openssl/certs/openldap.pem
       
 #  ACL  
   If you can still use getent, encryption is happening. You can of course also tcpdump your network traffic to see what's going on. 
 I left access control lists of the server to the last, because they are the easiest to get wrong and often cause problems that you might attribute to other things in the various setups.  
   #  ACL 
 The syntax is fairly straightforward;  
      I left access control lists of the server to the last, because they are the easiest to get wrong and often cause problems that you might attribute to other things in the various setups. 
     acceess to [something] by [someone] [access]  
      The syntax is fairly straightforward; 
       
 The order is important; if something matches, later tests will not be run.      acceess to [something] by [someone] [access]
       
 The one I use looks like this:  
      The order is important; if something matches, later tests will not be run. 
      #  
      # Protect passwords from prying eyes  The one I use looks like this: 
      #      
      access to attrs=userPassword       #
         by dn="cn=nss,dc=example,dc=org" write       # Protect passwords from prying eyes
         by anonymous auth       #
         by self write       access to attrs=userPassword
         by * none          by dn="cn=nss,dc=example,dc=org" write
                by anonymous auth
      #          by self write
      # set read-only attributes          by * none
      #       
      access to attrs=uidNumber,gidNumber,uid,homeDirectory       #
         by dn="cn=nss,dc=example,dc=org" write       # set read-only attributes
         by self read       #
         by * read       access to attrs=uidNumber,gidNumber,uid,homeDirectory
                by dn="cn=nss,dc=example,dc=org" write
      #          by self read
      # For all else, let the user edit his own entry and everyone else watch          by * read
      #       
      access to *       #
         by dn="cn=nss,dc=example,dc=org" write       # For all else, let the user edit his own entry and everyone else watch
         by self write       #
         by * read       access to *
                by dn="cn=nss,dc=example,dc=org" write
              by self write
           by * read
 Note that access to the user password can be set to auth; so that the database can authenticate a user without letting them see the password hash using an anonymous bind.       
       
   
   Note that access to the user password can be set to auth; so that the database can authenticate a user without letting them see the password hash using an anonymous bind. 
   

Removed from v.1.1  
changed lines
  Added in v.1.4


CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb