ansible / awx

AWX provides a web-based user interface, REST API, and task engine built on top of Ansible. It is one of the upstream projects for Red Hat Ansible Automation Platform.
Other
13.98k stars 3.41k forks source link

Unable to connect to LDAPS #12042

Closed FooBarTrixibell closed 2 years ago

FooBarTrixibell commented 2 years ago

Please confirm the following

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_128SHA - 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

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 https://github.com/ansible/awx-operator/issues/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= \ --from-file=bundle-ca.crt=
FooBarTrixibell commented 2 years ago

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 commented 2 years ago

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.