LDAP + TLS not working after update to v3.2.6 #799
Comments
|
I've tested this new image but unfortunately LDAP is not working with the same specs prior to the update.
I can ping the ldap server both from host machine and container. Didn't test it with plain text. Image used: v3.2.6-2.0.0 |
|
@oyxnaut - Could you try manually pointing it at the certificate? django-auth-ldap/django-auth-ldap#198 (comment) You can add it in ./configuration/ldap/extra.py if you map that file in. |
|
I also get the same error: But my LDAP uses an official CA certificate, so it would be not possible for me to use |
|
@netsandbox - Could you try to set |
This works. My I had to add the |
|
Setting |
The new image uses debian as a base instead of alpine. Not sure if there's actual differences between openldap-dev (alpine) and libldap-dev (debian) as they are the same product, but it seems that the debian version doesn't use the system cacerts by default. I think it might make sense for us to set |
|
The Netbox LDAP Backend (based on django-auth-ldap) has at the moment no way to set the I have opened an issue for Netbox that addresses the problem. I have prepared a fix from which I will open a PR when (or if) the issue is accepted. |
|
@tobiasge - I don't think I understand why it can't just be put in AUTH_LDAP_CONNECTION_OPTIONS like suggested above?
AUTH_LDAP_CONNECTION_OPTIONS should support it and is already mentioned in the docs for setting ldap.OPT_REFERRALS. |
As a workaround its a good solution. But I think if we get the option into Netbox it will benefit more users. To be consistent I choose the same way as was used for |
Will you amend the issue to request the option for specifying a directory also? Otherwise I don't see it solving the issue that the debian build broke LDAPS handling. That is not respecting the system certificate store. We really should be setting that by default to match the previous (sane) behavior. |
|
In import ldap
AUTH_LDAP_CONNECTION_OPTIONS = {
ldap.OPT_X_TLS_CACERTDIR: '/etc/ssl/certs'
}wasn't sufficient to get the LDAP server certificate accepted, I had to use this: import ldap
AUTH_LDAP_CONNECTION_OPTIONS = {
ldap.OPT_X_TLS_CACERTDIR: '/etc/ssl/certs',
ldap.OPT_X_TLS_REQUIRE_CERT: ldap.OPT_X_TLS_ALLOW,
ldap.OPT_X_TLS_NEWCTX: 0
}(see also #799 (comment)) @tobiasge please account for this in your change for netbox-community/netbox#9722, |
|
This essentially disables certificate verification, so that's not a valid way to fix it for the default setup. I don't have a setup to help verify it though. It didn't work with only Our AD does not have a public certificate, so sadly I can't help validating right now. |
|
Without So there is still a certificate validation problem. |
|
I think the problem is not only LDAP because after updating from v3.2.4 to 3.2.6 I have the following error with Redis configured for TLS : Edit: upgrade from v3.2.4 to 3.2.5 works. |
How are you loading your self-signed redis certificate into the netbox container? |
|
It's not a self-signed certificate, it's a certificate signed by our internal certificate authority. The root certificate of this authority is mounted as file in |
|
@keliansb - Not sure that is related to the issue here and it's sadly not possible to help you without you providing all the information. Feel free to create a seperate issue with more information. One thing you could try is installing the certificate the right way. That is extending the image and adding the certificate with something like this: |
|
Did some testing with an AD server with a private ca signed certificate. The following procedure was done to install the certificate in the system store: Pre debian image (v3.2.5): Works Debian image (v.3.2.6): Doesn't work Debian image (v.3.2.6) with OPT_X_TLS_CACERTDIR set to Doesn't work, maybe I have misunderstood the option as it should work as update-ca-certificates copies the file to the folder. Debian image (v.3.2.6) with OPT_X_TLS_CACERTFILE set to Works. The config looks like this in So maybe that should be the solution @tobiasge ? Just having ldap.OPT_X_TLS_CACERTFILE set to the system cacerts by default and then maybe update the wiki to instruct people as to how you provide your own ca certificates? I do however have no idea why python-ldap is not picking up the system certificate store by default, maybe it is because of the difference between openldap-dev and libldap-dev? The system certificate store is clearly working, as stuff like curl functions as intended. |
|
@kkthxbye-code I can confirm your observation in #799 (comment), but we use in our case a certificate from a official CA, which is also in /etc/ssl/certs and /etc/ssl/certs/ca-certificates.crt. |
Thanks for your help @kkthxbye-code! After a proper installation of the certificate (with |
|
I spent some time debugging this and found the solution. The image does not have file /etc/ldap/ldap.conf which contains The file is provided by package libldap-common which is NOT installed. To fix this, just add installation of libldap-common package to the Dockerfile I would create a merge request but the change is so trivial, that I hope this comment will suffice. |
|
Tested also by me and the fix provided by @jiri-lunacek works as expected and resumes the behavior of previous versions. So thanks! |
|
Closed with #808 |
|
Will you retag the old images with version 2.0.0? |
Please do not do that. It's a nightmare unless you can manually go to the machine and force pull a new image. Those of us that run NetBox in Kubernetes clusters will thank you. |
|
Well, the fix it's backward compatible unless you are inheriting from those images (e.g. you fixed it yourself) |
It's not about the compatibility, it's about the fact that Docker won't pull a new image with the same tag unless forced to. Plus it's just an overall crappy thing to do. There were changes made, that should be reflected in the version number. |
Current Behavior
After the update from
3.2.5-ldapto3.2.6, LDAP with ldaps://, and ldap:// + StartTLS aren't working anymore.When using ldap:// + StartTLS, it throws this error:
Caught LDAPError while authenticating testuser: CONNECT_ERROR({'result': -11, 'desc': 'Connect error', 'ctrls': [], 'info': '(unknown error code)'}).When using ldaps://, it throws this error:
Caught LDAPError while authenticating testuser: SERVER_DOWN({'result': -1, 'desc': "Can't contact LDAP server", 'ctrls': [], 'info': '(unknown error code)'})Using plaintext LDAP works, so the server is not down, and the error messages are misleading.
I thought maybe there's something wrong with the CA, or server certificate, and ran
openssl verify <(openssl s_client -showcerts -connect contoso.com:636 </dev/null)inside the netbox container. This turned out to work as expected:My Dockerfile to bundle the CA certificate:
Expected Behavior
I expect to be able to log in.
Docker Compose Version
docker-compose version 1.25.0, build unknown (it's the one packaged for Ubuntu 20.04)
Docker Version
The git Revision
b45934c
The git Status
Startup Command
docker-compose up
NetBox Logs
Content of docker-compose.override.yml
The text was updated successfully, but these errors were encountered: