Hello again @anon36323116,
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.
