LDAP user authentication

[fjulianom]

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 solution]

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. 

[xsilver_FTNT · Accepted solution]

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 · Accepted solution]

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. 

[fjulianom]

Hi Tomas,

Thanks for the explanation. Then, is LDAP server authentication an exception in server-based authentication method where FortiGates sends the entered user credentials to the server and waits for a respond (NSE4)?

Regards,

Julián

[xsilver_FTNT · Accepted solution]

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

[emnoc · Accepted solution]

To further explain

LDAP authenticates by simple or anonymous or even SASL. Anonymous is almost never use, "simple" provides a ldap_clientuser  and password ( clear text btw ) unless you  thrown over  TLS.

So your credentials for the bind  user and account and the  "enduser" that's being   validate are sent unencrypted unless LDAPS is in use.

Ken