Simple LDAP option

Hello again. I am attempting to setup the LDAP Service and noticed it requires a certificate path for TLS connections. My LDAP server is cloud hosted through a third party and they have informed me that it, “only supports simple authentication configurations and doesn’t allow for LDAPS with x.509 certificates or anonymous authentication.”

Is there a way to bypass the certificate requirement, or allow LDAP instead of LDAPS? It’s also possible that my provider doesn’t know what they’re talking about as they didn’t know what LDAP was when I reached out to their support team :smiley:

Any help would be much appreciated, and I’m already super grateful for this active and helpful community.

Hello again @reid,

Thanks for reaching out about this; I’m afraid this requirement is my doing when updating our LDAP logic and backend. Indeed, I decided to follow SSSD’s (our backend tool to manage LDAP/AD) recommendation to use TLS encryption:

LDAP back end supports id, auth, access and chpass providers. If you want to authenticate against an LDAP server either TLS/SSL or LDAPS is required. sssd does not support authentication over an unencrypted channel. If the LDAP server is used only as an identity provider, an encrypted channel is not needed.
source: https://linux.die.net/man/5/sssd-ldap

This change was part of a bigger update detailed in: https://github.com/rockstor/rockstor-core/pull/2235#issue-762971766

Now, as you experience, this might be a bit over-zealous if it prevents some users like yourself to use LDAP altogether so we might want to revisit this hard requirement.

Unfortunately, there isn’t a way in Rockstor webUI to bypass this certificate requirement.
Fortunately, however, as the Rockstor webUI is “simply” providing an interface to configuring SSSD, it means that we can circumvent the problem by manually changing the certificate requirement in SSSD’s config.

Now, this part is not as fresh in my mind as it used to be when I made those changes, so it may require a few trials to get it right but if you are ok with it, we can try a few adjustments to SSSD’s configuration file to get your LDAP set up. I unfortunately do not have access to my test LDAP server at the moment so I can’t verify these changes on my end before suggesting them to you; my apologies.

As detailed in the Github pull-request linked above, here is what Rockstor writes to SSSD’s config file (/etc/sssd/sssd.conf):

[sssd]
(...)
domains = rockldapserver.example.com
(...)
[domain/rockldapserver.example.com]
ldap_tls_reqcert = demand
ldap_id_use_start_tls = True
cache_credentials = True
auth_provider = ldap
chpass_provider = ldap
enumerate = True
ldap_tls_cacert = /etc/ssl/certs/ldapcacert.crt
ldap_search_base = dc=example,dc=com
id_provider = ldap
ldap_uri = ldap://rockldapserver.example.com
ldap_tls_cacertdir = /etc/ssl/certs

The first step would be to replace all mentions of rockldapserver.example.com with your own ldap server address, of course.
Then, we can try changing the parameters related to the tls cert:

[sssd]
(...)
domains = rockldapserver.example.com
(...)
[domain/rockldapserver.example.com]
ldap_tls_reqcert = never
ldap_id_use_start_tls = false
cache_credentials = True
auth_provider = ldap
chpass_provider = ldap
enumerate = True
#ldap_tls_cacert = /etc/ssl/certs/ldapcacert.crt
ldap_search_base = dc=example,dc=com
id_provider = ldap
ldap_uri = ldap://rockldapserver.example.com
#ldap_tls_cacertdir = /etc/ssl/certs

You also need to make sure that the system will check sssd for users/groups by adding the sss bit to the passwd and group lines of /etc/nsswitch.conf as below:

passwd: compat sss
group:  compat sss

You can then restart the sssd service to see if everything is working as intended:
(you need to be logged in as root for the lines below):

systemctl stop sssd
systemctl enable sssd
systemctl start sssd

If all is well, you should now be able to see your LDAP users/groups. If it doesn’t work, you would need to have a look at the logs; the following may be of interest:

  • SSSD logs: located in /var/log/sssd/
  • system logs: journalctl -u sssd.service

Hope this helps, and sorry again I cannot provide a much simpler answer for the moment; I’m hoping to get my test LDAP server up and running soon so that we can easily troubleshoot this sort of things.

2 Likes

This is all super helpful, thank you so much.

I’m running into a bit of a snag I think, however. I edited both the sssd.conf and nsswitch.conf files, verified the changes were applied, but when I try to run the systemctl stop/enable/start commands I get an error.

Job for sssd.service failed because the control process exited with error code.
See "systemctl status sssd.service" and "journalctl -xe" for details.

