Advice on policy rules for usernames with and without domain

[jacksonben]

Hello all, could I get some advice on the ISE policy rules that you use to distinguish your users who may omit their domain suffixes when connecting to wireless (PEAP/MSCHAPv2)?

We have some rules in place already, which I will detail below, but some users are not hitting the rules when we think they should, but they are hitting the rule below it which we think they shouldn't. We are therefore very confused and want to make sure our policy rules make sense before raising a support call about it.

So firstly we have a rule to match users who do use their full username with domain, which looks like:

Radius-Called-Station-ID   CONTAINS   ourwifissid

Radius-NAS-Port-Type EQUALS Wireless - IEEE 802.11

Radius-Service-Type EQUALS framed

Radius-User-Name ENDS_WITH @ourdomain.com

This is followed by a rule to catch anyone who omits the @ourdomain.com suffix.

Radius-Called-Station-ID   CONTAINS   ourwifissid

Radius-NAS-Port-Type EQUALS Wireless - IEEE 802.11

Radius-Service-Type EQUALS framed

Radius-User-Name NOT_CONTAINS @

This works for the vast majority of users, however we have seen users who enter their username as bob@ourdomain.com not match the 1st rule, but does match the 2nd rule despite it containing an @ symbol. 

We have confirmed that the usernames are correct, the @ symbol is definitely an @ and there are no strange characters or spaces in the usernames. By all rights they should be caught by the top rule but they are not.

I'm assuming this is an ISE bug, but would appreciate anyone who could confirm how they solve this particular issue and maybe we can devise new rules based on your solutions.

We are running ISE 3.2 Patch 7.

Many thanks

[Arne Bier]

Hi @jacksonben 

It should not matter whether the user enters "bob" or "bob@domain" - and neither should your ISE Authorization Policies. Let me show you how I did it. I created a Policy Set called Wireless 802.1X. Notice the top-most 'AND" condition that matches on Wireless 802.1X and SSID equals example.  With ISE you don't need to (and shouldn't really) refer to the Called-Station-ID and Framed Type etc. - yes, of course those are the RADIUS attributes used, but the config below is provided for you by ISE, and it's also vendor neutral. ISE knows which attributes to look into.

The authentication supported in my setup is EAP-TLS (certificates) and EAP-PEAP (MSCHAPv2) - the users are looked up in an on-prem AD server.

Then the Authorization is simply this - no need to match usernames - ISE will lookup either format.

The only time you want to interfere with the username lookup stuff, is when you want to reformat the username, if (for some reason) you need to strip leading or training characters. Then you go to Administration / Identity Management / External Identity Sources/  YOURAD_JOINPOINT / Advanced Settings , and then under Identity Rewrite, you can mess around with these things.

My Live Logs shows without and with AD domain suffix entered by the user. Both work.

[jacksonben]

Thank you for taking the time to reply. It looks like there is some scope for improving our ruleset there.

As an educational organisation we also have a requirement to authenticate visitors from other educational organisations as well, so we do need to have something to distinguish logons from other domains and use external radius servers to authenticate them. 

So we needed something to match our domain, match something without a domain (NOT "@") and then match everything else. We have found that the rule matching our domain was sometimes not hit by an authentication, and it fell through to the rule matching NOT "@", despite the username actually having "@ourdomain.com" in there. So either there is something wrong with our rules or there is a bug in ISE.

Given the requirement above, would you distinguish our and not our domains at the policy set level or within the authorization policy rules?

[Arne Bier]

I feel I might have oversimplified it, but in the case of just one AD Join, you can take what I said as read. Your situation is more complex.

When there are multiple domains involved, you must match on domains during authentication (e.g. to ascertain which AD Joins to use for the lookups, or in the case of certificates, where to look in the certificate to retrieve the identity).   

I don't have multiple AD Domains, but the principle would be similar to what I tested below:

And to my surprise, in ISE 3.4p1, I get the same result as you - ISE doesn't seem to match on the MSCHAP with domain Rule ... it skips that one and always lands on the MSCHAP without domain.  But I can clearly see the @rnlab.local domain in the RADIUS Username. 

During Authentication you don't yet have access to AD attributes etc. - all you can use are the RADIUS Attributes like User-Name.

I tried every operator (ENDSWITH, CONTAINS, MATCHES) and none of them seem to match anything (username or domain) in the User-Name - with or without the '@' symbol.  I can't see what is wrong with the Authentication Policy. Have you raised a Cisco TAC case to request some assistance with this?  I have a feeling this used to work.

[jacksonben]

I'm somewhat reassured that you are seeing the same problem! 

I have not yet raised a TAC case, I made this community forum post first to make sure I was not doing something stupid in my rules. But now it looks like it is a real issue.

Further testing in the office this morning has shown that my phone (Pixel 8 on GrapheneOS) never gets the "@" matched, whereas my colleague with an iphone always gets matched.

I suspect Google phones may possibly be sending the string in a different format. 

[jacksonben · Accepted solution]

Ok we have figured it out, the rule is matching whatever is configured in the "anonymous identity" field of the wifi setup (at least on Android).

If left at the default "anonymous" it will not be matched by a rule looking for "@". I imagine ISE is only looking at the outer method details during this stage of the PEAP authentication process.

When we change the anonymous field to "@ourdomain.com" for example, it is then matched correctly by the rule.

[Arne Bier]

Oh yes - good catch.  I don't know if (or where) you can set that in Windows, iOS and other supplicants. I was using wpa_supplicant to produce my lab tests (It's an 802.11 software stack for Linux that can generate RADIUS traffic to mimic a Wi-Fi client).