Deployed a Cisco ISE 1.1.2. that is used to authenticate and posture validate for wired users, attached to Cisco IP Phones. Backend database is Microsoft AD.
At the first time both, users and IP Phones, pass authentication and posture validation steps successfully. When the user logs off from windows, the log off is done whithout any problem, and I can see it switch.
The problem takes place when the user try to log on again. The ise does not match the configured authenticion rules as in the first time, and put the user directly to default "DenyAccess" policy (rule).
Anyone out there experienced something similar or have any ideas on why this is happening?
Cisco ISE network enforcement points (switches) may be missing key configuration commands, may be assigning the wrong port (i.e., a port other than 1700), or have an incorrect or incorrectly entered key.
Ensure the following commands are present in the switch configuration file.
aaa server radius dynamic-author
• This could be either a MAB or 802.1X authentication issue.
• The authorization profile could be missing the Cisco av-pair=”device-traffic-class=voice” attribute. As a result, the switch does not recognize the traffic on the voice VLAN.
• The administrator did not add the endpoint as static identity, or did not allow an unregistered endpoint to pass. create a policy rule to (“Continue/Continue/Continue” upon failure).
• Verify that the Authorization Policy is framed properly for groups and conditions, and check to see whether the IP phone is profiled as an “IP phone”or as a “Cisco-device.”
• Verify the switch port configuration for multidomain and voice VLAN configuration.
• Add the continue/continue/continue to allow the endpoint to pass:
Choose Policy > Policy Elements > Results > Authentication > Allowed
Protocols to create a Protocol Policy. MAC authentications use PAP/ASCII and EAP-MD5 protocols. Enable the following MAB Protocols settings:
– Process Host Lookup
– Detect PAP as Host Lookup
– Detect EAP-MD5 as Host Lookup
• From the main menu, choose Policy > Authentication.
• Change the authentication method from Simple to Rule-Based
• Use the action icon to create new Authentication Method entries for MAB:
– Name: MAB
– Condition: IF MAB RADIUS:Service-Type == Call Check
– Protocols: allow protocols MAB_Protocols and use
– Identity Source: Internal
– Hosts: Continue/Continue/Continue
1. Choose Monitor > Authentications.
2. Scroll over and look for the "Failure reason."
Please Look for the details of the failed authentication record and click on the failure reason link under
Details > Resolution for the Authentication. The failure reason should be listed.
Correct the failure reason per the findings that are defined in the Possible Causes.
Check the Cisco ISE dashboard (Monitor > Authentications) for any indication regarding the nature of RADIUS communication loss. (Look for instances of your specified RADIUS usernames and scan the system messages that are associated with any error message entries.)
Log into the Cisco ISE CLI and enter the following command to produce RADIUS attribute output that may aid in debugging connection issues:
test aaa group radius
If this test command is successful, you should see the following attributes:
•Connect NAD IP address
•Connect Policy Service ISE node IP address
•Correct server key
•Recognized username or password
•Connectivity between the NAD and Policy Service ISE node
You can also use this command to help narrow the focus of the potential problem with RADIUS communication by deliberately specifying incorrect parameter values in the command line and then returning to the administrator dashboard (Monitor > Authentications) to view the type and frequency of error message entries that result from the incorrect command line. For example, to test whether or not user credentials may be the source of the problem, enter a username and or password that you know is incorrect, and then go look for error message entries that are pertinent to that username in the Monitor > Authentications page to see what Cisco ISE is reporting.)
Note This command does not validate whether or not the NAD is configured to use RADIUS, nor does it verify whether the NAD is configured to use the new AAA model.
Can you tell us more about the policies? Are you doing machine authentication and does your authentication policy for user authentication also include a condition for machine authentication? If you can provide some screenshots of your authorization policies along with the authentication report, that will help troubleshoot your issue much faster.
*Please rate helpful posts*
Thank you so much fore your help and attention!
But before changing any policy statement. I preffer try to find a solution/workaround in client machine side.
I've been doing some tests on the LAB environment, and I think that I find out the way to solve the problem.
I'm going to do more consistent tests in production inviroment.
The solution consists in the machine dot1x suplicant side (seet attachement - sorry my windows is in Portuguese).
The as I metioned before. The I've got the enviromment working fine by enabling only "User Authentication" and "Single Sing On" as showed in picture I sent before.
Thanks every one for helping me.
*Please rate helpful posts*