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.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Sure it should work but it sounds like your lockdown broke you.
Qs:
[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
PCNSE
NSE
StrongSwan
Thanks for the tips, Emnoc, I'll work on these.
[ul]I'll get back here once I have been able to access the device.
Thanks again.
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
PCNSE
NSE
StrongSwan
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!
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1502 | |
1011 | |
749 | |
443 | |
209 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.