[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
SASL Authentication, DNs and supported SASLMechanisms
- To: openldap-software@OpenLDAP.org
- Subject: SASL Authentication, DNs and supported SASLMechanisms
- From: "Nels Lindquist" <nlindq@maei.ca>
- Date: Thu, 30 Aug 2001 17:39:32 -0600
- Content-description: Mail message body
- Organization: Morningstar Air Express Inc.
Okay. I'm beginning to understand how all this works.
I've successfully managed to get SASL authentication working, for the most part, but there's a couple of
things that are still hazy.
I've got things set up with entries of the following form:
dn: cn=[full name],ou=People,o=[Company],c=CA
objectclass: top
objectclass: person
object...
[...]
uid: [uid]
userPassword: {SASL}[uid]
o When authenticating using SASL, it seems that you're always given an authorization DN of the form
"uid=username + realm=REALM", which is all well and good for searching/viewing entries visible to all
authenticated users, but right now a SASL authorized user will never see an entry which the ACL system
calls "self." Is there any way to associate an entry of the above form with a DN of the SASL authorized
"uid=username + realm = REALM" form?
o Once ACLs are actually applied to the server, then SASL aware applications no longer work without
specifying an authentication method on the command line (ie, if I use -Y [SASL mech] then it still
works). It appears that applications such as ldapsearch are attempting to query the server to see which
mechanisms are supported, but the query is denied. (Output from slapd -d 386):
----
daemon: conn=1 fd=10 connection from IP=206.75.202.1:3754 (IP=0.0.0.0:34049) accepted.
ldap_read: want=1, got=1
0000: 30 0
ldap_read: want=1, got=1
0000: 3e >
ldap_read: want=62, got=62
0000: 02 01 01 63 39 04 00 0a 01 00 0a 01 00 02 01 00 ...c9...........
0010: 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 63 6c ........objectcl
0020: 61 73 73 30 19 04 17 73 75 70 70 6f 72 74 65 64 ass0...supported
0030: 53 41 53 4c 4d 65 63 68 61 6e 69 73 6d 73 SASLMechanisms
ldap_read: want=1 error=Resource temporarily unavailable
conn=1 op=0 SRCH base="" scope=0 filter="(objectClass=*)"
=> access_allowed: read access to "" "entry" requested
=> acl_get: [1] check attr entry
=> acl_get: [2] check attr entry
<= acl_get: [2] acl attr: entry
=> acl_mask: access to entry "", attr "entry" requested
=> acl_mask: to all values by "", (=n)
<= check a_dn_pat: self
<= check a_dn_pat: anonymous
<= acl_mask: [2] applying auth (=x) (stop)
<= acl_mask: [2] mask: auth (=x)
=> access_allowed: read access denied by auth (=x)
acl: access to entry not allowed
ber_flush: 14 bytes to sd 10
0000: 30 0c 02 01 01 65 07 0a 01 00 04 00 04 00 0....e........
ldap_write: want=14, written=14
0000: 30 0c 02 01 01 65 07 0a 01 00 04 00 04 00 0....e........
conn=1 op=0 RESULT tag=101 err=0 text=
ldap_read: want=1, got=0
conn=-1 fd=10 closed
----
My ACLs look like this:
access to attr=userPassword
by self write
by anonymous auth
by dn="cn=Manager,dc=maei,dc=ca" write
by dn="cn=Manager,o=Morningstar Air Express Inc.,c=CA" write
by * none
access to *
by self write
by anonymous auth
by dn="cn=Manager,dc=maei,dc=ca" write
by dn="cn=Manager,o=Morningstar Air Express Inc.,c=CA" write
by * read
I tried adding an ACL of the form "access to supported SASLMechanisms by anonymous read", but it didn't
help.
Any ideas?
----
Nels Lindquist <*>
Information Systems Manager
Morningstar Air Express Inc.