[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: SASL EXTERNAL and client certificates
Quanah Gibson-Mount wrote:
Is only TLSCACertificatePath checked or OpenSSL's default directory also?
...
I ran into the same issue with SASL/GSSAPI (anyone who connects with a
valid K5 ticket from my realm is a "user"). Because of this, I do not use
"user" anywhere in my ACLs.
However, I also exploit this feature of OpenLDAP to use the SASL DN's of
"Exploiting" a "feature"? :)
connections that do not map into my user space to it so I can give some
SASL connections read access to various entries without them having entries
in the database.
Yes, and the same with users in sasldb and maybe other sasl backends.
But I don't think this is comparable. Normally you have ascendancy over
accounts created in there, but I don't know about Identities Verisign
trusts in.
This would just subvert the meaning of "users".
But if slapd doesn't care about /etc/ssl/certs (I don't know libssl)
this wouldn't be a problem. Does an explicit TLSCACertificatePath
prevent libssl from evaluating CA-certificates in /etc/ssl/certs?
dn:email=me@my.dom,cn=adam pordzik,o=a org
So, DN is in reversed RFC2253 order. That's good, but who flipped it?
(AFAIK "openssl x509" sub-command also offers a switch to reverse
subject-DN, but I've never used it so far, therefor I am not sure,
whether this is only for displaying purposes.)
If you understand DN structure in LDAP (i.e., the order of importance) then
it should become obvious why the order is reversed to create a valid DN.
I'm not sure, whether I understand you. Which structure? Which order?
The usual Hierarchy? I don't know X500 well, but AFAIK it just starts
with the left-most AVA whereas LDAP-DNs on the right. Is there more to
know?
So, it's slapd itself who reverses subject's DN, right? (And what about
multi-valued AVAs?)
sasl-regexp
email=([^,]*),cn=([^,]*)(,.*)?
ldap:///ou=Users,ou=Accounts,dc=my,dc=dom??one?(&(mail=$1)(cn=$2))
$ ldapwhoami -H "ldap://ldap.lan.d-dt.de/"; -ZZ -Y EXTERNAL
I will note that since you have a sasl-regexp (authz-regexp in OL 2.3+),
you can essentially create a "users" set by doing:
access to <whatever>
by dn.children="ou=Users,ou=Accounts,dc=my,dc=dom"
Yes. It's just another point. And more typing, especially with multiple
naming contexts... :) Generally, I agree that unmapped authzid's allow
a finer grained access control.
(What is dc=dom, by the way? dc=com? :) ).
dc=exaple,dc=org is so much typing too... :)
A
--