On Fri, 2002-04-19 at 19:28, Howard Chu wrote: > > Your question isn't very clear to me, but I'll take a stab at it. > In OpenLDAP 2.0, SASL principals cannot bind as arbitrary users. They bind > as themselves only, and their names are in the DN form I gave above. Your > ACLs need to control access based on those DNs. I see. Does that mean I must create an LDAP entity (say, uid=principal@KERBEROS.REALM)? And then set the ACLs to allow "root" access? (Or whatever permissions I want.) Or is it cn=asdfasf@DOMAIN.COM? How does the krb5Prinicpal objectClass fit into things? I apologize for so many questions, but these things have not been discussed to clearly in the howtos and docs I've read. > > In version 2.1 the SASL DN format is changed, and support is added for a > SASL principal to bind as some other user. But since you're not using 2.1 > yet, the feature doesn't apply to you. I look forward to these new kerberos features. Also thanks for the info on the KRB5 environment variable to set the keytab location. I knew about this but forgot it was applicable here. ;) > > To give you a taste of what's coming: the OpenLDAP 2.1 SASL DN format is > uid=<user>, cn=<realm>, cn=<sasl-mechanism>, cn=AUTH > where user, realm, and sasl-mechanism are replaced by the actual values, and > cn=AUTH is a constant. > > The exception to this is in SASL EXTERNAL with TLS, where the DN from the > user's certificate is used directly as the SASL DN. > > Also, in 2.1 there is a sasl-regexp directive that defines rules to map the > above SASL DNs to any other form. As a very simple example, I use this rule: > sasl-regexp "uid=\(.*\),cn=symas.com,cn=gssapi,cn=auth" > "cn=$1,ou=personnel,o=symas corp.,c=us" > > This would map my Kerberos login hyc@symas.com to > cn=hyc,ou=personnel,o=symas corp.,c=us > > The DN mapping feature can perform its own LDAP search to resolve names, > which makes it very powerful. I could use this rule instead: > sasl-regexp "uid=\(.*\),cn=symas.com,cn=gssapi,cn=auth" > "ldap:///ou=personnel,o=symas corp.,c=us??sub?cn=$1" > > For a Kerberos login hyc@symas.com this would return the entry that matches > "cn=hyc" and use that entry's DN. On my directory, this would return > cn=Howard Chu,ou=personnel,o=symas corp.,c=us > > Which coincidentally :) happens to also be the DN in my SSL certificate... > (Naturally the above search works because my entry contains "hyc" as one of > the values of the cn attribute.) > > -- Howard Chu > Chief Architect, Symas Corp. Director, Highland Sun > http://www.symas.com http://highlandsun.com/hyc > Symas: Premier OpenSource Development and Support -- Public key available from http://students.cs.byu.edu/~torriem
Attachment:
signature.asc
Description: This is a digitally signed message part