Arthur de Jong <adej...@debian.org> writes: > On Sat, 2010-06-12 at 18:31 +0200, Daniel Dehennin wrote: >> I provide a patch to start k5start when nslcd is configured for SASL >> GSSAPI kerberos authentication. > > Thanks for your patch. If I understand correctly this allows nslcd to > authenticate with Kerberos to the LDAP server and keep the Kerberos > ticket active (I'm not very familiar with Kerberos).
Yes, it is. >> Handle kerberos ticket cache creation with k5start. >> >> * debian/nslcd.init (NSLCD_DEFAULT): Default configuration file. >> Add kerberos specific options: K5START_DESC, K5START_BIN, >> K5START_PIDFILE, KRB5_PRINCIPAL, KRB5_KEYTAB, KRB5_CCREFRESH, KRB5_MODE. >> Take care of badly configured nslcd.conf: use_sasl requires >> sasl_mech=GSSAPI wich requires k5start binary. >> Restrict tiket cache type to file based. >> Start k5start before starting nslcd. >> Stop k5start after stopping nslcd. > > The change to the init script is a bit large. Is there any way to make > it simpler? Currently it more than doubles the number of lines of > code. The idea is to configure the feature in nslcd.conf (through debconf), we must detect the configuration in the init-script to start the "ticket keeper" before nslcd starts. I put it in the init-script and not in /etc/default/nslcd to keep this one as simple variables assignment and to avoid errors: imagine someone who change the KRB5_CCNAME in /etc/default/nslcd and does not update the /etc/nslcd.conf accordingly. I check the sasl usage in init-script because defining "use_sasl" and not configuring the sasl_mech does not work. Note that I'm restricting sasl_mech to GSSAPI because it's the only configuration I tested. The other possibility is to implement, in nslcd, the ticket handling. In this case, we only need to configure the keytab in /etc/nslcd.conf and nslcd manage everything. Sergio Gelato suggests that it's not the desired solution[1]. > Also, is there any reasonable configuration where you have use_sasl in > nslcd.conf but don't use k5start? Maybe for another SASL_MECH than GSSAPI? SASL is a security layer which support several security mechanism, GSSAPI is a security layer too which could support several mechanism too (but only kerberos seems implemented). So, I think yes, use_sasl is not obviously GSSAPI-Kerberos (maybe CRAM-MD5, NTLM or OTP[2]). >> * debian/nslcd.default: Kerberos configuration used by init script. >> >> * debian/nslcd.conffile: Put nslcd.default in /etc/default/. >> >> * debian/control (Recommends): Add k5start. > > I think this should be kstart. Sure, my mistake. > Anyway, I think this is more of a Suggests than a Recommends because > this is likely only useful in a limited number of environments. Recommends[3]: "Use this for packages that are not strictly necessary but are typically used with your program" Suggests[3]: "Use this for packages which will work nicely with your program but are not at all necessary" I'm not sure which one to use :-/ > Note that the SASL-relation options in nslcd are currently not > completely supported because I don't have SASL-related test in my test > environment. This makes it a bit weird to support them in the init > script. > > Do you think the options (use_sasl, sasl_mech, sasl_realm, sasl_authcid, > sasl_authzid and sasl_secprops) work as they are supposed to? If this is > the case I will re-add them to the manual page and remove the warnings > during start-up. Can you check the commented out text to see if it is > still correct? I use the following configuration: --8<---------------cut here---------------start------------->8--- # /etc/nslcd.conf # nslcd configuration file. See nss-ldapd.conf(5) # for details. # The user and group nslcd should run as. uid nslcd gid nslcd # The location at which the LDAP server(s) should be reachable. uri ldap://192.168.122.4 # The search base that will be used for all queries. base dc=baby-gnu,dc=org # The LDAP protocol version to use. ldap_version 3 # The DN to bind with for normal lookups. #binddn host/netfilter.baby-gnu....@baby-gnu.org #bindpw secret # The search scope. #scope sub use_sasl on sasl_mech GSSAPI krb5_ccname /tmp/nslcd.tkt --8<---------------cut here---------------end--------------->8--- As Sergio Gelato noted[1], sasl_realm, sasl_authcid, sasl_authzid are derived from the credential cache), I will try them to see their effects My slapd server only accepts SASL-GSSAPI-Kerberos authenticated connection, my client with the previous configuration and my patch works fine: 1. invoke-rc.d nslcd start: a. k5start is started, the credential cache is derived from /etc/nslcd.conf with defined permissions b. nslcd is started 2. nslcd bind to the LDAP server and do lookups 3. If I kill the k5start, the credential cache is still present and valid for some time 4. If I delete the credential cache, nslcd continue to works as long as it keeps the connection to the LDAP server (I restart slapd to force the connection down, then nslcd could not open a connection to the server). Hope it helped. Regards. Footnotes: [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495762#15 [2] http://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer [3] http://www.debian.org/doc/manuals/maint-guide/ch-dreq.en.html#s-control -- Daniel Dehennin Récupérer ma clef GPG: gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1
pgpCt9HFn2iOC.pgp
Description: PGP signature
