is expecting entries in the form of RFC2307. Is there something stopping
you from having such entries?

Failing that, I'm sure you can come up with a few regexp's to mangle into
the expected form. But there's plenty of software out there that expects
standard schema used in standard ways. I'd submit that using an
unpublished integer as a naming attribute isn't a "standard way." Not
wrong by any means, but not likely to gain widespread support with your
vendors nor your users (as you're seeing).

On Thu, 17 May 2007, Joe Flowers wrote:

Jim,

No answers here yet, just a vote for what you want. I am working hard on
exactly the same type of problems - trying to get OpenLDAP to handle these
types of middle-man translations/prep-work.

Joe

S James S Stapleton wrote:

Can I use open-ldap as a translation layer for queries with a ldap client
with minimal configuration potential?

Right now the client (which cannot be trivially modified), can use LDAP
authentication, sort-of. What it does, is it takes your user name, and
assignes it to the 'uid' attribute, and then tacks on whatever string is in
the config to form a distinguished name. For example, if I used 'stapleton'
as my username and the config had 'ou=People,dc=domain,dc=tld', it would
query for 'uid=stapleton,ou=People,dc=dmain,dc=tld'. Unfortunately, people
usernames are everything before the '@' sign in their email, and this is
not their uid. The uid is a number, that is used nowhere else. The standard
process that we use is to take their user name and perform an ldap query to
get the uid from the email, and then use the uid to verify if the user is
correct.

The client, as described cannot do that, if a user attempts to use what
they expect their user name to be, it will send:
uid=stapleton,ou=People,dc=mydomain,dc=tld
or
uid=stapleton@mydomain.tld,ou=People,dc=mydomain,dc=tld

Neither of which will authenticate. Is there a way to make OpenLDAP provide
a middle layer to handle this?