ISE Not Profiling Non-Domain Devices

[kknuckles]

I am having an issue where ISE is not profiling devices that do not belong to our domain. Machines with computer accounts in our domain get profiled with no issue. It does not matter if it is an apple device, windows device, or android device. The user can successfully get a prompt for their username and password, however they will get an error stating 'Incorrect Username or Password'. If I drill into the failed attempt, they get a 15039 Authorization Failed and it assigns DenyAccess to them. If I find the device by MAC address in the profiled endpoints, it remains UNKNOWN. If I manually assign a profile, then it lets the device on and successfully identifies the user. I need to be able to allow users to use their devices to gain access to the network.

SYSTEM INFO

ISE Ver: 1.1.4.218

Stand Alone Mode

Profiling Setup

DHCP - Interface ALL - Port 67

HTTP - Interface All

Radius

DNS - Timeout 2

Authorization Policies

Wireless Blacklist Default - if Blacklist and Wireless_802.1X then Blackhole_Wireless_Access

Profiled Cisco IP Phones - if Cisco-IP-Phone then Cisco_IP_Phones

OnlyMachineAuth if AD1:ExternalGroups EQUALS EDUORG/Users/Domain Computers then PermitAccess

Guest if WLC_Web_Authentication then Guest_Profile

Employee if (Apple-iPad OR Workstation OR Android) AND (Wireless_802.1X AND AD1:ExternalGroups EQUALS EDUORG/User Accounts/All Employees AND AD1:ExternalGroups NOT_EQUALS EDUORG/Students/All Students ) then Employee_Profile

Student if (Apple-iPad OR Workstation OR Android) AND (Wireless_802.1X AND AD1:ExternalGroups EQUALS EDUORG/Students/All Students AND AD1:ExternalGroups NOT_EQUALS EDUORG/User Accounts/All Employees ) then Student_Profile

Default if no matches, then DenyAccess

Any help would be greatly appreciated

Thanks,

Kevin

[Tarik Admani]

This could be an issue where ip helper statements are not assigned to the l3 interface for the guest network, if the guests layer 3 interface resides on a firewall then your best bet is to force users to be redirected to a device registration portal so the http probe can be triggered in this case.

If your non domain users are doing dot1x and using dhcp information is not a viable solution (firewall) then http is one way, keep in mind the http solution redirects users only once, subsequent connections will not require redirection.

Sent from Cisco Technical Support iPad App

[kknuckles]

Sorry for not explaining further. The guest network works flawlessly. Employees and students are the ones having the issues. They connect to the employee and student networks. The guest network is soley for guests. Employees and students still connect to their respective networks.

Employees, for example would connect to the 'employees' network. They are unable to connect with their personal device. With their district issued laptop they can get on with no issue. Their district issued laptop is a windows machine which is joined to the domain. However, if a district employee decides to bring their ipad, they will still connect to the employees network. This is where they get the issue. It will not let them connect. It prompts them for their username and password, but then does not allow them on. The same applies to students.

I hope this clarifies it a little better

Sent from Cisco Technical Support Android App

[Tarik Admani]

I understand, so when they connect to the network they are connecting to the same network (ssid) but they are not meeting the endpoint identity group of apple-x android or workstation.

If this is on wireless what version of code are you running? This could be an issue where the dhcp proxy is most likely enabled so dhcp broadcasts are proxied from the controller. If you are running 7.3 or above you should be able to run the dhcp profiling setting on the advanced settings of your ssid and making sure that the radius probe is enabled on the psns. This is known as the device sensor probe and should send the data you need.

Sent from Cisco Technical Support iPad App

[kknuckles]

This is on wireless. My controllers are at 7.3.112.0. When I look at the advanced page for the SSID on the controller, DHCP profiling is checked.

In the DHCP section, DHCP Server - Override is not checked. DHCP Addr. Assignment - Required is checked.

I have checked all the L3 interfaces across the network and they all have the ip helper-address statement on there and it is correct.

Where do I check the radius probe at? In ISE the radius option is checked in the profiling configuration.

[kknuckles]

Okay. I think it is one of my ISE rules killing it. Further down in one of the failed authentications, I found this error:

24423  ISE has not been able to confirm previous successful machine authentication for user in Active Directory.

If I manually register the device, using the my devices portal, then I can get the user on. My goal is to not make them use the My Devices Portal.

It would look like its trying to authenticate their machine in the directory, which would fail since their device won't be in the directory. I have to have machine authentication on due to devices that are essentially kiosks for any user to come up to and use as well as mobile labs that any user can use.

[Tarik Admani]

I do not think that is your issue, your issue is related to profiling. I am sure if you turn on radius profiling you should be able to start the profiling process for the users. Currently with dhcp and http you are not going to be profile the users successfully. My assumption is...with your network design that you probably arent forwarding dhcp packets over to the ise psn.

The machine authentication method is typical message regardless if you are performing machine authentication or not in your deployment, its more informative in the event you are for that specific use case.

Tarik Admani
*Please rate helpful posts*

[kknuckles]

This turned out to be an issue with authorization policies. The original policies listed above were valid with our original implementation of ISE. However, when we went through patch upgrades, the device profile rules changed. Apple iPads were getting profiled as Apple-Device. Some android devices had gotten properly profiled and authorized, just not the ones we were testing. Many windows workstations were not getting profiled under the workstation profile. They were getting profiled as Windows-Device or Windows-Workstation, which for some reason would not get put under Workstation.

We corrected the policies and everything started working correctly.

[Muhammad Munir]

Hi

Possible Causes:

The default Auth rule is to deny access, and there are no specific Auth rules for this session.

Resolution:

The  authorization profile with the ACCESS_REJECT attribute was selected as a  result of the matching authorization rule. Check the appropriate  authorization policy rule-results.

For more information regarding configuration, please go through the given below link:

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

[blenka]

Hi,

Your error code shows it's a policy created is wrong or missing.

[Sheraz.Salim]

Hi I am running into a same problem. we are using ise version 1.2.8.899 patch 5,2,3. how did you resolve this issue?