I need help to configure NethServer to use external OpenLDAP server

NethServer Version: v7-rc2
Module: sssd

Hi there,

I’ve been struggling with this all day, but I finally give up and ask for help. :tired_face:

I just want to use NethServer with an existing OpenLDAP server. Fresh install of NethServer, I apply all updates and then I go straight to the “Users and Groups” section. I select “LDAP” and I fill in the IP address of the LDAP server. I wait while the config gets applied and things get restarted, and when it’s finished, after about 20 seconds, the page gets refreshed and I am left with an empty user table.

I look in /var/log/messages and I see no obvious problem there. It seems to get applied, but nothing seems to happen, no users and groups are pulled. Which, to be honest, does not surprise me, because:

  • I did not get to specify a bind user and password
  • I did not get to specify a base dn

Also, there is no way to specify ldaps instead of ldap. (It should work with either in my case.)

I have the feeling that I am missing something…

Is this the correct work flow for what I am trying to achieve?

Thanks in advance for the feedback!


1 Like

Me too! Thanks for pointing this out @lucian. I have to add at least some documentation about this!

The default configuration in sssd.conf have some preconditions on the remote LDAP server

  • rfc2307 schema
  • anonymous bind is allowed and the LDAP tree can be browsed anonymously
  • authenticated bind must be protected by STARTTLS

We found the default behavior of sssd is good for our LDAP setup, but of course there can be other variants, too. Can you provide more details about your LDAP server? What are its requirements?

Also can you query the rootDSE?

ldapsearch -h LDAPserver -b "" -s base "(objectclass=*)"
1 Like


Many thanks for the clarifications! Sorry for the delay in my response, I am mostly on the road these days.

I don’t think that the LDAP tree can be browsed anonymously. When I connect with phpldapadmin anonymously I do not see my users. When I connect authenticated (cn=admin,dc=example,dc=com) then I can see everything.

So I think I need to fix that.

Querying the rootDSE from the OpenLDAP server itself gives the following:

[root@dmz2-hq-buc myuser]# ldapsearch -h localhost -b "" -s base "(objectclass=*)"
ldap_sasl_interactive_bind_s: No such attribute (16)
[root@dmz2-hq-buc myuser]# 
[root@dmz2-hq-buc myuser]# 
[root@dmz2-hq-buc myuser]# 
[root@dmz2-hq-buc myuser]# ldapsearch -x -h localhost -b "" -s base "(objectclass=*)"
# extended LDIF
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: ALL

objectClass: top
objectClass: OpenLDAProotDSE

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
[root@dmz2-hq-buc myuser]# 

It seems to be successful, but only with the “-x” switch. Is this the correct/expected output?

1 Like

Create a custom-template in /etc/e-smith/templates-custom/etc/sssd/sssd.conf/01provider_config_credentials:

   $provider_config .= "ldap_default_bind_dn = cn=admin,dc=example,dc=com\n";
   $provider_config .= "ldap_default_authtok = your_s3cret\n";
   $provider_config .= "ldap_id_use_start_tls = true\n";


expand-template /etc/sssd/sssd.conf
systemctl restart sssd

@lucian, any news on this? Did you try the custom template? Does it work for you?

A new nethserver-sssd package is coming

@davidep, thanks a lot for the feedback! and sorry for the delay!

I tried the custom template and it worked (partially):

  • the users and groups tab of NethServer got populated - this is great;
  • but then I installed NextCloud from software center and the LDAP settings did not propagate correctly in NextCloud

Snippet from current sssd.conf (this is correct):

enumerate = True
use_fully_qualified_names = True
id_provider = ldap
ldap_uri = ldap://
ldap_search_base = dc=example,dc=com
ldap_tls_reqcert = never
cache_credentials = True
ldap_default_bind_dn = cn=admin,dc=example,dc=com
ldap_default_authtok = secret
ldap_id_use_start_tls = true
default_shell = /usr/libexec/openssh/sftp-server

Generated NextCloud settings (this is incorrect):

User DN: cn=ldapservice,dc=example,dc=com
Password: <empty>
Base DN: dc=directory,dc=nh

Of course, it is easy to correct the NextCloud config, but I guess the idea was to generate the right config autiomatically, since NethServer already has the info.

1 Like

