SSL-VPN group member failed to logged in

[Shagma]

Firmware version is v5.2.1,build618

I have a user which is matched on a LDAP server. The user also has a FortiToken assigned, but I don't think that's relevant.

The user is a member of a firewall local group. This group is added to the SSL policy (under Source Address, Source User(s)).

When I try to log in the user through the FortiClient, I receive "Permission denied. (-455)".

The Fortigate logs: sslvpn_login_unknown_user.

I tried to set the users password to local as well, that did not work either.

However, if I add the user directly to the policy, I can log in. 

It seems that the policy does not process groups, only users. Is this correct? Then what do we need groups for?

[max_monterumisi]

I had the same problem and it took me two hours to solve it!! 

PROBLEM: the problem is how the 5.2.1 import the user.

SOLUTION: after the users creation, rename the user (User & Device -> Users definition) exactly as on "cn" field of Active Directory

EXAMPLE: on Active Directory you have this user:

cn=Pippo Franco,cn=myUsers,DC=myDomain,DC=local

when this user login in Windows it use myDomain\pippo.franco account.

When you ad the user from LDAP on Fortigate 5.2.1 it's create a new user named pippo.franco but If you try login on SSL VPN receive on the logs sslvpn_login_unknown_user error, the same errore if you use Pippo Franco, because this user not exist in Fortigate users definition.

To undestand better: If you using by CLI the command:

diag test authserver ldap "Server LDAP" pippo.franco password123

you have the same problem, but if you use the command:

diag test authserver ldap "Server LDAP" "Pippo Franco" password123

all work!

Then you must change the user name on User & Device -> Users pippo.franco in Pippo Franco and now all work well.

[Shagma]

Hi, thx for reply!

I'm not sure our problems are the same. My LDAP server is configured with sAMAccountNAme as common name identifier on the Fortigate. When I run diag test authserver ldap with the sAMAccountName i get a successful authentication.

[GCOMM]

I'm experiencing the exact same symptoms on 5.2.2. We don't use ldap often, so I can't say whether it broke before upgrading or not. Did you happen to find a solution?

[Shagma]

GCOMM wrote:

I'm experiencing the exact same symptoms on 5.2.2. We don't use ldap often, so I can't say whether it broke before upgrading or not. Did you happen to find a solution?

No, I am sorry to say I have not found a good solution. I have currently settled for adding users one by one to the firewall policy.

[npc423 · Accepted solution]

Shagma wrote:

GCOMM wrote:

I'm experiencing the exact same symptoms on 5.2.2. We don't use ldap often, so I can't say whether it broke before upgrading or not. Did you happen to find a solution?

No, I am sorry to say I have not found a good solution. I have currently settled for adding users one by one to the firewall policy.

I have been setting up a Fortigate 90D for the first time. I came across this issue.

It was fixed by adding both sAMAccountName in the Common Name Identifier field, and my domain (dc=mydomain,dc=local) in the Distinguished Name field.

I was under the impression that if I left both empty, Fortigate would use the entire forest, and any login attribute. This did not work, and I kept receiving failed logins. Once I entered values, authentication started working.

Do you have both fields filled in?

[yanivhs]

thank you npc423, finally a good explanation.

Just to make it clearer the "Common Name Identifier" field  should contain only sAMAccountName.

not something like cn=sAMAccountName.

Is there a way to use the LDAP users without adding them to the user list on the FW?

ie, the FW will check if the user have the "dial in" right.

[westekim]

I had a similar (if not same) problem and the first reason was that I didnt use sAMAccountName. When I changed that it started working for some users but not all. Now it seems like it doesn't work with nested groups.

For example, User1 is a member of Group1 and Group1 is a member of VPNUsers. User2 is a member of VPNUsers directly. In this case User2 can log in but User1 can not.