search

389ds / 389-ds-base

The enterprise-class Open Source LDAP server for Linux
https://www.port389.org/
Other
210 stars 90 forks source link

Directory Server should support LDAP aliases #152

Closed 389-ds-bot closed 1 year ago

389-ds-bot commented 4 years ago

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

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 commented 4 years ago

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

batch update moving tickets to future

389-ds-bot commented 4 years ago

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

set default ticket origin to Community

389-ds-bot commented 4 years ago

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

Added initial screened field value.

389-ds-bot commented 4 years ago

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

Metadata Update from @nkinder:

389-ds-bot commented 4 years ago

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

Does the 389 Directory Server still not support LDAP aliases?

389-ds-bot commented 4 years ago

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 commented 4 years ago

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

Metadata Update from @mreynolds389:

389-ds-bot commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

Metadata Update from @mreynolds389:

anilech commented 1 year ago

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

mreynolds389 commented 1 year ago

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 commented 1 year ago

would allow us to add to the server code base?

Sure!

mreynolds389 commented 1 year ago

@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: https://github.com/389ds/389-ds-base/pull/5748

mreynolds389 commented 1 year ago

Design doc:

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

Firstyear commented 1 year ago

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

mreynolds389 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

13e66bfa5..9c05f2e46 389-ds-base-2.3 -> 389-ds-base-2.3 f6c639768..aa1d1a998 389-ds-base-2.2 -> 389-ds-base-2.2 55640d87f..f6e226ec8 389-ds-base-2.1 -> 389-ds-base-2.1

mreynolds389 commented 1 year ago

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