Hello,
my installation has two OUs, one contains real inetOrgPerson objects, other one contains aliases to the first OU. First OU contains DNs which are not acceptable to a specific application (pls. don't ask me why) so 2nd OU was introduced with DNs which are acceptable to that application. Unfortunally, authentication to an alias seems to be not possible, because that application is not able to do dereferencing.
OU1:
# 007@x86.be, freemail, my.net dn: uid=007@example.com,ou=mail,dc=my,dc=net objectClass: top objectClass: inetOrgPerson uid: 007@x86.be cn: testuser
Application does not like DN "uid=007@example.com,ou=mail,dc=my,dc=net" but other applications depend on it. So following was introduced:
OU2:
# testuser, members, my.net dn: uid=testuser,ou=members,dc=my,dc=net objectClass: top objectClass: alias objectClass: extensibleObject uid: testuser aliasedObjectName: uid=007@example.com,ou=mail,dc=my,dc=net
That application would accept DN "uid=testuser,ou=members,dc=my,dc=net", but is not able to dereference that to "uid=007@example.com,ou=mail,dc=my,dc=net" :-(
Is there a way to let a proxy do dereferencing an aliasedObjectName to "real" object, so that application may be able to authenticate to that proxy ?
best regards Christian
Christian Felsing wrote:
Hello,
my installation has two OUs, one contains real inetOrgPerson objects, other one contains aliases to the first OU. First OU contains DNs which are not acceptable to a specific application (pls. don't ask me why) so 2nd OU was introduced with DNs which are acceptable to that application. Unfortunally, authentication to an alias seems to be not possible, because that application is not able to do dereferencing.
Aliases can only be dereferenced by Search operations. They're a pretty poor mechanism for just about anything, really. You should look into using back-relay for this purpose instead.
openldap-technical@openldap.org