Unable to connect to LDAPS

[FooBarTrixibell]

Please confirm the following

• I agree to follow this project's code of conduct.
• I have checked the current issues for duplicates.
• I understand that AWX is open source software provided for free and that I might not receive a timely response.

Summary

When setting LDAP authentication to LDAPS (ldaps:servername:636) I get a message -

SERVER_DOWN({'result': -1, 'desc': "Can't contact LDAP server", 'errno': 110, 'ctrls': [], 'info': 'Connection timed out'})

When changing back to LDAP (ldap:servername:389) it works.

nmap shows the service as up and supporting TLS 1.2 -

PORT STATE SERVICE
636/tcp open ldapssl
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_RC4_128_MD5 - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
| TLSv1.1:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_RC4_128_MD5 - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
| TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_RSA_WITH_RC4_128_MD5 - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
|_ least strength: strong

I am using the same server with ldaps on other web services for authentication.

AWX version

20.1.0

Select the relevant components

• UI
• API
• Docs

Installation method

docker on linux

Modifications

no

Ansible version

2.9.27-1

Operating system

Centos 7

Web browser

No response

Steps to reproduce

Install clean docker image.
Setup LDAP options using LDAPS
Attempt to login to Web GUI

Expected results

Logon allowed

Actual results

LDAP server timeout

Additional information

No response

[FooBarTrixibell]

Sorry, that error was when I was trying the IP Address, with FQDN it gives -

SERVER_DOWN({'result': -1, 'desc': "Can't contact LDAP server", 'ctrls': []})

[FooBarTrixibell]

Might be related to CA, I am also getting a certificate error trying to sync a project from gitlab -

SSL certificate problem: unable to get local issuer certificate

I tried to add the CA to /etc/pki/ca-trust/source/anchors and then run update-ca-trust inside the awx container but it didn't fix this.

I must say, I really hate Docker and MiniCube, it would be nice to just apply my ansible configs to this to apply proxy/certificates etc.! Why do the AWX maintainers have this insistence on containerism?

[FooBarTrixibell]

I tried installing this in Kubernetes, the learning curve is horrendously steep and the complexity is stupid considering its only a database, a web server and an app server, all of which can run on a single monolithic server quite happily.

After installation I can get nothing useful to work as the network appears to be isolated to the host. I needed to reverse proxy with nginx just to get the frontend!

The whole thing is making me angry.

[fferraro87]

yes with ldaps i've same problem
SERVER_DOWN({'result': -1, 'desc': "Can't contact LDAP server", 'errno': 107, 'ctrls': [], 'info': 'Transport endpoint is not connected'})

[wwolkers]

for me, this was resolved by not checking the certificate anymore from AWX:

awx-cli setting modify AUTH_LDAP_CONNECTION_OPTIONS "{u'OPT_NETWORK_TIMEOUT': 30, u'OPT_REFERRALS': 0, u'OPT_X_TLS_REQUIRE_CERT': 0}"

[FooBarTrixibell]

Buried in the install documentation -

Trusting a Custom Certificate Authority

In cases which you need to trust a custom Certificate Authority, there are few variables you can customize for the awx-operator.

Trusting a custom Certificate Authority allows the AWX to access network services configured with SSL certificates issued locally, such as cloning a project from from an internal Git server via HTTPS. It is common for these scenarios, experiencing the error unable to verify the first certificate.

Name	Description	Default
ldap_cacert_secret	LDAP Certificate Authority secret name	''
bundle_cacert_secret	Certificate Authority secret name	''

Please note the awx-operator will look for the data field ldap-ca.crt in the specified secret when using the ldap_cacert_secret, whereas the data field bundle-ca.crt is required for bundle_cacert_secret parameter.

Example of customization could be:

---
spec:
  ...
  ldap_cacert_secret: <resourcename>-custom-certs
  bundle_cacert_secret: <resourcename>-custom-certs

To create the secret, you can use the command below:

# kubectl create secret generic <resourcename>-custom-certs \
    --from-file=ldap-ca.crt=<PATH/TO/YOUR/CA/PEM/FILE>  \
    --from-file=bundle-ca.crt=<PATH/TO/YOUR/CA/PEM/FILE>

Trusting a Custom Certificate Authority In cases which you need to trust a custom Certificate Authority, there are few variables you can customize for the awx-operator.

Trusting a custom Certificate Authority allows the AWX to access network services configured with SSL certificates issued locally, such as cloning a project from from an internal Git server via HTTPS. It is common for these scenarios, experiencing the error ansible/awx-operator#376.

Name Description Default
ldap_cacert_secret LDAP Certificate Authority secret name ''
bundle_cacert_secret Certificate Authority secret name ''
Please note the awx-operator will look for the data field ldap-ca.crt in the specified secret when using the ldap_cacert_secret, whereas the data field bundle-ca.crt is required for bundle_cacert_secret parameter.

Example of customization could be:

---

spec:
...
ldap_cacert_secret: -custom-certs
bundle_cacert_secret: -custom-certs
To create the secret, you can use the command below:

kubectl create secret generic -custom-certs \

--from-file=ldap-ca.crt=<PATH/TO/YOUR/CA/PEM/FILE>  \
--from-file=bundle-ca.crt=<PATH/TO/YOUR/CA/PEM/FILE>

[FooBarTrixibell]

Worth noting, I was NOT using the kubernetes install method (and as yet am still trying to get the damned thing to work) and this does not exist in the docker install document.

I think I am three days down on this simple upgrade. I am beginning to wish I had never started.

[FooBarTrixibell]

I still have not gotten this working, OPT_X_TLS_REQUIRE_CERT did not work, probably because I am not using tls but rather SSL (ldaps).

I tried the certificate as a secret and cant seem to get that working either. I had initially thought that the certificate was in the wrong format but after converting it to PEM and using the certificate chain in bundle it still didn't work.

I am giving up and running over 398 since this is probably the least of the security issues I have with this new install (now running on kuberneties as root with SElinux off and no firewall).

I think to progress this further I would need more verbose logging on the ldap connection, unfortunately the single line produced in debug mode tells pretty much nothing.