Change UserPrincipalName with Script via Powershell

When setting up single sign on in Office 365, one problem you may run into is needing to change the UserPrincipalName to match your public mail domain. For example, if your primary Active Directory Domain is something like @domain.local it will not work with Office 365 and you will need to change the UserPrincipalName to @domain.com.

After you have created the alternate UPN as described in http://techatmount.blogspot.com/2012/09/office-365-single-sign-on-errors.html, you can script the change the of UPN of users to a different UPN using the following powershell script.

I played around with the formatting of the code below to get it nicely color coded. This means that some of the line breaks don't show well here, but a copy and a paste into notepad should format it properly.

Import-Module ActiveDirectory            
$privateUPN = 'domain.local'            
$publicUPN = 'domain.edu'            
Get-ADUser -SearchBase "ou=Students,dc=domain,dc=com" -SearchScope SubTree -filter * |             
ForEach-Object {if ($_.UserPrincipalName){#Checks if the UserPrincipalName is null            
 $newUserName = $_.UserPrincipalName.Replace($privateUPN,$publicUPN) #Changes the UPN and sets the new name to a variable            
 <# The following is to output extra details for troubleshooting  : Note the line continuation is a back tick#>            
 #Write-Host $_.UserPrincipalName " now is " $newUserName -ForegroundColor DarkRed `            
 $_ | Set-ADUser -Server $privateUPN -UserPrincipalName $newUserName <#-WhatIf#>}#The whatif commands doesn't actaully change anything remove it to make the change.            
 else {Write-Host $_.sAMAccountName + " does not have a UPN" -ForegroundColor DarkCyan}            
 #{$newUserName = $_.UserPrincipalName.Replace($privateUPN,$publicUPN))}            
 }

GroupPrincipal.FindbyIndentity Search returns Well Known SID Error

We use a custom program to assist in the creation and management of our Active Directory User Accounts. In this we use the DirectoryServices.AccountManagement namespace released in .net 3.5 to do much of the interaction with AD.

One of the processes that gets completed is to find what groups a user should be in based on their department and add the user to that group.

In doing this, I use the following code to search for the group based on their name.

Dim domainContext As PrincipalContextdomainContext = New PrincipalContext(ContextType.Domain, "campus", "OU=" & Me.Department & ",OU=" & Me.accountType & ",DC=domain,DC=com")Dim group As GroupPrincipalgroup = GroupPrincipal.FindByIdentity(domainContext, Me.Department)

Problem

A problem arose while searching for some of our departments. For example our Communications department is identified as 'CO' and our Education department is identified as 'ED'. When we searched for the value 'CO' assigned to Me.Department, the identity found was the well known SID "Creator Owner." When we would search for 'ED', the group found was "Enterprise Domain Controllers" instead of the expected group 'ED'.

We would also receive the following error when trying to create the user account.

This principal object represents a well-known SID and does not correspond to an actual store object. This operation is not supported on it.

Solution

The solution to the problem was actually pretty quick.
Change

group = GroupPrincipal.FindByIdentity(domainContext, Me.Department)

to

group = GroupPrincipal.FindByIdentity(domainContext, IdentityType.SamAccountName, Me.Department)

so you are only searching against the sAMAccountName or you can choose a different IdentityType to search against. The options include

• DistinguishedName
• Guid
• sAMAccountName
• Name
• Sid
• UserPrincipalName

Additionally trying to catch the MultipleMatchesException did not resolve the problem because it was never thrown during the search process.

Hopefully this will help save some searching.

Spear Phishing Attempts

We have recently been receiving several different types of spear phishing attempts. These messages contain customized institutional headers and information of interest specific to the users they were sent to. For example, fake recruiting information was sent to admissions and vice presidents.

We have notified users of the phishing emails and tried to sink hole the DNS addresses.