Security

Hey, Airheads -

First post, frequent lurker. Straight to it:

We're shifting all of our access switching to 802.1x via ClearPass, but in getting the testing completed, I've run into an issue with Endpoint Statuses. Currently, 802.1x requires AD credentials and for the Endpoint to be Known in the Endpoint Repository. Basically, it's the exact same as our (working) wireless environment. All should be well and good, however, there seems to be some kind of mixup with the End-Host Identitiy.

The Event Tracker shows the REJECT status, but also lists the Endpoint Status as Known. So, for all intents and purposes, I should be accepted. The only anomaly I can locate it that the End-Host Identifier lists the device's MAC as 98-5A-EB-XX-XX-XX, whereas on every working device (and every device stored in the Endpoint Repository) is displayed as 985aebxxxxxx.

I've already confirmed on the switch side that the MAC should be unformatted. I tried changing it to Colon to see if the Identifier would correspond, but no such luck. The only field in the Event Tracker that seems to correspond to that is the Calling Station ID, which I've tried to specify as unformatted on the switch as well, but still, no difference. 

Google's failed me on any solutions, and I'm probably getting a bit more into the weeds than I'm used to, so any help is appreciated. 

I included the Event Tracker export, but it is mildly redacted, for my own peace of mind. :)

Oh - I should also specify that if I remove the Status: Known parameter from Enforcement, everything it peachy keen. I'm also nearly certain it's not something silly like missing the Authorization source (I'm not).

Attachment(s)

Dashboard_Details.txt   2 KB 1 version

Dashboard_Details.txt   2 KB 1 version

The format of endhost identifier wouldn't affect authentication.

Please post a screenshot of your role map and enforcement policy.

I thought that seemed like a stretch. Anyway, here are the screenshots.

I couldn't get the top and bottom, but for the Role Mapping, the last rule is that if the Name exists, they're given the "Employee" role in Tips. For the Enforcement policy, the last rule is if the Tips Role NOT_EQUALS Employee and the Endpoint is unknown, the Deny profile is applied.

So if you look at the logs, Known is actually being matched. The reason it is failing is there is no match for a TIPS role.

Here is role result:

 Roles: Employee, VLAN-666, [User Authenticated]

None of those match your policy.

My apologies. I think my hasty editing may be to blame here. Attached is a more carefully edited log and some additional screenshots. 

The log shows the following roles: 

 Roles: Employee, VLAN-701-NOC, [User Authenticated]

The role "VLAN-701-NOC" matches the policy, which also uses a "NOT_EQUALS" rule against the "Employee" role. (I assume that the [User Authenticated] role is given automatically by CPPM, as it's not one specified in the mapping policy, or enforcement policy.)

Also, if the roles and policy didn't align, why would I be given an "ACCEPT" status once the EndpointsReposity Status condition is removed?

It's certainly possible I'm missing something completely obvious, but if it works without the Endpoints condition, the "VLAN-701-NOC" role is functioning correctly. But if introducing the Endpoints condition causes authentication to fail, but it is in fact matching as "Known" and passing the condition... I'm not sure what to think. These roles and policy are more-or-less cloned from our current production wireless environment, which works very and rarely has role assignment issues.

Apologies if this is overkill - I'm just trying to be thorough.

Attachment(s)

Dashboard_Details.txt   2 KB 1 version