[hostname]: systemctl status sssd.service
sssd.service - System Security Services Daemon
Loaded: loaded (usr/lib/systemd/system/sssd.service: enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Fri 2022-07-08 [time]
Process: 14649 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited, status=4)
Main PID: 14649 (code=exited, status=4)

systemd[1]: Starting System Security Services Daemon...
sssd[14649]: SSSD couldn't load the configuration database [2]: No such file or directory
systemd[1]: sssd.service: Main process exited, code=exited, status=4/NOPERMISSION
system[1]: sssd.service: Failed with result 'exit-code'.
systemd[1]: Failed to start System Security Services Daemon.

I noticed the “NOPERMISSION” status and thought that might be something, but I was logged into ‘root’ when I tried to run the systemctl commands. Not sure what most of this means, but any help would be greatly appreciated.

1 Like

Thanks for the logs and the information… I think we may need to verify your /etc/sssd/sssd.conf file.

This actually can occur for a variety of reasons, to the best of my knowledge, and I think we need to pay attention to the line from sssd just above that:

sssd[14649]: SSSD couldn't load the configuration database [2]: No such file or directory

By the way, did you have to create the file altogether or did you simply edit what was already in place?

Let’s first see if it’s there and what the permissions are:

ls -la /etc/sssd/sssd*

We can also make sure the correct permissions are applied:

-chmod 6000 /etc/sssd/sssd.conf-

EDIT: The line above should read: chmod 600 /etc/sssd/sssd.conf

Try restarting the service in case that was the issue:

systemctl restart sssd

If it still is problematic, then would you mind posting the contents of your conf file? You can always anonymize any information you don’t want to share, of course! There are a few lines that are required in that conf file and we just need to make sure they are there.

cat /etc/sssd/sssd.conf

We can then take it from there; I’ll try to get a working example out as soon as I can.

2 Likes

The file was already in place, but I had to add quite a few lines pertaining to the TLS certs as they hadn’t been added yet due to my inability to enable the LDAP service in the WebUI.

Before modifying the permissions, it was:
-rw------- 1 root root 2154 Jul 8 11:36 /etc/sssd/sssd.conf

After modifying, it is this:
---S--S--- 1 root root 2154 Jul 8 13:40 /etc/sssd/sssd.conf

I then tried the systemctl restart command and got the same error. Here is the output of the cat command. I didn’t modify any of the AD lines as I assumed they didn’t apply to my configuration. Thanks again for everything.

[HOSTNAME] # cat /etc/sssd/sssd.conf
[sssd]
config_file_version = 2
services = nss, pam
# SSSD will not start if you do not configure any domains.
# Add new domain configurations as [domain/<NAME>] sections, and
# then add the list of domains (in the order you want them to be
# queried) to the "domains" attribute below and uncomment it.
; domains = ldap.DOMAIN.com

[nss]

[pam]

# Example LDAP domain
; [domain/ldap.DOMAIN.com]
; ldap_tls_reqcert = never
; ldap_id_use_start_tls = false
; cache_credentials = true
; id_provider = ldap
; auth_provider = ldap
; chpass_provider = ldap
# ldap_tls_cacert = /etc/ssl/certs/ldapcert.crt
# ldap_tls_cacertdir = /etc/ssl/certs
# ldap_schema can be set to "rfc2307", which stores group member names in the
# "memberuid" attribute, or to "rfc2307bis", which stores group member DNs in
# the "member" attribute. If you do not know this value, ask your LDAP
# administrator.
; ldap_schema = rfc2307
; ldap_uri = ldap://ldap.DOMAIN.com
; ldap_search_base = ou=users,dc=COMPANY,dc=DOMAIN,dc=com
# Note that enabling enumeration will have a moderate performance impact.
# Consequently, the default value for enumeration is FALSE.
# Refer to the sssd.conf man page for full details.
; enumerate = TRUE
# Allow offline logins by locally storing password hashes (default: false).
; cache_credentials = true