We have now a package in testing! Can you test it?

Download latest updates

yum update


yum --enablerepo=nethserver-testing update nethserver-sssd
config setprop sssd BindDN cn=admin,dc=example,dc=com BindPassword secret

Check the settings are good

perl -MNethServer::SSSD -MJSON -e '$o = NethServer::SSSD->new(); print JSON::to_json({'BaseDN' => $o->baseDN(), 'BindDN' => $o->bindDN(), 'BindPassword' => $o->bindPassword(), 'UserDN' => $o->userDN(), 'GroupDN' => $o->groupDN(), 'LdapURI' => $o->ldapURI()});' | python -mjson.tool

To apply changes

signal-event nethserver-sssd-save
1 Like

Ok, I will do the test on a clean NethServer install.

Is this workflow ok?

  • install NethServer
  • update packages
  • reboot
  • configure LDAP server x.x.x.x as external account provider
  • update netserver-sssd as per your last post
  • check config and apply changes

Do I still create the custom template and expand then restart sssd?

1 Like

Generally speaking, reboot is required only to run a new Linux kernel version. Here should not be required.

When testing there are always two scenarios to consider ( /cc @quality_team )

  • New installation: nethserver-sssd from testing must be installed before configuring the external LDAP provider. No manual action required.
  • Update existing installation: nethserver-sssd from testing is updated after joining the external LDAP and the “signal-event” command must be issued manually

Keep us updated man, we need your feedback on this!

Sure. Sorry, I was busy today. I will try to do it a little later this evening or tomorrow morning.

1 Like

Test 1:

fresh install
yum --enablerepo=nethserver-testing update nethserver-sssd
config setprop sssd BindDN cn=admin,dc=example,dc=com BindPassword secret
configure external LDAP provider from GUI


  • GUI users and groups page gets populated
  • perl command gives this output:

“BaseDN”: “dc=directory,dc=nh”,
“BindDN”: “cn=admin,dc=example,dc=com”,
“BindPassword”: “secret”,
“GroupDN”: “ou=Groups,dc=directory,dc=nh”,
“LdapURI”: “ldap://”,
“UserDN”: “ou=People,dc=directory,dc=nh”
[root@nethserver ~]#

  • Next, I installed NextCloud from software center and I checked the LDAP settings page. It looks good, except for Base DN, which is “dc=directory,dc=nh”. And the message was “Configuration incorrect”. Changed Base DN to “dc=example,dc=com”, I got “Configuration OK”, then I checked the users page and it got populated ok.

Test 2:

fresh install
configure external LDAP provider from GUI
yum --enablerepo=nethserver-testing update nethserver-sssd
config setprop sssd BindDN cn=admin,dc=example,dc=com BindPassword secret
signal-event nethserver-sssd-save


  • exaclty the same as above

Thank you @lucian

I’m working on a fix:

1 Like

My comments on the above:

It’s great that now it’s working! :slight_smile: The Base DN propagation from NS to NC still needs to be fixed, though. That being said, I also think the following two features would be very useful:

1.The ability to manually specify the base DN (currently it is implied from the NS host name). This comes in handy when the LDAP server has subdomains. In my case, I have the following structure:

2.The ability to specify the base user tree and base group tree. For example, in my case, I could have:
NS host name: nethserver.customer1.com
Base DN: dc-example,dc=com
Base User tree: vd=customer1.com,o=hosting,dc=example,dc=com
Base Group tree: vd=customer1.com,o=hosting,dc=example,dc=com

This way, each customer could have its own NS with access to only its users and groups and the users and groups would have the proper email address (user@customerx.com). Base user tree and base group tree would also need to be propagated to the installed packages, for example in NextCloud LDAP Advanced settings page.

Thanks and have a nice weekend everyone!


Could you run a test? Now BaseDN, UserDN and GroupDN props should be honored!

Please update the packages from nethserver-testing:

yum --enablerepo=nethserver-testing update nethserver-sssd

Also the following packages have been updated in testing. You can update them, too:

  • nethserver-nextcloud
  • nethserver-ejabberd
  • nethserver-roundcubemail
  • nethserver-directory

See also:

1 Like

A post was split to a new topic: SOGo LDAP bind failed after updates

A post was split to a new topic: Zimbra 8 as LDAP account provider