Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What to do about 389-ds support #364

Open
Firstyear opened this issue Aug 3, 2022 · 4 comments
Open

What to do about 389-ds support #364

Firstyear opened this issue Aug 3, 2022 · 4 comments

Comments

@Firstyear
Copy link

Hi all, I'm the maintainer of 389-ds and related parts at SUSE. Slightly embarrassing but I didn't actually know yast-users could manage users and groups in ldap, so I haven't looked into this in some time! Sorry!

I've had a look at this module and yast-ldap and think we need to discuss how to proceed. Currently, using yast-users with 389-ds is broken. Users can be created and modified but they don't match the "expected" schema of 389-ds. If a password is set via yast-users, it will never work as the yast-users module pre-crypts before sending the value which 389-ds rejects (this works on openldap for "reasons"). The default bind dn of "cn=Administrator,base_dn" is not the same as 389-ds. It's not clear the yast-users is reading from /etc/openldap/ldap.conf at all to be honest ... . User Management Settings (Configuration Modules) don't work because yast users can't read the schema properly. Reading the code, it looks like the access controls can't be set either because 389-ds ACI's are vastly different to openldaps.

Generally, pretty much most features have "some kind of problem".

To compound this, the module is split over perl, c++ and ruby, which are three languages that I don't know, and am not confident to "make large sweeping chanages" over this module in.

As a result, I think there are a few ways we could proceed. These are listed in order of "least work to most".

1 - Only support openldap, not 389-ds with this. On connection, read the RootDSE entry, and if the 'vendorName' is 389 Project, then warn the user and disable all LDAP related elements. It would be then up to the community to maintain this support. 389-ds would continue to manage it's users via it's existing inbuilt admin tool kit (dsidm).

2 - Fully remove LDAP support from yast-users. Currently, there has only been a single bug report about this feature, which may indicate it's not widely used or adopted amongst 389-ds users. However it may be working with openldap still. regardless, there appears to be a "lack of appetite" to maintain this, give the general age of the code and lack of interest to develop the ldap integration. The ldap integration as it currently exists is also generally confusing and difficult to find (even as an ldap expert it took me about half an hour to even find how to list ldap users ....)

3 - Only support 389-ds, not openldap with this module. On connection, read the RootDSE entry, and if the 'vendorName' is 389 Project, then proceed. Any other value is an error. This would allow some features to be remove, aci's to be fixed, removal of the pre-hashing of pws and more. This would bring yast-users into line with the other yast modules also only supporting 389-ds. However, this would basicly be a "large rewrite" of many elements of the ldap feature, and would require "someone else" to really help because I'm not able to do this code confidently.

4 - Support both 389-ds and openldap. This would require verification of the server type at module start, and then effectively swapping behaviours underneath. This is effectively combining 1 and 2, and would be the most work wrt to testing, making sure both code paths work, and the features involved.

I hope this gives some ideas,

@kobliha
Copy link
Member

kobliha commented Aug 4, 2022

I'd go for "2", code removal. If there are other tools to do it...

@Firstyear
Copy link
Author

@kobliha Sure, I can submit a PR for that then :)

@johnlmax
Copy link

johnlmax commented Sep 4, 2023

Hi, I would like to know the current status of this.

@Firstyear
Copy link
Author

It has been marked as deprecated, I need to finalise when it will be removed for good.

You should use dscreate instead, and follow https://www.port389.org/docs/389ds/howto/quickstart.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants