Windows – sAMAccountName used for logged on users

active-directorywindowswindows-server-2008

When RDP'd to a server I'll often find that there are no available sessions as there are users currently logged in. Within our environment we utilise a user privilege management solution which creates managed domain accounts. For one reason or another the solution will populate the sAMAccountName (pre-Windows 2000 logon name) with a random value similar to the following: $1LB100-465HL3IJKL4

It is the sAMAccountName which is displayed when showing the current logged in users instead of the readable User Logon Name.

Is there a way to force Windows to display the UPN instead of the sAMAccountName because as things stand we are unable to tell who is actually logged in and this causes problems when deciding which session to end.

Below is a screenshot that explains my point:
enter image description here

With the sAMAccountName being displayed instead of the UPN users are unable to easily identify who is logged in and thus who's session can/should be disconnected. Is there a way for Windows to instead display the UPN of the logged in user instead of the sAMAccountName?

Thanks in advance.

Best Answer

OK, it's pretty seriously hacky to mess with sAMAccountName it's defined in the Windows spec:

http://msdn.microsoft.com/en-us/library/ms679635%28v=vs.85%29.aspx

http://msdn.microsoft.com/en-us/library/ms677605(v=vs.85).aspx

It exists for compatibility reasons, and I can't honestly think of a good reason to trample it - you can modify your LDAP schema and add custom attributes and fields. But if you've changed something that's by definition supposed to be something else, then all sorts of things are just going to break in various ways.

You wouldn't want to use UPN, because that's defined by the Kerberos spec, and can actually be quite long - and thus not much use for an on screen display.

What you really want is a unique, per account value, that's short. Which is what sAMAccountName is defined as. If you can't get your security management software to use something else, I'd be suggesting that you SERIOUSLY consider throwing it out and getting one that doesn't suck*.

* I appreciate this is straying into the realm of 'opinion', but I would justify it by point out that as a professional sysadmin - this is exactly the sort of thing that makes systems unreliable, unpredictable and unstable, and that you should Just Never Do.

Related Topic