SSL VPN LDAP AD authentication stopped working

[JaapHoetmer]

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]

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

[JaapHoetmer]

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]

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

[JaapHoetmer]

Hi emnoc,

To close this issue off, the problem was resolved. It turns out that due to security patching with regards to the Exchange server the simple bind mechanism had been removed from the list of modules in the registry.

The original entry in the Registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders] "SecurityProviders"="credssp.dll, pwdssp.dll"

The modified entry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders] "SecurityProviders"="msapsspc.dll, schannel.dll, digest.dll, msnsspc.dll, credssp.dll"

As you can see, some SecurityProviders have been added, but pwdssp.dll was removed. After adding this dll to the list, the FG ldap authentication mechanism sprang back to life.

The odd thing is that not having this dll made it appear to work, but only partially. The login was validated, and the root ldap level was shown, but no child entries were shown.

Anyways, it works again, and your feedback helped me with the testing of the functionality.

Thanks again!