--- wikisrc/tutorials/openldap_authentication_on_netbsd.mdwn 2012/02/05 07:14:36 1.2 +++ wikisrc/tutorials/openldap_authentication_on_netbsd.mdwn 2014/06/04 20:56:19 1.4 @@ -19,13 +19,13 @@ An example config file is included in th 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. 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; @@ -131,8 +131,7 @@ and databases/nss_ldap - -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. +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 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. @@ -172,7 +171,7 @@ Note that the traffic between the ldap c 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 ${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) +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) The important bits in this file is the base setting and the uri for your ldap server: @@ -187,9 +186,6 @@ Next we need to tell it who it should co binddn cn=nss,dc=example,dc=org - bindpw unencrypted-password - - 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).) I haven't mentioned this user before, it's the database's root user, allowed to do anything; @@ -197,7 +193,7 @@ I haven't mentioned this user before, it rootbinddn cn=root,dc=example,dc=org -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 +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 * ) not sure about this, but my system has both, linked together @@ -228,9 +224,10 @@ To group: files ldap ... passwd: files ldap - + ... + netgroup: 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; +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 @@ -250,51 +247,47 @@ On my system I have the following change ## /etc/pam.d/sshd - # $NetBSD: openldap_authentication_on_netbsd.mdwn,v 1.1 2011/11/20 21:35:54 mspo Exp $ # # PAM configuration for the "sshd" service # # auth auth required pam_nologin.so no_warn - auth sufficient pam_ldap.so auth sufficient pam_krb5.so no_warn try_first_pass + auth sufficient pam_ldap.so no_warn try_first_pass # pam_ssh has potential security risks. See pam_ssh(8). #auth sufficient pam_ssh.so no_warn try_first_pass auth required pam_unix.so no_warn try_first_pass # account account required pam_krb5.so - account sufficient pam_ldap.so account required pam_login_access.so account required pam_unix.so # session # pam_ssh has potential security risks. See pam_ssh(8). #session optional pam_ssh.so - session sufficient pam_ldap.so session required pam_permit.so # password password sufficient pam_krb5.so no_warn try_first_pass - password sufficient pam_ldap.so + password sufficient pam_ldap.so no_warn try_first_pass password required pam_unix.so no_warn try_first_pass ## /etc/pam.d/su - # $NetBSD: openldap_authentication_on_netbsd.mdwn,v 1.1 2011/11/20 21:35:54 mspo Exp $ # # PAM configuration for the "su" service # # auth - auth sufficient pam_ldap.so auth sufficient pam_rootok.so no_warn auth sufficient pam_self.so no_warn auth sufficient pam_ksu.so no_warn try_first_pass - 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 + auth requisite pam_group.so no_warn group=wheel root_only fail_safe + auth sufficient pam_ldap.so no_warn try_first_pass auth required pam_unix.so no_warn try_first_pass nullok # account @@ -307,29 +300,27 @@ On my system I have the following change ## /etc/pam.d/system - # $NetBSD: openldap_authentication_on_netbsd.mdwn,v 1.1 2011/11/20 21:35:54 mspo Exp $ + # $NetBSD: openldap_authentication_on_netbsd.mdwn,v 1.3 2014/05/31 17:49:28 tron Exp $ # # System-wide defaults # # auth - auth sufficient pam_ldap.so auth sufficient pam_krb5.so no_warn try_first_pass + auth sufficient pam_ldap.so no_warn try_first_pass auth required pam_unix.so no_warn try_first_pass nullok # account - account sufficient pam_ldap.so account required pam_krb5.so account required pam_unix.so # session - session sufficient pam_ldap.so session required pam_lastlog.so no_fail no_nested # password - password sufficient pam_ldap.so - password sufficient pam_krb5.so try_first_pass - password sufficient pam_unix.so try_first_pass + password sufficient pam_krb5.so no_warn try_first_pass + password sufficient pam_ldap.so no_warn try_first_pass + password sufficient pam_unix.so no_warn try_first_pass password required pam_deny.so prelim_ignore @@ -344,6 +335,27 @@ The original message describing the prob +## /etc/pam.d/system + + # + # PAM configuration for the "sudo" service + # + + # auth + auth sufficient pam_ldap.so no_warn try_first_pass + auth required pam_unix.so no_warn try_first_pass nullok use_uid + + # account + account required pam_login_access.so + account include system + + # session + session required pam_permit.so + +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 +"pam" because it doesn't support PAM by default. + # Securing your system 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. @@ -354,27 +366,18 @@ In order to do this you will need to cre 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. - TLSCipherSuite HIGH:MEDIUM:+SSLv2 + TLSCipherSuite HIGH TLSCertificateFile /etc/openssl/certs/openldap.pem TLSCertificateKeyFile /etc/openssl/private/openldap.pem TLSCACertificateFile /etc/openssl/certs/openldap.pem -And we'll also have to change the way slapd is started, so add this to your /etc/rc.conf - - slapd_flags="-h ldaps://" - - -Note that this will make slapd answer only to ldaps! - -Next we'll need to change the clients setup so that they will use ldaps. Enable ssl in ${LOCALBASE}/etc/{nss_,pam_}ldap.conf; - - ssl on +Next we'll need to change the clients setup so that they will use encryption. Enable ssl in ${PKG_SYSCONFBASE}/{nss_,pam_}ldap.conf; + ssl start_tls -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 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: - URI ldaps://my.server TLS_CACERT /etc/openssl/certs/openldap.pem