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

Re: SASL Authentication, DNs and supported SASLMechanisms



At 08:17 AM 2001-08-31, Nels Lindquist wrote:
>On 30 Aug 2001 at 18:18, Kurt D. Zeilenga wrote:
>
>> >Is there any way to associate an entry of the above form with a DN of
>> >the SASL authorized "uid=username + realm = REALM" form? 
>> 
>> regex's...
>>         access to dn="(uid=.*),dc=example,dc=com"
>>                 by dn="uid=$1 + realm=REALM" write
>
>Just for clarification--the inference here is that for the ACL system to associate a SASL authenticated 
>user with a particular entry, the DN must have at least the UID in common with the SASL authname so that 
>a regex ACL can be created.
>Currently my user DNs are of the form cn=[full name],ou=People,o=[Company 
>name],c=CA.  There *is* a uid field in each entry, but the uids aren't currently part of the DN.  It 
>looks like I'm going to have to change all my user DNs so that they incorporate the uid.  Is this 
>assumption correct?

Basically.  The 2.0 code works best when there is some relationship
between the SASL-based authzDN (the subject) and the entry DN (the
target).  You could actually use fullnames within SASL and match
"uid=full name + realm=REALM" with "cn=full name,o=Company,c=CA",
but I don't recommend it.

2.1 will have a more sophisticated mapping mechanism.

However, I generally recommend use of uid for person naming
(and dc for context naming).  Besides not changing frequently,
they ease programmatic use (such as such mappings, DNS SRV
location, etc.).

Kurt