LDAP user authentication

Question

Hi community,

How does FortiGate verify the credentials of a remote LDAP user?

1. I understand that FortiGates queries or fetch the LDAP server for credentials.

2. According to NSE4 course, for server-based authentication the FortiGate sends the user's entered credentials to the remote authentication server, then the server responds if they are valid or not.

Then which is correct?

Regards,

Julián

xsilver_FTNT · Accepted Answer

Hi,

not sure if I fully understand to the question, but ...

Basically there are active (user interaction needed) and passive (no interaction) authentications.

In active ones like remote LDAP/RADIUS/TACACS, and local active ones like local users, there are user credentials in some way presented from user to FortiGate and then to local authd or via fnbamd to remote auth server (LDAP/RADIUS/TACACS).

From this point of view there is no exception that LDAP hands over user's credentials in some way to LDAP server.

That 'in-some-way' and 'user's credentials' is a little bit inaccurate, as you might have for example RADIUS with any CHAP based authentication like nowadays most used MSCHAPv2 and in those cases there is challenge-handshake between client (FGT) and server (RADIUS server for example on FAC). So there are actually NO clear credentials passed over the potentially insecure network.

In contrary there are passive authentications. Most of the called SSO (Single Sign-On). Which gather already made logon somewhere else to re-use it and authenticate user based on his previous auth. For example to harness logon to WiFi and via RSSO gather necessary data about the user from AD and pre-authenticate his traffic from the already authenticated workstation and let it pass through FortiGate (FGT).

So generally, the answer is no, it's not exception.

Kind regards,

Tomas

xsilver_FTNT · Answer

Ji Julián,

if you are curious then I would suggest to sniff the traffic and also run 'diag debug app fnbamd 7'.

And you should see that FGT do two staged authentication:

stage one

1. bind with provided regular user (from config) to gain connection to LDAP and anbility to search

2. search for username which was provided by end user who is trying to autrhenticate

stage two

3. tries LDAP bind again (as in 1.) BUT now with username verified as existing via step 2. and with password provided by end user

4. fnbamd then decide based on bind result .. bind successful = username OK + password OK = user authenticated. Anything else (errors or bind failure) mean user is not authenticated.

Kind regards,

Tomas

PS: noted is scenario with regular bind to LDAP as nowadays I do not see many LDAP servers allowing anonymous bind.

Sign up

Login with SSO

Login to the community

Login with SSO