[strongSwan] roadwarrior user groups
andy.paton at hp.com
Thu Jun 27 14:26:42 CEST 2013
The only way I have thought to do this are around common resource groupings. So if you know that backend A & B are commonly accessed together then create a profile based on resource rather then end user /device.
We use this approach for quite a few scenarios, and really the manageability of the connection profiles hasn't been too much of a headache, if anything it has actually made it much easier to a) Debug and b) Monitor.
Business Development Solution Architect
andy.paton at hp.com
From: Daniel Pocock [mailto:daniel at pocock.com.au]
Sent: 27 June 2013 13:07
To: Paton, Andy
Cc: users at lists.strongswan.org
Subject: Re: [strongSwan] roadwarrior user groups
On 27/06/13 13:40, Paton, Andy wrote:
> We are doing this using Client Certificates.
> For example, we have Windows 8, Android and iOS devices, and we have
> two reasons for assigning different IP pools
> a) For identification of backend traffic
> b) To be able to hive users off to restriced subnets
(b) is the type of thing I had in mind
> We use different OU's in the Client Cert to achive this, for example:
> 1) OU = Sales will have access to leftsubnet 172.x.x.x and 162.x.x.x
> 2) OU = Dev will only have access to leftsubnet 172.x.x.x
> We basically have different connection profiles for each device / OU, and using a wildcard in the DN to allow access:
> e.g. rightid="C=EN, O=My Compnay, OU=DEV, CN*"
That's really helpful - I was looking at the "ConnSection" wiki page and it doesn't mention the use of the wildcard. For many people this is probably neater than creating another CA.
However, it only gets me half way there... imagine a scenario where you have two departments (Sales and Dev) and two types of device (laptop and mobile). The laptops are corporate managed devices but the mobiles are BYOD and are assumed to be full of malware.
So there are four permutations:
Sales/mobile (O=My Company, OU=Sales, D=mobile, CN*) Sales/laptop Dev/mobile Dev/laptop
Writing out all the permutations explicitly may not be scalable - would you know if there is any other administrative mechanism for dealing with such situations?
More information about the Users