SSL VPN Using Raidus VSA Group

[moby]

Hi Folks, I am trying to find out if the following is possible: Authentication for an SSL VPN where the authentication request is for a user is sent to radius, radius then returns the " Group-Name" VSA to inform the Fortigate which user group the user belongs to. Then based on that user group the user gets a specific SSL VPN portal. I think it may be possible, but I am wondering how to set it up - I' m thinking that I would need a policy that includes that radius server in the group and then other policies for each actual user group matching the VSA returned by Radius. I also assuming that I would need to create a user group with no actual users in it for each matching group returned as a radius VSA - and then the Fortigate would add the user to that group. Anyone know if this is possible? and how to do it? Cheers, Moby.

[Blacktip]

This is almost what I have been trying to do myself. My post (2 down from yours) is trying to achieve this with using LDAP group membership as opposed to VSA' s. I would be interested to see if you get an answer here and good luck.

[Blacktip]

I tried to attach this as a Word document to keep things clean, but apparently Fortinet wont let you do this. I' m not sure how this will come out without the images, but here goes. ################################################## Fortinet & Safenet Integration Radius Authentication and Radius Vendor Specific Attributes (VSA) For Identifying Group Membership of Users and Thereby Presenting the User with a Specific Web Portal Author: Kevin Jones Title: Team Leader – Network & Security Mail: blacktip@gmail.com Date: 15/10/2014 Executive Summary This document looks at the requirements, obstacles and workaround for how you can create a separate Web Portal for providing a separate view of resources to different target audiences whilst still using two form authentication and group membership for identification. If you just want to get this working without reading the ramblings of a mad man, then jump straight to the “Workaround” section. Opinions/Views in the document All options or views (correctly or incorrectly) made in this document are the personal opinion or judgement of the author by way of an outcome from some experimentation and should not be interpreted as or in any way shape or form the options of others or fact. Format I have chosen to use Microsoft Word as my choice of document format as many forums don’t allow you to include screenshots or add certain obscure files (should the need arise and what some call obscure other classify as normal) for fear that they may be passing something “dodgy” onto their clients even though they normally take the view of “you get it as is” or “we have done as much due diligence as possible”. Introduction The main reason I wrote this article was simply due to the fact that I was trying to do something that I thought should have been so easy to achieve but Ohhh this was not to be the case at all. I was unable to find an answer from the various parties concerned and in fact I almost lost my faith in all support desks and humanity in it’s entirely, but we persevered. I managed to find a document (in German I think and I’m Welsh, so please don’t hold that against me) but I needed the assistance of Google Translate to at least give me at least some hope of finding out what the hell that Author was talking about. Eventually after a few tries, I managed to work out what I needed to do to achieve the end goal and the result of which is ultimately this document hoping that this will help you guys if your all stuck in the dark place like I was with this problem. Technology Information Below is a list of technologies that are used to provision the solution and services as useful background information. Radius - General Wiki give a good explanation as Remote Authentication Dial In User Service (RADIUS) is a networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management for users that connect and use a network service. Because of the broad support and the ubiquitous nature of the RADIUS protocol, it is often used by ISPs and enterprises to manage access to the Internet or internal networks, wireless networks, and integrated e-mail services. These networks may incorporate modems, DSL, access points, VPNs, network ports, web servers, etc. RADIUS is a client/server protocol that runs in the application layer, using UDP as transport. Radius – Vendor Specific Attributes (VSA’s) Fortinet correctly states that Radius VSA’s are the method Radius servers and clients use to extend the basic functionality of RADIUS. Some major vendors, such as Microsoft, have published their VSAs, however many do not for some reason. In order to support vendor-specific attributes (VSA), the Radius server (SafeNet in my example) requires a dictionary to define which VSAs to support. This dictionary is typically supplied by the client vendor. Fort iGate’s VSA’s The FortiGate unit Radius VSA dictionary is supplied by Fortinet and is available through the Fortinet Knowledge Base or through Technical Support. Fortinet’s dictionary is configured with the following supported VSA extension (not to dissimilar to a very small SNMP MIB for those who understand): ## Fortinet’s VSA’s # VENDOR fortinet 12356 BEGIN-VENDOR fortinet ATTRIBUTE Fortinet-Group-Name 1 string ATTRIBUTE Fortinet-Client-IP-Address 2 ipaddr ATTRIBUTE Fortinet-Vdom-Name 3 string ATTRIBUTE Fortinet-Client-IPv6-Address 4 octets ATTRIBUTE Fortinet-Interface-Name 5 string ATTRIBUTE Fortinet-Access-Profile 6 string # # Integer Translations # END-VENDOR Fortinet SafeNet We use SafeNet’s Two-factor authentication service for user identification. SafeNet says, Two-factor authentication serves a vital function by securing access to corporate networks, and protecting the identities of users, and ensuring that a user is who they claims to be. Two-factor authentication ensures that users are who they claim to be by requiring them to identify themselves with a combination of: Something they know – password or PIN & Something they have – soft/hard token or smart card (two-factor authentication) Because strong authentication security requires multiple means of identification at login, it is widely recognized as the most secure software authentication method for authenticating access to data and applications and this mitigates against brute force attacks. The LDAP Synchronization Agent we use on the other hand has been developed to simplify the task of user creation in SafeNet Authentication Service. Without the agent, the administrator must manually input user information via the web based management interface. Once installed, the LDAP Synchronization Agent monitors LDAP groups for membership changes and updates user information in SafeNet Authentication Service to reflect these changes. LDAP Contrary to popular belief, the Lightweight Directory Access Protocol is an open, vendor-neutral, industry standard application protocol for accessing and maintaining a distributed directory of information services ran over an Internet Protocol (IP) network. Directory services play an important role in developing intranet and Internet applications by allowing the sharing of information about users, systems, networks, services, and applications throughout the network. As examples, directory services may provide any organized set of records, often with a hierarchical structure, such as a corporate email directory. Similarly, a telephone directory is a list of subscribers with an address and a phone number. A common usage of LDAP is to provide a " single sign on" where one password for a user is shared between many services, such as applying a company login code to web pages (so that staff log in only once to company computers, and then are automatically logged into the company intranet). In our example, the user’s who are authenticated will be presented with an “appropriate view” of a web portal based on group membership. Microsoft’s version of an LDAP directory structure is called Active directory and that is what they use for Directory Management. Problem/Issue What I was trying to achieve was quite simple in its concept. I was trying to achieve two form authentication using SafeNet’s Authentication Service Synchronisation Agent for synchronising all my users to the SafeNet Radius cloud (where I could use auto provisioning of their soft tokens, which is outside the scope of this document) and then use something like LDAP for group membership with the ultimate end result of “if you authenticate as X and you are a member of group Y then you get web portal Z”. Simple isn’t it.!!! Due to local government rules (governed really centrally and dictated down) and best practise techniques, we should for all incoming connections (keep in mind here as well that we deal with several 3rd parties) use:- • Two form authentication (something you know and something you have – PIN + OTP Token, like chip and PIN on your credit card). • And only present systems to authenticated users that they should have access to (web portals where all you can see is what you are allowed to manage or use). Symptoms/Observations/Issues What I noticed is that you can use Radius for Authentication, but I could not find a way no matter how I tried of creating a security policy which would then use LDAP for group membership details in conjunction with the Radius Authentication. Cause/Reason SSL policies are evaluated top down like normal firewall rules but you can’t “AND” the source of Radius Authentication “AND” LDAP group membership to display a specific Web Portal. This my friend’s is the nub of the problem!!! Fix/Resolution The real resolution here should be that you can use simple Radius for Authentication in an SSL Policy for Authentication and THEN use LDAP/FSSO group membership as an AND’ing effect “which” would then display the correct portal view that you want to display. For some strange reason (I’m sure it’s clear to those in the know), Fortinet think that Radius should be used for Authentication and LDAP or FSSO should be used for identity based decisions only and both can’t be currently used in conjunction with each other. Workaround First of all, let’s configure the SafeNet side of things as that’s nice and simple. When you login into the SafeNet management web portal, if you click on assignment and search for the User ID you are interested in assigning to a group. See below:- Once you have located the correct user, then click on their User ID and this will take you to page which displays everything about the specific user you have chosen. In the section called Radius Attributes, click on Add and change the Vendor to Fortinet from the drop down menu and then select Fortinet-Group-Name as an attribute and then enter some arbitrary text that you want to identify the group by (this must match at both ends of the configuration). See below:- You are now done with SafeNet. Now let’s configure the Radius server on the FortiGate unit. Go to Users & Device Authentication  Radius Servers. Click on create new and enter your credentials for the Radius Server settings, ensuring they match with the SafeNet settings. See below:- Now we need to create the group in FortiGate by going to Users & Device Users  User Groups. Click on create new and enter the details as below remembering to select the Radius Server you just created and ensuring that the Group name is exactly the same (FortiGate is very sensitive to case issues) name as you created on the SafeNet management portal for this User. See below:- Now create your web portal view that you want including any bookmarks you want people to be presented with. See below:- Under VPN  SSL  Settings, you now need to map the User Group with Radius Authentication to the Web Portal you created earlier. See below:- And finally you need to create the policy to allow connections through by going to Policy & Objects  IPv4 and click on create new, which then allows you to configure the Source IP, Destination IP and Protocols that you’re going to permit through. See below:- Your now done. If you now get a standard user to login to the SSL service, they should get the standard web portal that you probably already have. However, when the user who you assigned to a group called Web_Portal_1 logs in, they should see a totally different view. And that’s how you do it. It’s not pretty and requires you to manually map Users to the User Group in SafeNet, but we can only hope one day that SafeNet will find a way in which you can selectively and automatically assign a Radius Attribute from the LDAP group synchronisation process. References The following is list of references that I have either used in the document or is used as a pointer to further information where further reading will hopefully expand the reader’s knowledge about the subject. http://www.microsoft.com/ http://blog.boll.ch/?p=244 https://translate.google.com/ http://en.wikipedia.org/wiki/RADIUS http://docs-legacy.fortinet.com/fos50hlp/50/index.html#page/FortiOS%205.0%20Help/Servers.029.08.html Properties This article applies to: • SafeNet Authentication Synchronisation Agent Version 3.03.XYZ • FortiGate Version 5.0.9 & 5.2.1 Publication Status I classify this document as “in the public domain” and as such it can be referenced by anyone or from anywhere without any royalties or fear of litigation with the hope that the person who references this material will at least give me a nod of reference in their document that I attempted to help others and that’s good enough for me.