NAC ldap integation - userPricipalName

[Christoph]

We would like to integrate NAC in a Wireless network and want to authenticate users against an Active Directory. The customers users know only their "userPricipalName" (UPN).

If we use the "userPricipalName" as "User Search Attribute" in the LDAP configuration from NAC (version 5.0), we don't get a RADIUS accept. We assume that the NAC is cutting the @ from the UPN. If this is the case there cannot come off a match with the UPN.
Can somebody confirm this behaviour?

And if this is the case, is there a workaround available?

Kind regrads
Christoph

[Brian_Anderson3]

Is there a reason to have those two fields different?

Somebody with knowledge of the inner workings of NAC would have to weigh in to see if that User Search field is really customizable.

A possible work around, would be to do Radius Proxy. Would be good to test and might give you a temporary solution, if the User Search field ends up being a feature request.

Regards,

Brian

[Tamera_Rousseau]

Hi Brian, I have sent this into our NAC group so we should have some enlightenment shortly!

[Christoph]

Hello Brian,

thanks for your answer.
In our case UPN and sAMAccountName have nothing in common, e.g.:
samAccountName = ABC123
UPN = [email protected]
If we follow your suggestion the NAC will check "max" against the samAccountName. This will not result in a match.

And yes we have configured a pattern *@example.de to redirect the user authentication against the LDAP server.

Kind regrads
Christoph

[Brian_Anderson3]

You should be able to leave the User Search Attribute at samAccountName and still be able to use the UPN for authentication (just tested it). Do you have user to auth mapping set to catch the@UPN pattern? Pattern should be at least *@domain.name where domain.name is what is after the @ sign when you login.