ISE 2.4 Authorization Profile setting an attribute in "Advanced Attribute Settings" does not work?

[gowen]

In an effort to avoid some looping MAB authentications, which I need to have do at least two authentications, I have created a custom endpoint boolean attribute that I assign "True" or "False" to and match against in multiple MAB Authorization Policies.  Initially I set it to true when adding a static endpoint to the ISE database.  I try to mark it to "false" in the Advanced Attributes Settings in my ISE Authorization Profile.  I see the Authorization Policy get hit and know the Authorization Profile I call runs.  It assigns the DACL and kicks off the reauthentication i need, but does not update my custom attribute.    I have my custom attribute update set up  in the authorization policy.   Here are the Attribute Details shown at the bottom of my Authorization Profile.

Access Type = ACCESS_ACCEPT
DACL = Deny_but_allow_domain
Session-Timeout = 60
Termination-Action = RADIUS-Request
AuthFirstPass = false

Has anyone successfully gotten a custom attribute field to be updated through the Advanced Attribute Settings of an ISE Authorization Profile?   Any one have an idea how to make this work??      OR has anyone found another way to insure that I can force two authentications of a device and then stop and not keep reauthenticating after two tries??  

Here is the use case I am trying to solve.

With ISE 2.4 patch 9, I am attempting to do some wired MAB authentication where I have endpoints statically defined in an Identity group and have a custom attribute defined, which holds the IP address assigned to the endpoint.  I want to authenticate and permit access to the MAB endpoint only if the connecting device MAC address is using the IP address that is stored in my custom, static IP address.  The intent is to make it more difficult to spoof a MAC address and get connected to the wired network.

I can only get the IP address of the connecting device from the RADIUS Framed IP Address, which is not included in the first RADIUS Access Request.  It is only included in a subsequent access request after device tracking / dhcp snooping has had a chance to learn the IP address of the newly connected device.  To get the MAC and Framed IP Address in the same Access Request, I need to force a 2nd reauthentication.  So if my stored IP address for the endpoint does not match the Framed IP Address in the 1st RADIUS access request (which it never does), I call an authorization profile which does a reauthentication in 30 seconds.  This works so now when the IP address of the defined device matches the Framed IP address passed in the 2nd RADIUS Access Request,  I call the correct authorization profile, which assigns the correct DACL and does not kick off a reauth. and the device stays connected.

This all works except for a device that never gets an IP address.  These devices will then loop forever doing reauthentications every 30 seconds, due to my Authorization policy kicking off a reauth every 30 seconds.  If it can set my custom attribute to false, then my Authorization Policies can ignore this device.

Any help would be appreciated.

[hslai]

ISE authorization profiles are not designed to update a custom attribute of an endpoint.

[gowen]

Too bad a custom attribute cannot be updated. Then ISE should not allow me the option to configure  that under the Advanced Attribute Settings in the authorization profile.

Is there some other way to set a flag for a device that I can test for in an authorization policy to insure we only do a reauthentication once?  We have some devices that may loop on reauthentication.

[Jason Kunst]

have you thought about some sort of system using the API to monitor and then try update?

[Mike.Cifelli]

IMO I think you are creating more work for the admins than what is necessary.  Why not consider enabling anomalous detection to deter mac spoofing?  Anomalous detection can give you the ability to identify rogue endpoints based on:

NAS-Port-Type: determines if access method changed

DHCP Class ID: determines if client/vendor type has changed

Endpoint Policy: identifies if a host endpoint profile has changed

Using that along with CoA you could quarantine hosts identified with anomalies mentioned above.  

[gowen]

I have tried using anomalous behavior detection and it is pretty much useless.  While it was on, I spoofed a MAC address of an active online endpoint and ISE just updated it's database entry for that endpoint to be the info of the new spoofed MAC address.   It did not flag it as anomalous.   You would think ISE could realize that there were two endpoints simultaneously on the wired network with the same MAC.  But not so!

Every anomalous behavior endpoint that was flagged (about 800)  in our network of 90,000 devices were not valid and ISE gave no error message to even tell why the endpoint was flagged as anomalous.  If I looked at specific flagged devices, they were all valid DHCP class changes.

Anomalous behavior detection, at least for wired networking, to date has been useless in our network.