SSL VPN & LDAP Fails - No Matching Policy

Forum|Forum|14 years ago
June 17, 2011
8 replies
35392 views

I am following this KB article: http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&externalId=FD32359 trying to use LDAP to authenticate users logging into the SSL Portal based on their group membership in AD. I have two AD user groups and depending on which group the user belongs to they will get one of either two portal pages. I tested logging in as any user of either AD group but I get a permission denied error with an alert message in the event log: " SSL user failed to logged in" Reason: no_matching_policy" My Fortigate - 200B/v4MR2 Patch 7 LDAP config config user ldap edit " LDAPServer" set server " 10.50.1.2" set cnid " sAMAccountName" set dn " dc=domain,dc=local" set type regular set username " CN=LDAP Agent,OU=Agents,DC=XYZ,DC=local" set password ENC next end The two VPN Groups to authenticate config user group edit " GeneralVPN" set sslvpn-portal " Default" set member " alane" " LDAPServer" config match edit 1 set server-name " LDAPServer" set group-name " CN=GeneralVPN,OU=Vancouver,OU=Users,OU=company,DC=XYZ,DC=local" next end next edit " AccountingVPN" set sslvpn-portal " Accounting" set member " LDAPServer" config match edit 1 set server-name " LDAPServer" set group-name " CN=AccountingVPN,OU=Vancouver,OU=Users,OU=company,DC=XYZ,DC=local" next end next end Firewall policies. This is at the top of the list. config firewall policy edit 11 set srcintf " WAN1" set dstintf " switch" set srcaddr " All" set dstaddr " Vancouver" set action ssl-vpn set nat enable config identity-based-policy edit 2 set schedule " always" set logtraffic enable set groups " GeneralVPN" set service " ANY" next edit 3 set schedule " always" set groups " AccountingVPN" set service " ANY" next end next end I also have a policy from ssl.root/All -> Internal/internal range set to Accept/Any/Always as well Here' s a debug output for sslvpn PGD-FGT200B # [62:root]SSL state:before/accept initialization (74.198.150.243) [62:root]SSL state:SSLv2/v3 read client hello A:system lib(74.198.150.243) [62:root]SSL state:SSLv3 read client hello A (74.198.150.243) [62:root]SSL state:SSLv3 write server hello A (74.198.150.243) [62:root]SSL state:SSLv3 write change cipher spec A (74.198.150.243) [62:root]SSL state:SSLv3 write finished B (74.198.150.243) [62:root]SSL state:SSLv3 flush data (74.198.150.243) [62:root]SSL state:SSLv3 read finished A:system lib(74.198.150.243) [62:root]SSL state:SSLv3 read finished A:system lib(74.198.150.243) [62:root]SSL state:SSLv3 read finished A (74.198.150.243) [62:root]SSL state:SSL negotiation finished successfully (74.198.150.243) [62:root]two factor check for test: off [62:root]Auth failed due to group restrictions [62:root]rmt_logincheck.c:207 user[test],auth_type=32768 failed [no_matching_policy] [62:root]rmt_websession.c:47 status=1;host=74.198.150.243;fails=1;logintime=1308336797 [62:root]SSL state:warning close notify (74.198.150.243) [62:root]SSL state:warning close notify (74.198.150.243) [62:root]Destroy sconn 0x99c8988, connSize=0. [62:root]SSL state:before/accept initialization (74.198.150.243) [62:root]SSL state:SSLv2/v3 read client hello A:system lib(74.198.150.243) [62:root]SSL state:SSLv3 read client hello A (74.198.150.243) [62:root]SSL state:SSLv3 write server hello A (74.198.150.243) [62:root]SSL state:SSLv3 write certificate A (74.198.150.243) [62:root]SSL state:SSLv3 write server done A (74.198.150.243) [62:root]SSL state:SSLv3 flush data (74.198.150.243) [62:root]SSL state:SSLv3 read client certificate A:system lib(74.198.150.243) [62:root]SSL state:SSLv3 read client certificate A:system lib(74.198.150.243) [62:root]SSL state:SSLv3 read client key exchange A (74.198.150.243) [62:root]SSL state:SSLv3 read certificate verify A:system lib(74.198.150.243) [62:root]SSL state:SSLv3 read certificate verify A:system lib(74.198.150.243) [62:root]SSL state:SSLv3 read finished A (74.198.150.243) [62:root]SSL state:SSLv3 write change cipher spec A (74.198.150.243) [62:root]SSL state:SSLv3 write finished B (74.198.150.243) [62:root]SSL state:SSLv3 flush data (74.198.150.243) [62:root]SSL state:SSL negotiation finished successfully (74.198.150.243) [62:root]SSL state:warning close notify (74.198.150.243) [62:root]SSL state:warning close notify (74.198.150.243) [62:root]Destroy sconn 0x99c8988, connSize=0. Any help would be greatly appreciated while I await TAC to respond. Regards, Eric

gunthnp

New Member

your user DN is off it should look more like set dn " OU=Users,DC=Domain,DC=local" the DN need to be set to the OU the users are in and the LDAP account need read access to that OU

ericlamAuthor

New Member

My LDAP Server is configured to look starting at my root of dc=domin, dc=local, so I don' t think that' s the case.

rwpatterson

New Member

The below works for me:

  fortigate $ show user ldap    config user ldap       edit " RDP Users"            set server " xxx.xxx.xxx.xxx"            set cnid " samaccountname"            set dn " dc=ad,dc=company,dc=domain"            set type regular           set username " cn=fortigate,cn=users,dc=ad,dc=company,dc=domain"            set password ENC blah-blah-blah           set group " cn=RDP Users,cn=users,dc=ad,dc=company,dc=domain"        next   end      fortigate $

AD doesn' t use Organizational Units (OUs) I believe. Try changing them to containers (CN). Granted, I' m running 4.1.x. It' s a bit different syntax, but the actual contents are in the same format.

ericlamAuthor

New Member

Tried using CN instead of OU and no change.

ericlamAuthor

New Member

I managed to fix the issue. It turned out the LDAP user I had created for the LDAP connector needed to be made part of the Domain Admin group in order for this to work. I didn' t think this was an issue as I was always able to hit that Windows Explorer button and browse my AD structure and see user accounts and security groups from the Fortigate... Thanks for trying to help anyways rwpatterson

A

Anonymous_User

Contributor

i configured ssl vpn in my fortigate as its shown in fortigate handbook but while iam loging its show permission denied and in log its show no matiching _policy . i checked there is no any typo error i tried so manay time but it doesnt work any body please help me i confiured user user group for ssl vpn i create firewall policy for that(iam doing only web access vpn)

murilo

New Member

same problem here... - when we tried with local user: works fine - when we tried with LDAP>AD group: " permission denied" (LOG: " SSL user failed to logged in" Reason: no_matching_policy" ) but, just for some users... After comparing the security policy of the users in AD... Everybody member of the group " Pre-Windows 2000 Compatible Access Group" had no problem like " permission denied" so, after add this " Pre-Windows 2000 Compatible Access Group" to the users (in SECURITY PROPRIETIES), solved the problem.

Zhuo

Explorer

I also encountered this problem a few days ago, the same log error.
In my environment, FortiGate did the HA master-standby mode and enabled ha-direct, which led to the connection from the management port when connecting to ldap. My solution was to specify source-ip in ldap, which solved this problem.

Hope this case helps you