--On Friday, August 04, 2006 11:24 AM -0400 Alex Karasulu
<[EMAIL PROTECTED]> wrote:
You mean the principal's entry may be in some place in the directory
which does not follow the domain to DN mapping I guess. Like ...
[EMAIL PROTECTED] really being in uid=jhenne,ou=users,dc=apache,dc=org
Yes, yes, this is a reasonable conclusion.
I was thinking about the following
algorithm:
1. map the specified name to a base dn, like in your example. This might
be up to a specialized authentication module.
2. search this base dn for matching users
3. bind using this user's DN.
You are right, of course, that the search still needs to be carried out.
However, we're saving a network round-trip.
We might want to look at making a custom SASL mechanism to do this as
well.
You may want to look at how the "authz-regexp" pieces work in OpenLDAP,
which allow you to map SASL identities to entries in the server based on
regular expressions.
For example, in my system, I have:
authz-regexp uid=(.*)/cgi,cn=stanford.edu,cn=gssapi,cn=auth
ldap:///cn=cgi,cn=applications,dc=stanford,dc=edu??sub?krb5PrincipalName=$1/[EMAIL PROTECTED]
authz-regexp uid=service/(.*),cn=stanford.edu,cn=gssapi,cn=auth
ldap:///cn=Service,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalName=service/[EMAIL PROTECTED]
authz-regexp uid=webauth/(.*),cn=stanford.edu,cn=gssapi,cn=auth
ldap:///cn=Webauth,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalName=webauth/[EMAIL PROTECTED]
authz-regexp uid=(.*),cn=stanford.edu,cn=gssapi,cn=auth
ldap:///uid=$1,cn=Accounts,dc=stanford,dc=edu??sub?suSeasStatus=active
Stanford uses SASL/GSSAPI as a binding mechanism, and this allows me to map
different types of Kerberos identities into different parts of the tree.
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
