Authenticate users via RADIUS using userPrincipalName instead of sAMAccountName?

  • 2
  • Question
  • Updated 5 years ago
  • Doesn't Need an Answer
OK, so I've got RADIUS running on my Aerohive APs, with APs acting as authentication/accounting servers and pointing to Active Directory as my user directory. The trouble is, some of my users have names longer than 20 characters (students with long first and last names and student IDs) which are truncated to 20 characters when stored in the sAMAccountName LDAP attribute ("pre Windows 2000 format" otherwise recognised as the domain\user format.)

When using the userPrincipalName LDAP attribute I have the full usernames, and students log in to other services with their full, untruncated username + "@domain.name". Unfortunately, while I can authenticate with RADIUS using the truncated sAMAccountName, I cannot authenticate using userPrincipalName (user@domain.name). I poked around the settings for a little while, but I didn't see anywhere I could change the LDAP attribute being used for username lookup.

Is this possible, or am I out of luck?
Photo of Greg Moore

Greg Moore

  • 16 Posts
  • 1 Reply Like

Posted 5 years ago

  • 2
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
If you use NPS as your RADIUS server, you will not have this issue. Have you considered going down this route?

Certainly, if HiveOS's built in RADIUS server does not support UPNs, it should be enhanced to support this. I would go so far as to classify this as a bug if it is the case considering how common the format is.

(As a side issue, one issue that I have noticed is that some accounts can have a sAMAccountName but the userPrincipalName will be missing. You should audit your directory to ensure that all accounts have a UPN.)
Photo of Greg Moore

Greg Moore

  • 16 Posts
  • 1 Reply Like
Switching to NPS had crossed my mind, though I'll admit I was hoping for a quick fix.

I know that my students have their UPNs populated, because they were just updated by script, though I will check up on staff accounts. Good catch.
Photo of Sam

Sam

  • 120 Posts
  • 31 Reply Likes
I agree with Nick. :)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I ought to add that there is a User-Name truncation to 31 characters issue that is due to be fixed in 6.1r2, due to be available in September some time.

You will likely hit this limit with your large user names when they are qualified with a domain/realm in a UPN and it may impact you in some way depending on how you choose to deploy things.

You will likely want to update when it is available.
Photo of Greg Moore

Greg Moore

  • 16 Posts
  • 1 Reply Like
Hm. Is the truncation bug only present when running the Aerohive RADIUS server, or would it occur while using NPS as well?
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I am not aware of the specifics of how the bug interacts with the built-in RADIUS server, sorry.

Certainly with an external RADIUS server, such as NPS, it occurs on the EAPOL outer-identity when passed in the User-Name AVPs of Access-Request and Accounting-Request packets and not the EAP inner-identity, which makes sense if you think about it as the EAP payload is opaque to the authenticator/NAS.

It usually just messes with accounting and any associated/layered functionality therefore and not authorization. Things break more spectacularly when some logic is expecting to do something based on the value of the User-Name AVP.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Conceptually, HiveOS should be able to automatically know to query either the sAMAccountName or the userPrincipalName from the directory based on the format of the user name provided, no special configuration should be required.
Photo of Greg Moore

Greg Moore

  • 16 Posts
  • 1 Reply Like
It may actually be doing so, and I'm simply hitting the 31 character bug when using UPN. I can authenticate using UPN format for short usernames, though I assumed it was still referencing sAMAccountName since usernames over 20 characters in length were failing.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Yes, that could well be the case if truncation occurs before the LDAP query. You could get a trace and analyze it with Wireshark to confirm what's going on.
Photo of Greg Moore

Greg Moore

  • 16 Posts
  • 1 Reply Like
I'll do that. If it's just the bug that's due to be fixed in r2 then I'll keep my current username format and hold off on implementing RADIUS until r2 is released.

Both RADIUS and the longer username format are new to students this school year, and we have yet to hand out student login cards. I have some flexibility in which one I adjust, but only for a few more days. I'd prefer to keep the longer format as it makes RADIUS usernames the same as their email login, and the fewer unique usernames they have to remember, the better.

If push comes to shove I'll just change the username format to the student ID alone, which should keep it under 20/31 characters for all users.
Photo of Greg Moore

Greg Moore

  • 16 Posts
  • 1 Reply Like
It looks like I may be getting bitten by both the 30 character limit bug AND an issue with using UPN.

I tested a username that was 19 characters long (sAMAccountName and UPN are identical) but adding the FQDN pushed it over 30 characters. It failed repeatedly when trying to log in when using username+@fqdn. It succeeded immediately when using just the 19 character username.

If I do an LDAP lookup test from Tools > AD/LDAP Test and I supply a username longer than 20 characters (but under 30) I get "Search user (username) under baseDN (baseDN) failed: no such user." If I truncate that same username to 20 characters (the sAMAccountName) the lookup succeeds.

I've also more thoroughly tested using short (< 20 character username, < 30 with the FQDN added) usernames + @fqdn for authentication, and, oddly enough, they fail most of the time, but every fifth or sixth try it succeeds, even when just spamming the same username and password over and over again (???)

I think I may switch the username format to just the student ID. It seems like the safest move.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Greg,

Have you considered opening a support case on the issue?

Nick
Photo of Shane Walters

Shane Walters

  • 23 Posts
  • 2 Reply Likes
I don't want to hijack a thread but I am having similar issues. My issue is with domain based computers. If a computer is joined to the domain and I am using an Aerohive AP as the RADIUS server the computer gets denied. In the client monitor you see that it is denying the username of DOMAIN\USERNAME. This does not happen on non-domain devices because it prompts you for a username and password when trying to connect to the WPA Ent SSID. When that occurs the user just puts in USERNAME and not DOMAIN\USERNAME and it works. It seems that the Aerohive RADIUS server does not like the DOMAIN\ format. This is also confirmed by using a Windows 8 device that IS on the domain. When you try to connect to the WPA Ent SSID it will ask you if you want to use your Windows credentials. If you say yes to use them you will get denied for the same reason mentioned above. If you say to not use those credentials it will then prompt you for a username and password where you have the ability to put USERNAME and not DOMAIN\USERNAME. This allows the computer on the SSID. In pre-Win8 you do not have the option to tell it to no pass through the Windows credentials. Either way this seems like a bug in the RADIUS software that Aerohive is using. One would think that it would accept DOMAIN\USERNAME. It is either a bug or I am missing a setting somewhere. I have not really found an answer to this issue though and hoped this thread would help. This is not an issue if you setup NPS on a Windows Server but the ease of using an Aerohive AP as a RADIUS server would justify figuring out this issue. Oh and if I utilize the AD/LDAP Test I cannot get it to fail...even if I use DOMAIN\USERNAME and leave the "Domain" field blank.