Profiling bug or something else...?

[rezaalikhani]

Hi all;

Please consider the following figure:

ISE 3.2 with Patch 6

Any ideas?

Thanks

[davidgfriedman]

I tried putting that GigaByte motherboard MAC address (1c:6f:65:47:1d:d1) you listed, into my lab ISE v3.2p4 instance. It was unknown as well, meaning there is (in at least v3.2) no profiling family for gigabyte-device. That makes sense since I think of Gigabyte as a motherboard company, and motherboards can often run many different OS. 

The real question is the data you gathered: do you have any information for this MAC Address within Context Visibility -> Endpoints, to indicate a total certainty factor over 0/Unknown? Do you see at least one item under that endpoints Other Attributes with match one or more conditions under Profiling Policies->Workstation?  If none, then it remaining Unknown makes sense.  However, with your ISE seeming to guess the OS was Windows 10 Education, I would have expected at least one DHCP learned condition to give you a total certainty of 10 toward the Workstation profile instead of staying Unknown.  When you check that out, you'll know if it is a bug to call Cisco TAC, or if you're just not getting enough data to properly match Workstation - this assumes you have profiling policies to match workstations (or ones specific to Gigabyte) and it not matching is your concern. 

If you have another concern, then I am running down the wrong rabbit hole. If you have profiling policies specific to Gigabyte motherboards, then feel free to share it / them and all relevant profiling conditions, plus the learned attributes of the endpoint so we can help you try to figure out why the profile isn't matching / catching.

Regards,
David

[Arne Bier]

Is your ISE AD integrated, and are those endpoints AD domain joined?  If they are domain joined, then I would reckon that you have AD Profiling Probe enabled on ISE, and it's getting this level of information from the Domain Controller. The OUI means nothing in relation to the final profile. It's just the MAC OUI, and it can be a starting point for profiling.

[rezaalikhani]

Thanks for your reply;

Is your ISE AD integrated, and are those endpoints AD domain joined?

---

Yes, you are right. ISE is joined to the domain.

If they are domain joined, then I would reckon that you have AD Profiling Probe enabled on ISE, and it's getting this level of information from the Domain Controller.

---

Yes. AD Probe is already enabled in my ISE cube.

Now my question is, although AD Probe has completed its duty without any problem, why not ISE profiles the endpoint using this gathered attribute. I have around 30 endpoints with this situation...

Thanks

[rezaalikhani]

Can anyone give me some dipper insight why ISE takes this behavior and confirm this behaviour is a bug or a normal operation?

Thanks 

[andrewswanson]

In ISE 3.2 patch 3 there is a Profiling policy called Windows10-Workstation (Policy > Profiling > Profiling Policy)

This policy has a number of condition rules, only one of which has to pass to match the policy.
One of these rules is called Windows10-Workstation-Rule5-Check1 (Policy > Policy Elements > Conditions > Profiling > Profiling Conditions)

This rule matches on the following attribue:

Type: ACTIVEDIRECTORY_PROBE
Attribute Name: AD-Operating-System
Operator: CONTAINS
Attribute Value: Windows 10

Is the above still the case with patch 6?

hth
Andy

[rezaalikhani]

Yes there is:

[andrewswanson]

Forgot to mention that Windows10-Workstation's parent policy is Microsoft-Workstation.

Microsoft-Workstation uses attributes other than AD probe attributes to match - dhcp, nmap, anyconnect etc.

I'd think that to match Windows10-Workstation, the endpoint would have to match the parent Microsoft-Workstation first.

hth
Andy

[rezaalikhani]

The strange thing is that, there are about 30 endpoints with this behaviour and nearly 500 windows 10 endpoints with correct profiling...

[Arne Bier · Accepted solution]

Assuming that there is no bug in ISE (this is my hypothesis) then I would rule out the following potential issues. I don't know your setup and what the common factor is with those endpoints that are not profiling, but here goes:

- @andrewswanson is correct about Microsoft-Workstation being the foundation for further profiling - and in my experience with Windows hosts, DHCP is always used (why would you not use DHCP, right?) - is DHCP snooping enabled on the switch? Is device-sensor working (can you see the DHCP packets in the cache)? Is RADIUS accounting setup correctly to send the data to ISE?

- Profiling also relies heavily on CoA - ISE must be successful in re-authing the session to get to the next stage of profiling - if CoA is broken, then we mistakenly blame ISE for not doing it job - but the cause is often missing/wrong CoA config on switch - test CoA! You should also be prompted/reminded of the CoA alarm bell theory, when you "fix the problem" by doing a "clear access-session" on an endpoint, and then miraculously the session gets Auth'd correctly.

- What do all the non-profiling endpoints have in common? Filter in Context Visibility and narrow down the issue to a switch

- Run a config diff between a switch that has working profiling and one with problem endpoints - sometimes we don't see the needle in the haystack without a side-by-side comparison

[rezaalikhani]

Thanks for your reply;

I will check the mentioned suggestions tomorrow and will update this threat accordingly...

But one question I have right now... All these missed profile endpoints are joined to the domain and the identified operating system is based on Active Directory probe configured. Does this fact changes anything?

Thanks

[rezaalikhani]

The problem was the lack of forwarding DHCP messages to ISE (as the NAD does not support Device Sensor)...

[Arne Bier]

I'm sticking with my DHCP theory. Without DHCP, you have no starting point for ISE. i.e. the "MSFT 5.0" comes from the client's DHCP discovery packet and tells ISE that this is a Microsoft-Workstation. And then the hostname also comes from DHCP. That is the index that ISE needs to perform an AD lookup (I might be wrong, but you can't lookup a domain joined PC in AD using a MAC address)