Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
SOLVED: IPSec VPN, Radius. Distinguishing user groups
Hi,
After successfully configuring various types of VPN I' m left with a puzzle.
In the organization we have several different types of user (administrative, technical and so on). They are split into differet AD groups (VPN-Admin, VPN-Tech). So far so good.
I need to allow access based on these groups
VPN-Admin should be allowed only access to 172.16.1.0/24
VPN-Tech should be allowed access to 172.16.1.0/12
Am I right in assuming this would entail configuring 2 distinct RADIUS connetions to the same NPS server?
They could be evaluated differently based on NAS IP/Called Station ID (i.e. one would be called VPN-Admin and one VPN-Tech).
The NPS CRP would then evaluate this field and grant/deny access based on user membership.
Also there would need to be created equally many VPN Phase 1/2 definitions and policies.
It seems quite complex, and if I' m somehow missing something that makes assigning user rights simpler, please let me know.
Sincerely
Mikkel
--
Mikkel Andreasen
-- Mikkel Andreasen
9 REPLIES 9
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hi Mikkel,
another easier approach is interface your AD through LDAP.
You could Xauth (phase1 setting) against it and give appropiate rights to your users based on their credentials.
There' re many examples in this forum with similar scenarios to look for.
regards
regards
/ Abel
regards
/ Abel
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
Thank you for the suggestion. I went ahead and tried LDAP authentication with the following config
Restrict users from logging in through VPN
Restrict access once logged in (based on group membership
[/ol]
Am I going about this the wrong way?
Sincerely
Mikkel Andrease
Company_Fortigate_~ # show user ldap config user ldap edit " Company_LDAP_IT_Teknik" set server " IP.of.LDAP.Server" set cnid " sAMAccountName" set dn " DC=domain,DC=local" set type regular set username " CN=LdapAccount,CN=users,DC=domain,DC=local" set password ENC EncryptedPassword set filter " (&(objectcategory=user)(memberOf=CN=VPNUSERS,OU=Groups,OU=Company,DC=domain,DC=Local))" next endBut all users, regardless of group membership are permitted to login - that should no be the case.
Company_Fortigate_~ # diag test auth ldap Company_LDAP_IT_Teknik administrator LongAndDifficultPasswordWhichHasBeenRemoved! authenticate ' administrator' against ' Company_LDAP_IT_Teknik' succeeded!Login through FortClient works just fine as well It appears to be exactly the same situation as referenced in this posthttp://support.fortinet.com/forum/tm.asp?m=56998 I need to be able to [ol]
--
Mikkel Andreasen
-- Mikkel Andreasen
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
If this is remote access VPN you can do SSL VPN tunnel mode.
This is assuming you are using V4 MR2.
The key here is to be able to assign different IP ranges to SSL VPN
users depending on which group they belong. Once you get this working
its a matter of defining firewall policies to allow different ip ranges
access to your internal network.
Access to the Internal network via Tunnel Mode SSL VPN is controlled
by SSL.ROOT---> Internal firewall policy
You do not need 2 distinct radius connections just 1 will do. What you
will need are two NPS policies for your various groups.
First define your radius communications under
User--> Remote--> radius
Create SSL VPN portals for different
types of user groups needing different types of access.
You create portals under VPN-->SSL--Portal
You add a Tunnel Mode Widget to your portal.
Now edit the Tunnel-Mode widget and you
should be able to see " IP Pools" where you
can assign a different ip range for your users.
You then create firewall policies under SSL.Root---> Internal
you can now control access to internal by specifying the ip ranges
on the source address of the firewall policy.
Create your User group
User---> User Group
add remote authentication servers ( radius server), you should be able to
specify the AD group the user belongs to. Assign the SSL VPN portal
for this group. " check allow SSL VPN access" the choose the portal.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I got most of that already setup... Though I' m only on FortiOS 3 MR6 P6 - will that limit me?
What I got so far is
1. Working SSL (including tunnel mode)
2. 2 distinct user groups (one LDAP/RADIUS and one local firewall users) assigned IP address from distinct ranges. These IP ranges have different policies applied.
I would prefer to use RADIUS as we already use that for Wifi access.
What I need to complete this - I think - is to be able to assign user groups based on the RADIUS authentication.
This is where NPS comes into play. Sure I can design various NPS policies based on user groups, but what I' m missing is translating those groups into " User groups" on the firewall.
Gotta go - meeting with the boss...
Sincerely
Mikkel Andreasen
--
Mikkel Andreasen
-- Mikkel Andreasen
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I' m not sure if this is available on your firmware version.
config user group
edit " SSL_group"
set group-type firewall
set authtimeout 0
set http-digest-realm ' '
set sslvpn-portal " full-access"
set member " AD_radius"
config match
edit 0
set server-name AD_radius
set group-name VPN-Tech
end
end
I think this is what you need
" config match
edit 0
set server-name AD_radius
set group-name VPN-Tech "
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you very much - Unfortunately I don' t seem to have the options of specifying corresponding AD groups
# set group-type type of user group sslvpn-tunnel Enable/disable SSLVPN tunnel sslvpn-tunnel-startip Start IP in IP pool sslvpn-tunnel-endip End IP in IP pool sslvpn-split-tunneling Enable/disable SSLVPN split tunneling sslvpn-webapp Enable/disable SSLVPN web application sslvpn-http Enable/disable SSLVPN http/https proxy sslvpn-telnet Enable/disable SSLVPN telnet sslvpn-ftp Enable/disable SSLVPN ftp sslvpn-samba Enable/disable SSLVPN SMB/CIFS sslvpn-vnc Enable/disable SSLVPN vnc sslvpn-rdp Enable/disable SSLVPN rdp sslvpn-portal-heading SSLVPN portal heading message sslvpn-client-check SSLVPN Client security checking sslvpn-os-check Enable/disable SSLVPN OS check sslvpn-cache-cleaner Enable/disable SSLVPN cache cleaner sslvpn-bookmarks-group SSLVPN bookmarks group redir-url SSLVPN Client login redirect URL member set group membersSo both suggested options would appear to be unavailable in OS3MR6 :-( Gotta go talk to somebody about upgrading... Sincerely Mikkel Andreasen
--
Mikkel Andreasen
-- Mikkel Andreasen
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
just as a hint as I have no RADIUS server here to test:
According to the Auth Guide for FortiOS 3.00 MR7, you can define a RADIUS instance to use a Fortigate user group attribute:
config user radius edit <server_name> set all-usergroup disable ... set server <primary_ip_address> set secret <primary_password> set use-group-for-profile <group_profile_select> endAs you can define up to 10 RADIUS instances you could bind up to 10 user groups to the same server. You' d have to experiment with this a bit I guess.
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, I keep working on this, but not having much luck. Today I' ve spent some time with Wireshark running to see if that would get me anywhere.
The part with " set use-group-for-profile" is not sent to the Radius server (according to my wireshark dumps).
The I came across this post http://support.fortinet.com/forum/tm.asp?m=42565. It looks like exactly what I need, but, alas, I cannot get it to work.
My configuration is as follows
Company_Fortigate_~ (LDAPSERVER) # Company_Fortigate_~ (LDAPSERVER) # show config user ldap edit " LDAPSERVER" set server " LDAPSERVER.DOMAIN.local" set cnid " sAMAccountName" set dn " OU=Company,DC=DOMAIN,DC=local" set type regular set username " ldapforti" set password ENC xXNEEZwa7UWa9j0EW8KnPplqfJ7blLDuj5y8xFFZOMSl8ZXEKaW1TzXVBeElUwpEV088Kc0Nhv3432430hLAEIs3Sn23v3PPPsG2LuG+XpE7td5ZqS87fL set group " CN=VPN-Company-Konsulent,OU=Company,DC=DOMAIN,DC=local" set filter " (&(objectCategory=CN=Group,CN=Schema,CN=Configuration,DC=DOMAIN,DC=local)(member=*))" next endBut no matter what user I attempt to authenticate with I' m allowed access. Regardless of groupmembership. Looking at the Wireshark dumps I was puzzled by two things 1. that the name of the group never appeared 2. all LDAP binds are of type " simple" as opposed to " regular" In the beginnging I had an error in the " set filter" line (wrong domain name), and all authentication was working just fine... I don' t get it... /mikkel
--
Mikkel Andreasen
-- Mikkel Andreasen
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Eureka!
At long last it has been resolved!
I now have multiple LDAP querys towards several domains with group filtering and I can move forward setting up the correct policies (most are in place). Now I need to start designing SSL Tunnel VPN subnet and routing, but that will most likely be left to someone else.
The final, working configuration was
config user ldap edit " LDAP-COMPANY-Konsulent" set server " IP.ADDRESS.OF.DC" set cnid " sAMAccountName" set dn " DC=DOMAIN,dc=local" set type regular set username " CN=Ldapforti,OU=COMPANY,DC=DOMAIN,DC=local" set password ENCODEDPASSWORD set group " CN=VPNGROUP,OU=COMPANY,DC=DOMAIN,DC=local" next ENDWhich I thought I had attempted several times, but apparently took a while to finally nail down... live and learn. Thank you all for you assistance and patience! /mikkel
--
Mikkel Andreasen
-- Mikkel Andreasen