Users - LDAP module may not be functional with 389-ds

[Firstyear]

Recently SUSE has changed from openldap to 389-ds. It has been reported during documentation of these changes, that this may have affected the ability of this module to function correctly.

We should either:

• Remove the ldap users module in favour of the 389 cli tool
• Update and investigate what is required to make this work with 389-ds.

I'm not a perl/ruby developer, so is there anyone who can help with this?

[kobliha]

Please share more information. You say that "It has been reported during documentation" - where? By removing "ldap users module" you probably mean ability to configure LDAP authentication from users module? Or from YaST Auth Server/Client?

[taroth21]

I think I can help to clarify as I have been involved in this on the documentation side. ;)

It is about

• removing the ability to configure LDAP users from the YaST User Management module or
• investigating what it takes to make this functionality work with 389-ds.

I recently removed the OpenLDAP-related parts from the documentation and updated the docs for SLE 15 SP2/SP1/GA for 389-ds (with @Firstyear 's help). While doing so, I also checked the procedure described in the Security Guide, section 5.4 Configuring LDAP Users and Groups in YaST, see https://documentation.suse.com/sles/12-SP5/html/SLES-all/cha-security-ldap.html#sec-security-ldap-yast-usergr. It turned out that connecting to the (389-ds) LDAP server did not work when trying to configure LDAP users with the YaST user management module. Therefore Firstyear and me agreed to comment this section in the docs for now (SUSE/doc-sle@8789104) and to see what can be done to fix this problem on the software side.

[kobliha]

Ah, now I seem to understand a bit more, especially when really looking at yast/yast-auth-server#49 and yast/yast-auth-server#52

Guys, what's wrong with using Bugzilla and our real names, huh :)? Any decision about removal of functionality needs to be blessed internally anyway.

[Firstyear]

Bugzilla's product categories are too coarse to allow specific discussions, the notifications are really bad, and the ui not conductive to effective discussion?

EDIT: Clarification as I realised this may be too harsh. I think it's really hard to get responses from people in BZ. A lot of issues I raise there do go un-answered, or they take weeks to get assigned to the right person. It's a really frustrating experience, so it's much better to take this upstream, get direct conversations happening.

Well, we haven't decided to remove any functionality yet ... I think part of this is going to be asking how hard is it to fix? Should we fix it? How many people use this module?

[kobliha]

Point about Bugzilla taken ;) Yes, it may be sometimes difficult to get answers from people. And no, I do not have any good answer to that. Anyway, I believe, that if you open new bug against Installation/YaST, then we respond pretty quickly. We have a special person that takes care of new bugreports. But, of course, whether the bug gets fixed and when, depends on several aspects (importance, level of annoyance, period in development...).

There are several reasons, why we as a team still prefer Bugzilla:

• It may happen, and it often is that the "issue" is not "ours", so we reassign to some other team
• It often happens that the problem is for instance in some binary or library which is totally unrelated to the upstream project you may refer to (e.g., parted or systemd bug during installation)
• Changes file should contain some kind of traceable ID, and GitHub issues are still not supported
• We may require some decision being taken by project or product management and that is quite hard to do here in GitHub issue
• We can ask for attaching YaST logs ;) We usually need them to debug the problem

If we talk about this specific issue, then removing functionality in service-pack is usually not allowed. But since we haven't seen any (other) bugreports about this specific one, there is a chance. Frankly, we still don't know what the problem actually is.

[Firstyear]

@taroth21 has reported a problem, and I trust her that an issue exists. I plan to test the module with 389-ds myself in the next few days, and I'll submit a PR to fix/document and issues. Is that reasonable?

From what I understand it appears that the ldap module doesn't work with 389-ds, only with openldap, and since SUSE is dropping openldap in favour of 389-ds, we probably want this to work!

[Firstyear]

Hey there, I did some research into this and I can't recreate the problem that @taroth21 reported. I've emailed her personally for more information, but I have a few minor changes that I'll put in a PR to make the integration with 389-ds a bit smoother. Thanks for your patience!

[ancorgs]

So what's the status here. Can this be closed in the yast-users side?

[taroth21]

From digging into my old mails: I reported further details to @Firstyear, including two screenshots. According to his reply the resolution seems to be that I should have used the string 'anonymous' in the BindDN field (where I had entered 'CN=Administrator'). I don't recall if I have tried again with the setting suggested by @Firstyear and if I succeeded then. I did not follow up since then, so maybe @Firstyear has more details.

[Firstyear]

I don't think that was quite right, I think it was to use a dn other than cn=administrator. That's an OpenLDAP pattern, not a 389-ds one. You need to just use a correctly priviledged DN.

IMO this isn't a bug, it's just that the docs/examples probably need rework.

[ancorgs]

Ok. Closing this in the yast-users side then.