New Member

Question

SSL VPN LDAP AD authentication stopped working

Forum|Forum|9 years ago
April 26, 2017
4 replies
9445 views

Hello all,

I am using AD authentication for SSL VPN users at all sites I am responsible for, and this works great. However, at one site the Exchange server required lockdown of secure protocols, ciphers, hashes and key exchanges; this Exchange server runs on the DC (SBS2011), and since those changes the FG won't authenticate users against AD-LDAP anymore.

See here https://www.nartac.com/Products/IISCrypto

The changes implemented help to secure the mail server against various attacks, and one of the changes is to disable SSL v2 and v3, as they are vulnerable, in favour of TLS.

Is there any way the FG-LDAP authentication can be made to work in such a situation, for instance using TLS?

Thanks in advance.

emnoc

New Member

Sure it should work but it sounds like your lockdown broke you.

Qs:

[ul]

where you using LDAP or LDAPS b4 the lockdown ? and is this just a SSL to TLS protocol change?

did you run ldapserach/curl against the AD servers and use LDAPS { 636 } ?

has the SMAccount changed ?

did your CAcert change ?

what version of FortiOS are you using ?

whats the current cfg "show full user ldap " ?

Do you have any internal firewall preventing the FGT as a leaps-client to hit the ldaps-server ?

did you run diag test autherver ldap-direct from cli-cmd[/ul]

e.g

diag test authserver ldap-direct 52.23.54.171 389

LDAP server '52.23.54.171' status is OK

diag test authserver ldap-direct 52.23.54.171 636

LDAP server '52.23.54.171' status is OK

I would start with the above and conduct some diagnostics

JaapHoetmerAuthor

New Member

Thanks for the tips, Emnoc, I'll work on these.

[ul]

The AD was already in LDAPS mode, as SBS2011 is delivered with its own CA on board. It has been working fine this way for years. I think it's the SSL to TLS change but I am not entirely certain, and I don't see how I can check the AD side to see the requests arrive. I have enabled AD auditing, but the resulting event log is a mess to go through and find useful data.

I can browse the LDAP using Softerra LDAP Browser, connecting over port 636, running on the AD.

The specific account to access the AD hasn't changed, the password is set not to expire, and I also tried with the domain admin account.

The DC's CACert has been renewed, and I have installed the new cert on the FG.

FortiOS was 5.2.9 but I have upgraded to 5.2.11 to see if that would fix it. It did not.

The FW connects straight into the LAN where the AD sits, no other internal device other than switches.

I'll try the command indicated, I have tried diag test authserver ldap <ldapserver> <username> <password> and that fails.[/ul]

I'll get back here once I have been able to access the device.

Thanks again.

emnoc

New Member

Sounds like authenentication credentials. To rule out ssl or tis, the fortigate should not matter any will negotiate with the AD server

I would use cUrl and openssl to ensure tls1.x is the only thing enabled and then test credentials using tls1.x

e.g to check if the ADserver is SSLv3 enabled

curl -k --sslv3 --verbose -u "mydomain\kfelix" ldaps://10.5.2.2/DC=example,DC=com

or for tls1.2

curl -k --tlsv1.2 --verbose -u "mydomain\kfelix" ldaps://10.5.2.2/DC=example,DC=com

You can crawl thru the various TLS sub-version to check each one. Doing the above validate you know what SSLversion or TLSversion is enable and double check your AD credentials and BaseDN.

It also double checks ldap vrs ldap. I hope that helps but you need to diagnose the auth-credentials.

Ken

Sign up

Login with SSO

Login to the community

Login with SSO