Choose one of the topics below for ISE Resources to help you on your journey with ISE
This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC!
We will not comment or assist with your TAC case in these forums.
I have been researching the use cases behind the IdentityAccessRestriction attribute in ISE and have encountered an issue which may be expected but i'd like your inputs.
Our flow is to connect using our smart card certificates to an ASA. The ASA strips out the CN field of the certificate (email@example.com) and then sends that via RADIUS to ISE using PAP ASCII. In ISE, we have an authentication policy which continues even if authentication fails (which it does in this flow as there are no passwords sent). Once we continue past the authentication policy, we start looking at the authorization policies. We then match a policy which checks the username against the AD store which validates the user is a member of a certain group and is then permitted access.
We are looking at using the ISE attribute IdentityAccessRestriction in addition to the rule above to check to see if the account is disabled or outside the logon hours specified in AD. In testing, if the AD account is disabled, we are able to successfully match on a condition which states IdentityAccessRestriction = True. However, if the logon hours are set, ISE does not update the IdentityAccessRestriction value to TRUE. If we perform a test user under the AD settings, ISE reports the user cannot logon due to login hour restrictions. Does the IdentityAccessRestriction attribute update for logon hours if authentication fails? IdentityAccessRestriction does update if the account is disabled and authentication fails which makes me think the query we send to AD is not pulling back the user attributes from AD which would tell us the account has logon hour restrictions.
The idea to use this attribute came from reading the following document
When authenticating or querying a user, Cisco ISE checks the following:
• MS-CHAPandPAPauthentications check if the user is disabled, locked out, expired or out of logon hours and the authentication
fails if some of these conditions are true.
• EAP-TLS authentications checks if the user is disabled or locked out and the authentication fails if some of these conditions is
Additionally, you can can set the IdentityAccessRestricted attribute if conditions mentioned above (for example, user disabled) are
met. IdentityAccessRestricted attribute isset in order to support legacy policies and is not required in Cisco ISE because authentication
fails if such conditions (for example, user disabled) are met.
Your responses are greatly appreciated.
Solved! Go to Solution.
Yes, I am able to reproduce this behavior in my lab environment. I'd be happy to meet with you to show you the test bed and the logs I have pulled during my test. My customer has also opened a TAC case for this and my lab test and customer debugs session logs are on the case. but there has been no movement on the case for two weeks.