[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Heimdal/OpenLDAP/Samba howto and bugreport

> -----Original Message-----
> From: owner-heimdal-discuss@sics.se
> [mailto:owner-heimdal-discuss@sics.se]On Behalf Of Tarjei Huse

> 2. Edit /etc/openldap/slapd.conf
> - add
> include         /etc/openldap/schema/krb5-kdc.schema
> - comment out minssf lines like this one:
> sasl-secprops minssf=128

> As the external method used by heimdal does not have an ssf>0 (of
> someone comes up with a suggested solution to this please give it too
> me).

Seems like this is a necessary step, yes.

> - modify the relevant acls by adding:
>   by sockurl="^ldapi:///$" write

This is a bad idea. SASL/EXTERNAL supplies the client's uidNumber and
you should use sasl-regexps to map these to regular identities instead of
defeating your security system in this manner.

At the very least, you know that uidNumber=0 is Unix root, and you should be
able to unambiguously map this to either the LDAP rootdn or to a Kerberos
admin account, as you wish:

sasl-regexp "uidNumber=0\\\+gidNumber=.*,cn=peercred,cn=external,cn=auth"

> 3.class 'krb5KDCEntry' requires attribute 'krb5KeyVersionNumber'
> You may get this when you run kadmin -l, init. I'm not sure if this is
> related to (2) or if it is a separate error. If it is a
> separate error,
> you may get around it by setting
> schemacheck off
> in slapd.conf, but this is not the way to do it.

Hm, in Heimdal 0.6.1 this error never occurred. Seems to be a regression

> Bugs:
> - The code that searches for an account searches for
> (&(objectclass=account)(uid=<username>)). This defeats some of the
> purpose of using ldap, namely the option to be able to define and
> structure your information in an quite arbitary way. In this
> case, a lot
> of people (me included) use inetOrgPerson as the base objectclass
> instead of account. Samba as such does not have any problems
> with this,
> and neither should Heimdal. I therefore suggest that the user
> should be
> able to set this in kdc.conf.

Sounds like a good point.

> Then , when I try
> kadmin> ext host/elprinsessekaja.mail2.bergfald.no I get:
> kadmin: krb5_kt_add_entry: End of credential cache reached
> it seems that the kdc tries to search the ldapdatabase with the
> following as base:
> gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> >From the log:
> May 25 18:52:37 elprinsessekaja slapd[31188]: conn=55 op=3 SRCH
> base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" scope=2
> filter="(objectClass=krb5Principal)"
> May 25 18:52:37 elprinsessekaja slapd[31188]: conn=55 op=3
> SRCH attr=cn
> createTimestamp creatorsName krb5PrincipalName krb5PrincipalRealm
> modifiersName modifyTimestamp objectClass uid
> May 25 18:52:37 elprinsessekaja slapd[31188]: conn=55 op=3 RESULT
> tag=101 err=32 text=
> OpenLDAP gives the errorcode 32, i.e. no such object.

In 0.6.1 this error occurred but it was benign. hdb-ldap is just using the
creatorsName attribute in the account entry to try and lookup the Kerberos
principal that created the given account. Usually it fails to find a match
since there is no krb5Principal associated with the
"uidNumber=0+gidNumber=0,..." DN. (Yet another reason to use sasl-regexp and
map your SASL/EXTERNAL creds to real DNs before working with this...)

> You also need to add the following to your slapd.conf's sasl section:
> sasl-realm              NU.NO
> sasl-host               elprinsessekaja.mail2.bergfald.no
> sasl-authz-policy both

Why are you using sasl-authz-policy? Nothing here needs it.

> sasl-regexp
>      uid=(.+),cn=NU.NO,cn=gssapi,cn=auth
>      uid=$1,ou=People,o=nu,c=no

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support