On 27. sep. 2017 14:43, Roger Aas wrote:

...

...

Hi,

I have the NAV webfront LDAP authentication working with a Windows AD server, but only with unencrypted traffic on port 389.

In the file /etc/nav/webfront/webfront.conf

port = 389 encryption = none

It works well with search for user in the AD tree and group requirement.

But if I change encryption to tls, or port to 636 and encryption to ssl then it fails.

Anyone have this working? If yes, what did you have to do to get it to work?

I can not use it as it is as both the user account used for binding to the server and the user trying to authenticate have their passwords in cleartext in the packets.

Hi,

We use port = 389 and encryption = tls on our server. This works fine. My guess is that you have some issue with certificate validation.

Best regards, Sigmund

I am not sure what this can be, the AD server have a valid certificate, and the NAV server have the CA (by default) in /etc/ssl/certs.

A packet capture of the LDAP query seems mostly fine until I get a "Ignored Uknown Record" message in Wireshark. Then the client just finishes the connection.

o TCP 3-way handshake o NAV: Req LDAP_START_TLS_OID o AD: Resp LDAP_START_TLS_OID o NAV: Client Hello o AD: Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done o NAV: Certificate o NAV: Client Key Exchange, Change Cipher Spec o NAV: Encrypted Handshake Message o AD: Change Cipher Spec, Encrypted Handshake Message o NAV: Ignored Unknown Record o NAV: FIN,ACK o AD: ACK o AD: RST, ACK

The apache error log is not helpful (for me):

[Wed Sep 27 14:08:40.844212 2017] [wsgi:error] [pid 32247:tid 140541489465088] [ERROR] [pid=32247 nav.web.ldapauth] LDAP server is down [Wed Sep 27 14:08:40.844269 2017] [wsgi:error] [pid 32247:tid 140541489465088] Traceback (most recent call last): [Wed Sep 27 14:08:40.844278 2017] [wsgi:error] [pid 32247:tid 140541489465088] File "/usr/lib/python2.7/dist-packages/nav/web/ldapauth.py", line 101, in open_ldap [Wed Sep 27 14:08:40.844285 2017] [wsgi:error] [pid 32247:tid 140541489465088] lconn.start_tls_s() [Wed Sep 27 14:08:40.844316 2017] [wsgi:error] [pid 32247:tid 140541489465088] File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 564, in start_tls_s [Wed Sep 27 14:08:40.844324 2017] [wsgi:error] [pid 32247:tid 140541489465088] return self._ldap_call(self._l.start_tls_s) [Wed Sep 27 14:08:40.844330 2017] [wsgi:error] [pid 32247:tid 140541489465088] File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 99, in _ldap_call [Wed Sep 27 14:08:40.844336 2017] [wsgi:error] [pid 32247:tid 140541489465088] result = func(*args,**kwargs) [Wed Sep 27 14:08:40.844342 2017] [wsgi:error] [pid 32247:tid 140541489465088] CONNECT_ERROR: {'info': '(unknown error code)', 'desc': 'Connect error'}

The dreaded 'unknown error code'...

Any ideas?

Roger

Maybe the AD server only supports SSL/TLS protocol versions that the nav server does not like because of security issues (SSL2/3 or possible even TLS1.0). Or the AD server requires TLS1.2 and the nav server does not handle this? It could also be related to which cipher suits are supported by the different ends.

Best regards

Sigmund Augdal

On 27. sep. 2017 15:17, Roger Aas wrote:

...

Maybe the AD server only supports SSL/TLS protocol versions that the nav server does not like because of security issues (SSL2/3 or possible even TLS1.0). Or the AD server requires TLS1.2 and the nav server does not handle this? > It could also be related to which cipher suits are supported by the different ends.

Best regards Sigmund Augdal

But you said you are using a Windows AD server for LDAP also? What version? We use a mix of 2012R2 and 2016 here, I have tried both, but with the same result.

Roger

No, we are not using AD for this. It's just our webfront.conf that resembles what you tried to do.

Another idea: the ldap library NAV uses also ships with a CLI tool (ldapsearch). Using this tool should trigger most of the same code paths as NAV, while hopefully giving better feedback on the errors.

Examples:

Dummy search using starttls:

ldapsearch -Z -x -H ldap://ldap.uninett.no:389

using SSL:

ldapsearch -x -H ldaps://ldap.uninett.no:636

Best regards

Sigmund

I got it working. :-)

And with the help of the link from Morten I got it working without the manager user. The option 'suffix' was better explained there than in the configuration file. Always nice to not have one more service account in AD.

I now use port 389 with encryption tls to authenticate AD users that are members of an AD group giving access to NAV.

My issue was the AD ROOT CA certificate. The AD DC (ldap-server) I was contacting sent over a certificate that was issued by this ROOT CA in Windows AD. This cert was of course not among the many default certs on the NAV server. So I copied this cert from a domain machine to the NAV server path '/usr/local/share/ca-certificates' and ran the 'update-ca-certificates' command (Debian), restarted the apache web server, and it worked. It was not enough to have the official CA cert and the official intermediate cert that had signed this AD ROOT certificate on the NAV server, I needed this one in addition. Actually the official intermediate certificate was not in the default cert store either, "COMODO High-Assurance Secure Server CA", I had to copy this one to the NAV server also.

The command that help me realize this issue was:

root@Nav:~# gnutls-cli -p 636 ad-server.company.local -d 1 Processed 177 CA certificate(s). Resolving ' ad-server.company.local'... Connecting to 'xxxx:yyyy:zzzz:1406::b:636'... - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info:

[SNIP] The AD DC Server cert

- Certificate[1] info:

[SNIP] This was the AD SUB CA that had issued the above cert, this was in turn issued by the AD ROOT CA

- Status: The certificate is NOT trusted. The certificate issuer is unknown. <--------------- *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. *** Handshake has failed GnuTLS error: Error in the certificate.

Best regards, Roger