# An example Active Directory domain. Please note that this configuration
# works for AD 2003R2 and AD 2008, because they use pretty much RFC2307bis
# compliant attribute names. To support UNIX clients with AD 2003 or older,
# you must install Microsoft Services For UNIX and map LDAP attributes onto
# msSFU30* attribute names.
; [domain/AD]
; id_provider = ldap
; auth_provider = krb5
; chpass_provider = krb5
;
; ldap_uri = ldap://your.ad.example.com
; ldap_search_base = dc=example,dc=com
; ldap_schema = rfc2307bis
; ldap_sasl_mech = GSSAPI
; ldap_user_object_class = user
; ldap_group_object_class = group
; ldap_user_home_directory = unixHomeDirectory
; ldap_user_principal = userPrincipalName
; ldap_account_expire_policy = ad
; ldap_force_upper_case_realm = true
;
; krb5_server = your.ad.example.com
; krb5_realm = EXAMPLE.COM}
1 Like

@reid Hello there. Just chipping in with this:

I suspect the following:

has one too many zeros. Try the same with 600 which is “-rw — ---” i.e. as it was.

Hope that helps.

3 Likes

Ah, thanks. Got it changed back :smiley:

Sorry for the extra 0 in the chmod command; I didn’t notice my typo. Thank you @phillxnet for catching that.

@reid, thanks a lot for all the information; it’s very helpful. I noticed something odd in your sssd.conf: the comments.
Indeed, the manpage for sssd.conf says:

A line comment starts with a hash sign ("#") or a semicolon (";"). Inline comments are not supported.

This means that almost all the necessary lines are ignored by SSSD when parsing the file. This may explain the no such file or directory error you were seeing (as it is equivalent as having no domain configured).

Could you try the following?

[sssd]
config_file_version = 2
services = nss, pam
# SSSD will not start if you do not configure any domains.
# Add new domain configurations as [domain/<NAME>] sections, and
# then add the list of domains (in the order you want them to be
# queried) to the "domains" attribute below and uncomment it.
domains = ldap.DOMAIN.com

[nss]

[pam]

# Example LDAP domain
[domain/ldap.DOMAIN.com]
ldap_tls_reqcert = never
ldap_id_use_start_tls = false
cache_credentials = true
id_provider = ldap
; auth_provider = ldap
; chpass_provider = ldap
# ldap_tls_cacert = /etc/ssl/certs/ldapcert.crt
# ldap_tls_cacertdir = /etc/ssl/certs
# ldap_schema can be set to "rfc2307", which stores group member names in the
# "memberuid" attribute, or to "rfc2307bis", which stores group member DNs in
# the "member" attribute. If you do not know this value, ask your LDAP
# administrator.
; ldap_schema = rfc2307
ldap_uri = ldap://ldap.DOMAIN.com
ldap_search_base = ou=users,dc=COMPANY,dc=DOMAIN,dc=com
# Note that enabling enumeration will have a moderate performance impact.
# Consequently, the default value for enumeration is FALSE.
# Refer to the sssd.conf man page for full details.
enumerate = true
# Allow offline logins by locally storing password hashes (default: false).
; cache_credentials = true

Make sure, also, that your ldap_search_base is correct.

Now, try again restarting the sssd service (systemctl restart sssd).

3 Likes

Hello hello. Hope your weekend was pleasant!

I made the adjustments you specified, and the SSSD service restarted and was enabled successfully (!) but the LDAP service was still not toggled on under Services. For fun, I entered the path server, base DN, and made a fake path for the cert and then toggled it on, but it didn’t populate any new groups or users through the LDAP connecton.

So I guess I’m still not sure what I’m doing wrong, haha. I’ll go ahead and post the cat printout for sssd.conf again just to double check. Thanks.

[sssd]
config_file_version = 2
services = nss, pam

# SSSD will not start if you do not configure any domains.
# Add new domain configurations as [domain/<NAME>] sections, and
# then add the list of domains (in the order you want them to be
# queried) to the "domains" attribute below and uncomment it.

domains = ldap.DOMAIN.com

[nss]

[pam]

# Example LDAP domain

[domain/ldap.DOMAIN.com]
ldap_tls_reqcert = never
ldap_id_use_start_tls = false
cache_credentials = true
id_provider = ldap

; auth_provider = ldap
; chpass_provider = ldap

# ldap_tls_cacert = /etc/ssl/certs/ldapcert.crt
# ldap_tls_cacertdir = /etc/ssl/certs
# ldap_schema can be set to "rfc2307", which stores group member names in the
# "memberuid" attribute, or to "rfc2307bis", which stores group member DNs in
# the "member" attribute. If you do not know this value, ask your LDAP
# administrator.

; ldap_schema = rfc2307

ldap_uri = ldap://ldap.DOMAIN.com

