Directory Server should support LDAP aliases

[389-ds-bot]

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/152

• Created at 2012-01-04 19:50:35 by mkosek
• Closed at 2020-03-25 17:01:19 as wontfix
• Assigned to nobody
• Associated bugzillas
  • https://bugzilla.redhat.com/show_bug.cgi?id=178898

---

https://bugzilla.redhat.com/show_bug.cgi?id=178898

Description of problem:

The Fedora Directory Server does not honor alias dereferencing requests

Version-Release number of selected component (if applicable):
Fedora Directory Server 1.0.1


How reproducible:
An ldapsearch using the correct '-a' syntax

Steps to Reproduce:
# ldapsearch -a always -x -b
'uid=myuser,ou=Accounts,ou=Office,dc=company,dc=com' -s base -h
ns-slapd.company.com 'uid=myuser' 'uid'

dn: uid=myuser,ou=Accounts,ou=Office,dc=company,dc=com
uid: myuser

Expected results:
# ldapsearch -a always -x -b
'uid=myuser,ou=Accounts,ou=Office,dc=company,dc=com' -s base -h
openldap.company.com 'uid=myuser' 'uid'

dn: cn=My User,ou=Persons,ou=Office,dc=company,dc=com
uid: myuser

Additional info: using the openldap ldapsearch or fedora provided ldapsearch
from /opt/fedora-ds/shared/bin does not make a difference. The fedora ds server
does not honor the -a setting, nor any -a setting (find, search or always) and
handles it by the default -never setting.

[389-ds-bot]

Comment from rmeggins (@richm) at 2012-01-10 06:12:05

batch update moving tickets to future

[389-ds-bot]

Comment from rmeggins (@richm) at 2012-08-14 19:56:22

set default ticket origin to Community

[389-ds-bot]

Comment from nkinder (@nkinder) at 2012-08-28 04:14:32

Added initial screened field value.

[389-ds-bot]

Comment from nkinder (@nkinder) at 2017-02-11 23:02:11

Metadata Update from @nkinder:

• Issue set to the milestone: FUTURE

[389-ds-bot]

Comment from toni94 at 2020-02-25 17:56:15

Does the 389 Directory Server still not support LDAP aliases?

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2020-02-25 19:18:36

Does the 389 Directory Server still not support LDAP aliases?

Correct, we still do not support aliases. There are no plans to add this functionality at this time.

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2020-02-25 19:18:36

Metadata Update from @mreynolds389:

• Custom field reviewstatus adjusted to None (was: Needs Review)
• Issue close_status updated to: None

[389-ds-bot]

Comment from toni94 at 2020-02-26 08:48:46

So you have been ignoring this feature since 2006? That's impressive :)

I have to assume that with 389 Directory Server there is another way to achieve the same or similar functionality as LDAP aliases do, right?

[389-ds-bot]

Comment from lkrispen (@elkris) at 2020-02-26 12:12:12

So you have been ignoring this feature since 2006? That's impressive :)

and looks like there was no real demand
it is an open source product, contributions are welcome :-)

I have to assume that with 389 Directory Server there is another way to achieve the same or similar functionality as LDAP aliases do, right?

we have smart referrals, which is probably not exactly what you want. But it could be a good starting point to manage aliases

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2020-02-27 04:29:06

Generally in these cases, I always ask "what are you trying to achieve". Sometimes there may be an easier or alternative method that doesn't involve new code/features.

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2020-03-25 17:01:21

Since there is no demand for this, we are going to close it out for now...

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2020-03-25 17:01:22

Metadata Update from @mreynolds389:

• Issue close_status updated to: wontfix
• Issue status updated to: Closed (was: Open)

[anilech]

Hi, if anyone is interested, I've created a plugin which supports alias dereferencing during base lookups. It's here.

[mreynolds389]

Hi, if anyone is interested, I've created a plugin which supports alias dereferencing during base lookups. It's here.

We would need to test this of course, but would it be something you would allow us to add to the server code base?

[anilech]

would allow us to add to the server code base?

Sure!

[mreynolds389]

@anilech I've reworked your code, and added to it to DS. Some of of it was outdated, most likely because the plugin programmers guide is also very outdated, and I updated it to comply with our coding guidelines.

Created PR for further review: #5748

[mreynolds389]

Design doc:

https://www.port389.org/docs/389ds/design/alias-entries-design.html

[Firstyear]

Part of the rfc is that aliases shouldn't have subordinate entries, is there a way we could enforce that?

[mreynolds389]

Part of the rfc is that aliases shouldn't have subordinate entries, is there a way we could enforce that?

Not easily, not without doing additional internal searches. Personally I don't feel we have to be super strict with this. The RFC is somewhat vague to begin with, the reasoning for this "requirement" is not clear, and there is little demand for this feature. Thoughts?

[progier389]

Part of the rfc is that aliases shouldn't have subordinate entries, is there a way we could enforce that?

Not easily, not without doing additional internal searches. Personally I don't feel we have to be super strict with this. The RFC is somewhat vague to begin with, the reasoning for this "requirement" is not clear, and there is little demand for this feature. Thoughts?

IMHO this kind of constraint (i.e which children entries could exist below a given parent entry) are supposed to be handled by the "DIT structure rules" (cf RFC4512, 4517 and X.501) but that is a part of the ldap RFC that is not implemented in ds389. So I would not bother about it until we support the DIT structure rules. (Should not be too complex as it is simply a test to do when adding a new entry, But I do not think that there is a real demand about it either. -;)

[Firstyear]

Part of the rfc is that aliases shouldn't have subordinate entries, is there a way we could enforce that?

Not easily, not without doing additional internal searches. Personally I don't feel we have to be super strict with this. The RFC is somewhat vague to begin with, the reasoning for this "requirement" is not clear, and there is little demand for this feature. Thoughts?

Don't we have a numsubordinates attribute on entries? But yes, there would be extra work involved for this requirement, but it is part of the rfc. I'm not gonna lose sleep if we don't do it though either.

[mreynolds389]

13e66bf..9c05f2e 389-ds-base-2.3 -> 389-ds-base-2.3
f6c6397..aa1d1a9 389-ds-base-2.2 -> 389-ds-base-2.2
55640d8..f6e226e 389-ds-base-2.1 -> 389-ds-base-2.1

[mreynolds389]

https://bugzilla.redhat.com/show_bug.cgi?id=2203173