[Date Prev][Date Next] [Chronological] [Thread] [Top]

SASL Authentication, DNs and supported SASLMechanisms



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.