10-17-2014 11:25 AM
We are working on integrating out new AD environment into the CPPM.
I would like to change the way that we do our Role Mappings and Enforcement.
We are using EAP-MSCHAPv2 to do all our of domain user and domain computer authentication.
Computer authentication provides a user-role that has limited access to the network.
User authentication changes the user-role to provide additional network access.
We have some computers that need to be placed into different subnets. We are currently accomplishing this using a combination of Role Mappings. We assign the roles based on a custom attribute that we apply to the device in the Endpoints database. We went this route in the beginning because very earlier on we were having a lot of issues with machine authentication and after we fixed that, we never really adjusted any of our rules.
I have been thinking about using AD groups to organize the machines going forward and doing Role Mappings based on those group memberships.
I am just curious if this is a good approach or if there are better practises that I should be following.
10-17-2014 12:10 PM
I am glad that I wasn't completely out to lunch with my plan.
When you say AD attributes are referring to the attributes that are visible under the "Attribute Editor" when we view of the properties of user or computer object?
Sorry for ignorance, I am still learning AD :D
10-17-2014 12:22 PM
For example, you could use the Department attribute to put a user in the correct subnet. The big thing with AD is ensuring that the data stays up to date. Many organizations now script this data from an ERP or HRIS system so it tends to be up to date and consistent formatting.
Many universities add custom attributes in AD for Class Year, advisor, student ID number etc.
You would just have to add the attribute in the AD authentication source.
10-17-2014 12:45 PM
Ah that makes sense!
That actually sounds like an interesting option.
It is similar to using the endpoints database with a custom attribute, except that you are using AD.
So I would assume that in our authentication source we would just have to add an attribute that pulls our custom attribute out of AD and makes it available to be evaluated?
10-17-2014 12:53 PM
Thanks @cappalli for your advice.
I want to try and make sure we start out on the right foot.
We are extending our 802.1x coverage to switch ports as well so I want things to be as easily flexible as possible.
10-22-2014 11:13 AM
I was wondering if there was a way to carry forward certain Role mappings?
For instance, if I map a role based on a computer account that authenticates, can I carry that role forward if a user signs in on the computer and then authenticates against the CPPM? We were initially accomplishing this by using the endpoint database with a custom attribute.
I know that the [Machine Authenticated] role is available even when doing user authentication. But I need a role that is a little more specific.
The only solution I can think of is to just not do user authentication and only do machine authentication.
The down side is that my machine role firewall settings would need to be adjusted. Currently our machine roles on the controller are very limited.
10-22-2014 11:14 AM
10-22-2014 11:21 AM
What I am experiencing in my testing is as follows.
I have the wireless profile set to do user or machine authentication.
When I fire up the computer and the machine authenticates with its AD account it receives a special role based on an attribute I set in the AD.
When I sign in on the computer and the user authentication takes place, that role that was assigned at the time that the machine authenticated is now no longer available. This makes sense since the users account doesn't have the attribute that I specified.
So when I setup my enforcement I can't accurately place the machine/user into the appropriate VLAN.
Not sure if that makes sense.
I need some way of maintaining that role obtained by the machine account for when user authentication takes place.