ISE 1.1.1 - RegisteredDevices Identity Group

[zztopping]

Working on building a ISE 1.1.1 system to match our internal security policies, and have hit a dilemma. Here goes:

The requirement states that there need to be differing network authorization profiles for different device types: Domain PCs, Non-Domain Workstations, iPads, and iPhone/Android Phones. Also, all (other than IP Phones and printers) endpoints must be self-registered by the user (My Devices workflow in CWA) who operates them so they appear in the My Device Portal.

In the authorization rules, there appear to be no way to create a  authorization rule to match a "profiled workstation" AND a "registered  device".

This is because within ISE, any endpoint that is "registered" joins the RegisteredDevices Identity Group, and is no longer a part of the configured indentity group created by the profiling system. For instance, a profiled Win7-Workstation is a member of the profiler-created Workstation IG until it is registered, then it becomes a member of the RegisteredDevices Identity Group.

So basically, it appears ISE does not support per-devicetype(from profiler) authorization rules *while also* supporting device registration ("My Devices").

Or am I missing something?

[Tarik Admani]

Hi,

Please test the Device IOS attribute and set that condition for your mobile devices while enforcing device registration. You should be able to add that in your authorization policy under the Add Attribute/Value Session:Device IOS...

Also how are you registered devices authenticating (windows vs mobile)? Are you authenticating them via peap or just letting them in with MAB?

Hope that helps.

Thanks,

Tarik Admani
*Please rate helpful posts*

[zztopping]

Thats great. I was so focused on using an identity group I did not see this as an option.

In a quick test, I added a compound condition to an existing working authz rule stating "Windows OR MacOSX" and a machine that has a MacOSX Lion idenity from Profiler did not match this rule. Removing this condition from the rule fixed it.

Are there any other configurations to do to make this session condition "active" or to debug it? Looking through the authentications screen doesnt show any debug of the Session:Device OS value for this Mac's session.

[Tarik Admani]

Hi,

Are you authenticating your mobile users (are you using mac filtering if they fall within the Registered Devices), can you post screenshots of your rule configuration and the mac osx authentication details.

The reason I am asking for this is that you can set the authentication condition (networkAccess:authentication method= mschapv2) which can segment the macbooks from the apple devices.

Thanks,

Tarik Admani
*Please rate helpful posts*

[zztopping]

Here is a screenshot of the rule in question:

and here is the breakout of the Compound condition called WorkstationOSs, based on your recommendation:

Without this compound condition, the authorization is matched. With it there, it is not matched, even though the endpoints are profiled as such.

[Tarik Admani]

HI,

Can you go to the endpoint entry in ISE for this mac address and see if the device OS is there? Are you using nmap?

Tarik Admani
*Please rate helpful posts*

[zztopping]

Yes, an example endpoint that did not match this authorization rule is showing the following under Idenities:

EndPointMatchedProfile	OS_X_Lion-Workstation
EndPointPolicy	OS_X_Lion-Workstation

[Tarik Admani]

I think the device OS is obtained from posturing or even the nmap probe.

Another attribute you can use is the Endpoints:PostureApplicable (set this value to equal NO) for your apple iDevice policy since ISE can not posture these endpoints.

Thanks,

Tarik Admani
*Please rate helpful posts*

[zztopping]

Makes sense, thanks for the advice.

But it seems like a roundabout way to do it. What if I wanted to have a Windows Policy and a Mac Policy? Or a Windows 7 versus Windows XP? ....all without posturing, that is.

Is this a known limitation in the product?

[Tarik Admani]

Its not a limitation, you have the option to fire the nmap probe in order to get the device-os or run posturing on your network to get that information on the client, currently there arent any specific OS profiles in ISE present in the dhcp/dns/http attributes that will tell you which OS the client is running.

If you are a geek like me then I can suggest you take a pcap of a win7/winxp/macosx, and look for an http get packet. If you can spot a specific difference in the user agent string between these devices you can use the built in profiling policies to create your own, it is real easy and this is what makes ISE even more powerful. You can create your own custom checks by using their rules as a great example.

Thanks,

Tarik Admani
*Please rate helpful posts*

[zztopping]

According to the TrustSec 2.1 guide, Endpoint Idenity Groups (my original method) is the approved way to accomplish this.

See Page 100:

http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns742/ns744/docs/howto_30_ise_profiling.pdf

With the advent of the My Device Portal and its use of the RegisteredDevices group to override a group set by Profiler, there appears to be no way to tie the result of the Profiler service into your Authorization rules.

To accomplish a workaround, you have to insert very specific rules to circumvent this limitation.

[zztopping]

Futhermore, this presentation verifies this as being a problem:

https://communities.cisco.com/docs/DOC-30940

[kianarbabifard]

Hi zztopping, hi Tarik Admani,

i have the same problem. Even with using NMAP my Android device is not being categorized in the correct Authorization Profile...

@zztopping: Did you find any solution for that scenario?

@Tarik Admani: Why is this so complicated? And why can't i use some Profiler Dictionaries (e.g. IP or DHCP) as Authorization condition?

EDIT: Can i just configure 4 conditions per AuthZ Profile? The 5th condition always overwrites the 4th condition...

[Tarik Admani]

Because the ip attribute is a profiling attribute and not an authorization condition. The goal here is to place the device in the appropriate endpoint database so that the authorization engine would run more efficiently and not have to wait for the ip user agent string to come through. Typically with dot1x attributes in dhcp and ip user agent string arent available till the authentication succeeds because dot1x is a l2 protocol.

If you build those into your authorization policy then you will never match, plus there is a default coa exception so that when a device transitions from unknown to profiled coa is triggered.

This is my assumption by working with the product. You can put this in as a feature enhancement and maybe Cisco can shed some light as if this will work or with not work.

Sent from Cisco Technical Support iPad App

[kianarbabifard]

thanks, i didn't think of that. now i understand...

OK, but why are all user registered devices automatically assigned to IdentityGroup "RegisteredDevices"?? As described here http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns742/ns744/docs/howto_30_ise_profiling.pdf (page 99): "RegisteredDevices is used by MyDevicesPortal and Native Supplicant Provisioning to designate endpoints registered by network access users."

I'm off the oppion that you are more flexible if e.g. user owned Android devices stay in the Android IdentityGroup and Workstations stay in the Workstation IdentityGroup...