Hi Kevin, as for qmail-ldap you can use a thing similar to what you call %d with this patch: http://www.sztaki.hu/~bajnokk/qmail-ldap-virtual.html
Sun's docs do really well describe decision factors in detail, I can not add any more ideas. Kristof Kevin wrote: > ldap_filter: <uid=%u> > Specify a filter. The following tokens can be used in the filter > string: > %% = % > %u = user > %U = user portion of %u (%U = test when %u = [EMAIL PROTECTED]) > %d = domain portion of %u if available (%d = domain.tld when %u = > [EMAIL PROTECTED]), otherwise same as %r > %1-9 = domain tokens (%1 = tld, %2 = domain when %d = domain.tld) > %s = service > %r = realm > %D = user DN (available for group checks) > > The %u token has to be used at minimum for the filter to be useful. > If ldap_auth_method is 'bind', the filter will search for the DN > (distinguished name) attribute. Otherwise, the search will look for > the 'ldap_password_attr' (see below) attribute. > > These tokens can also be used in some additional parameters such as > ldap_search_base, ldap_default_realm, ldap_group_dn, ldap_group_filter, > ldap_group_search_base, and maybe others. > > In particular, I've noticed that my first cut at such a DIT seems to me > to have some vivid shortcomings related to these tokens. The suffixes > in my DIT have the form: dc=domain,dc=com and the DN's have the form: > [EMAIL PROTECTED],ou=people,dc=domain,dc=com and it's clear to me > that with such a design, I'll have a difficult time using the tokens > available here to specify a ldap_search_base (ie. how could I use %r or > %d to get into the desired suffix/database for several different > suffixes) that is derived from the information that a user will enter > into clients that would want to authenticate against this LDAP DIT (such > as email clients). >