ldap_search_base = ou=users,dc=COMPANY,dc=DOMAIN,dc=com

# Note that enabling enumeration will have a moderate performance impact.
# Consequently, the default value for enumeration is FALSE.
# Refer to the sssd.conf man page for full details.

enumerate = true

# Allow offline logins by locally storing password hashes (default: false).

; cache_credentials = true

Thanks so much.

1 Like

Just a quick follow up on this. Still tinkering around and not sure where I’m going wrong. Don’t want to waste your time going around in circles on this, haha, but if you had any more insight I’d be thrilled to identify where I’m going wrong.

Appreciate it!

Hi @reid,

Sorry for the silence on this. I’d like to test the proper settings you would need on my end so that I don’t make you change things randomly. For that, I need to setup an LDAP server on my own and I unfortunately am running out of time for this lately as I have quite a few tight deadlines at work. I’m hoping to have something to test in the second half of next week.

Sorry for the delay.

4 Likes

Hey no worries at all! Thanks so much for the follow up. I’ll be on the lookout for your reply over the next few weeks, and thanks again for being so vigilant with this request. Really above and beyond.

Have a good weekend!

3 Likes

Hi @reid,

Sorry it took so long for me to get back to you. I was able to finally find some time to standardize a bit more my test LDAP server and I see a few things that we need to troubleshoot first so that we know what settings you would need and thus how we can improve Rockstor’s LDAP implementation.

The idea here would be to know to know what step is actually failing for you here. It would thus be helpful if you could provide us the results of the following tests. If one fails, then the next one shouldn’t work so no need to continue further. In all examples below, please use your own server name; replace rockstortest.com with your server.

Before we do anything, let’s make sure you have the tools needed to run one of these tests:

zypper in openldap2-client

First, let’s make sure you can reach your LDAP server without problem:
ping <servername>
In my test server case, for instance, I have the following:

rockdev:~ # ping -c 1 rockstortest.com
PING rockstortest.com (192.168.122.1) 56(84) bytes of data.
64 bytes from rockstortest.com (192.168.122.1): icmp_seq=1 ttl=64 time=0.513 ms

--- rockstortest.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.513/0.513/0.513/0.000 ms

Second, do you need a bind DN user to make any query to the LDAP server?

  • if you do, does the following work? ldapsearch -x -W -H ldap://rockstortest.com:389 -b dc=rockstortest,dc=com -D "cn=admin,dc=rockstortest,dc=com"
  • if you do not, does the following work? ldapsearch -x -W -H ldap://rockstortest.com:389 -b dc=rockstortest,dc=com

Third, let’s see what SSSD is telling us. We would need to increase its log level so that we can see more information in them. Let’s also simplify the config file at /etc/sssd/sssd.conf.
As before, make sure you have your domain listed in the domains = line. In my example, it is:

domains = rockstortest.com

Then, let’s take care of the config for your server:

  • If you do not need a bind dn user:
[domain/rockstortest.com]
debug_level = 6
ldap_tls_reqcert = never
ldap_id_use_start_tls = False
cache_credentials = True
; auth_provider = ldap
chpass_provider = ldap
enumerate = True
; ldap_tls_cacert = /etc/openldap/certs/openldap-ca.crt
ldap_search_base = dc=rockstortest,dc=com
id_provider = ldap
ldap_uri = ldap://rockstortest.com
ldap_tls_cacertdir = /etc/openldap/certs
  • if you do need a bind dn user:
[domain/rockstortest.com]
debug_level = 6
ldap_tls_reqcert = never
ldap_id_use_start_tls = False
cache_credentials = True
; auth_provider = ldap
chpass_provider = ldap
enumerate = True
; ldap_tls_cacert = /etc/openldap/certs/openldap-ca.crt
ldap_search_base = dc=rockstortest,dc=com
id_provider = ldap
ldap_uri = ldap://rockstortest.com
ldap_tls_cacertdir = /etc/openldap/certs
ldap_default_bind_dn = cn=admin,dc=rockstortest,dc=com
ldap_default_authtok = <password_of_the_bind_dn_user>

Now, restart the sssd service: systemctl restart sssd
And then, verify the service is up (paste the output of the command below as it can provide some hints as to what goes wrong… you can anonymize any information you’d like, of course):

systemctl status sssd

Now, we can look at the logs for your specific server. You will have a log file dedicated to your server at:
/var/log/sssd/sssd_<servername>.log

Hope this helps,

4 Likes