Weird issue

  • 295 Views
  • Last Post 15 June 2016
jeremy.stump posted this 14 June 2016

In our Active Directory we have noticed on the account tab within ADUC for a lot of users the User Logon Name (pre-Windows 2000) is correct but the User Logon Name is blank and so is the domain name drop down box to the right of that. I know that attribute is UserPrincipalName and am wondering if there is an easy Powershell script I can run to fix all of these users. Thank you   Jeremy Stump | System Admin III | Information Technology | BMHCC - CORPORATE
Phone: (901) 227-8205 | Jeremy.Stump@xxxxxxxxxxxxxxxx
Opinions expressed above are not necessarily those of Baptist.

This message and any files transmitted with it may contain legally privileged, confidential, or proprietary information. If you are not the intended recipient of this message, you are not permitted to use, copy, or forward it, in whole or in part without the express consent of the sender. Please notify the sender of the error by reply email, disregard the foregoing messages, and delete it immediately.

P Please consider the environment before printing this email...

Order By: Standard | Newest | Votes
ZJORZ posted this 14 June 2016

What is the definition of “fixing all of these users”? Met vriendelijke groeten / Kind regards, Jorge de Almeida Pinto*: JorgeDeAlmeidaPinto@xxxxxxxxxxxxxxxx(: +31 (0)6 26.26.62.80 Description: Description: Description: Description: Think Green 

show

SamErde posted this 14 June 2016

If you're sure that there is no issue to uncover, then populating the user principal name is quite easy with PowerShell. You could loop through each user and use the samaccountname for the first half of the UPN and the DNS domain name for the 2nd half of the UPN.


show

jeremy.stump posted this 14 June 2016

Ensuring the User Logon Name and our domain name in the drop down box is populated with the pre windows 2000 logon name.   

show

jeremy.stump posted this 14 June 2016

Thus my email to see if someone already had the Powershell script written as I am not that advanced in it yet. Thank you  Jeremy Stump
(901) 227-8205

show

ZJORZ posted this 14 June 2016

And why would you do that? In other words what is your reason for population of the attribute? Because it is not there? Because you need it?If you are configuring this because it is not there, that will not gain you anything The userPrincipalName attribute is the explicit UPN, which is your case is empty Every user by default has an implicit UPN (not configurable), which ALWAYS matches <sAMAccountName>@<FQDN domain> Users can logon through:·         sAMAccountName·         implicit UPN·         explicit UPN (when it contains an explicit value) If you go ahead, make sure the UPN has an internet routable domain, otherwise it will bite you when you need to use Azure AD/Office 365 Met vriendelijke groeten / Kind regards, Jorge de Almeida Pinto*: JorgeDeAlmeidaPinto@xxxxxxxxxxxxxxxx(: +31 (0)6 26.26.62.80 Description: Description: Description: Description: Think Green 

show

gkirkpatrick posted this 14 June 2016

Jorge is right, there’s probably not a need to populate UPN, unless you have some application that needs it.

 

FWIW, users can also login using their DN, their objectGuid, and their objectSID. Not that any of them would want to…

J One of those weird little bits of AD trivia.

 

The PoSh would look something like this:

 

Get-ADObject -ldapfilter '(&((objectCategory=person)(!(userPrincipalName=))))' -properties sAMAccountname,objectGuid | Out-File users.txt

 

<edit the users.txt file here to remove any users you don’t want to modify, like krbtgt>

 

Get-Content users.txt | %{Set-ADObject –Identity $_.objectGuid -Add @{userPrincipalName="$_.saMaccountName@xxxxxxxxxxxxxxxx"}}

 

-g

 

show

a-ko posted this 14 June 2016

One of the ways that the UPN attribute is used is to allow users to log in with their “email address” rather than their standard AD UPN. This allows uniformity across environments and ease of use for users because they’ll already know their e-mail address. It does not need to have a relation to the samAccountName field. Example: Domain: ad.contoso.com Pre-Windows 2000 Login Name: AD\mcramerSamAccountName: mcramerName: Mike.CramerUserPrincipalName: mike.cramer@xxxxxxxxxxxxxxxxEmailAddress: mike.cramer@xxxxxxxxxxxxxxxx In the case of what others stated earlier (with an implicit UPN), I can ALSO always use mcramer@xxxxxxxxxxxxxxxx to login. And by default this is the UPN that ADUC creates in the userPrincipalName attribute. This is excessively useful when you deploy something like Skype for Business. Note: In the ADUC console the UPN is separated into 2 fields. In the directory it’s not. So if you script it, changing just the “userPrincipalName” attribute is all you do. -Mike Cramer  

show

jeremy.stump posted this 15 June 2016

I understand that, unfortunately we have a application that is keying off the UserPrincipalName attribute and when it is blank it inserts a NULL in the SQL database security table they are using for security within their application. Poorly coded IMO most coders use SamAccountName. Regardless I need to fix these to match.  Jeremy Stump
(901) 227-8205

show

jeremyts posted this 15 June 2016

Fair call.

 

I’m intrigued to know how these accounts were created without a UPN in the first place? Ie. What do you use to create accounts?

 

Cheers,

Jeremy

 

show

a-ko posted this 15 June 2016

It’s not blank, or shouldn’t be, by default?  

show

jeremy.stump posted this 15 June 2016

Correct by default they are not blank, were unsure how they were set blank. Gotta fix the issue first then audit new account creations to see who may be doing it incorrectly.  

show

jeremy.stump posted this 15 June 2016

I have been sent a script via a contact here and it worked great in my test domain. thanks Get-ADUser -Filter * -SearchBase ‘CN=users,DC=contoso,DC=com’ -Properties userPrincipalName | foreach { Set-ADUser $_ -UserPrincipalName "$($.samaccountname)@contoso.com"} Jeremy Stump
(901) 227-8205

show

DonH posted this 15 June 2016

UPN doesn’t need to be filled in, because it always has an implicit value.  See https://msdn.microsoft.com/en-us/library/windows/desktop/aa380525%28v=vs.85%29.aspx  Leaving the UPN blank normally works fine, and only causes problems when SQL programmers attempt to replicate AD logon semantics. 

show

Close