Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
SSL VPN & LDAP Fails - No Matching Policy
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
11 REPLIES 11
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com
Bob - self proclaimed posting junkie!See my Fortigate related scripts
at: http://fortigate.camerabob.com
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Tried using CN instead of OU and no change.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Have you tried browsing your LDAP structure to see if maybe it' s not what you have entered into the FGT?
Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com
Bob - self proclaimed posting junkie!See my Fortigate related scripts
at: http://fortigate.camerabob.com
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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

Not applicable
Created on ‎09-25-2011 01:37 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
