Monday, November 22, 2021

User Profile Ramifications when Renaming Users on Azure AD-Joined Computers

I'm starting to work more with devices that are Azure AD-joined rather than domain-joined. One of my key questions was what happens to user profiles when an Azure AD user sign-in name (UPN) is changed. I was pleasantly surprised by how well it worked.

For my testing, I created an Azure AD user and signed in to create a profile. During sign-in, I created a PIN for authentication. While signed in, I also configured an Outlook profile and OneDrive. Then I tried changing the domain portion of the username and the userid portion of the username. The results were the same:

  • I could still sign in with the PIN.
  • I could sign in as the same user (username displayed on sign-in screen) with the password.
  • I could sign in with the new username (typed in) and password.

After signing in:

  • The workplace account was updated to the new username.
  • Outlook was still able to sign-in without user intervention and updated the account.
  • OneDrive continued to function without user intervention and updated the account.
  • The same Windows 10 user profile was retained.

 

Wednesday, November 17, 2021

Managing Microsoft 365 Licenses by using Microsoft Graph

Microsoft has announced that after June 2022, the MSOL and AzureAD cmdlets for managing user licenses in Microsoft 365 will cease working. These cmdlets rely on management functionality that is being retired. To manage licenses programmatically, you need to start using Microsoft Graph.

Here is the announcement:

Microsoft Graph is a web-API that you can use to manage Microsoft 365 users, groups, and services. If you're a programmer, then perhaps the idea of building a web request to perform administrative tasks sounds like a good idea. However, for an admin guy like me that typically uses PowerShell cmdlets for management tasks, building web requests is a bit painful. Fortunately, the Microsoft Graph PowerShell SDK has been released that provides PowerShell cmdlets to access Microsoft Graph features.

To get more information about the Microsoft Graph PowerShell SDK:

 Connecting with Microsoft Graph

Just like you use Connect-AzureAD or Connect-MsolService, for Microsoft Graph, you use Connect-MgGraph. When you connect, you need to specify a scope that defines your permissions. So, unlike previous versions, the connection does not automatically gain the full permissions based on your roles like Global Admin. I haven't experimented with exactly which scopes are required to manage user licenses. However, I can confirm that the following example does work.

Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.ReadWrite.All"

To get more information about Microsoft Graph scopes:

License Structure and Naming

If you've been managing licenses through the web interface in Microsoft 365 or the MSOL cmdlets, you're used to seeing license names such as Office 365 E3. When you manage licenses by using Microsoft Graph, you need to know the SkuId property of the licenses available in your tenant. You can obtain the SkuId for a license by using Get-MgSubscribedSku as shown in the following figure. The SkuPartNumber property is a more user friendly name that you can recognize.

Within each licenses type, there are also service plans. These correlate with apps provided by a license such as Exchange Online (Plan 2). To enable or disable the service plans, you need to use the ServicePlanId for a  service plan. If you place your subscribed SKUs in a variable, you can view the service plans included in the SKU as shown in the following figure.

To get a list of generally available SKUs and their service plans:

Viewing Assigned Licenses

You can view the licenses assigned to a user by using the Get-MgUserLicenseDetail cmdlet as shown in the following example:

Get-MgUserLicenseDetail -UserId user@domain.com

The results of this command return the users license assigned to the user. An array of licenses is returned if multiple licenses have been assigned. Within each license returned, you can view the ServicePlans property to see if any service plans have been disabled for a user.

You can also query assigned license information by using Get-MgUser. The licensing information isn't returned by default and you need to specify that the AssignedLicenses property will be retrieved as shown in the figure below. Notice that these results list the service plans that are disabled for a license.

Querying Users with Assigned Licenses

If you want to query all of the users with a specific license, you can do this by using Get-MgUser with a filter for a specific SkuId. The example below shows the syntax.

Get-MgUser -Filter "assignedLicenses/any(x:x/skuId eq 78e66a63-337a-4a9a-8959-41c6654dfb56)" -Property AssignedLicenses,UserPrincipalName,Id

When you are filtering based on AssignedLicenses there are some limitations on the results returned. By default, only 100 results are returned. If you use the PageSize parameter, you can specify up to 999 results are returned as shown below.

Get-MgUser -Filter "assignedLicenses/any(x:x/skuId eq 78e66a63-337a-4a9a-8959-41c6654dfb56)" -PageSize 999

If you have a larger tenant, and you try to use the All parameter to return results larger than these limits, you will be the following error Get-MgUser : The specified page token value has expired and can no longer be included in your request.To avoid this error, you need to query a list of all users and then filter by using Where-Object as shown below.

$allusers = Get-MgUser -All -Property AssignedLicenses,UserPrincipalName,Id,DisplayName
$A1plusUsers = $allusers | Where-Object {$_.AssignedLicenses.SkuId -contains "78e66a63-337a-4a9a-8959-41c6654dfb56"}

Modifying Assigned Licenses

To add or remove licenses for a user, you use the Set-MgUserLicense cmdlet. When you run the cmdlet, you need to provide the following parameters:

  • UserId. The user being modified. You can specify the user by the object Id or UserPrincipalName.
  • AddLicenses. A hash table that specifies the SkuId of a license being added and the ServicePlanId of any service plans that are being disabled.
  • RemoveLicenses. A string that identifies the SkuId of a license being removed.

The following code shows how to build a hash table for the AddLicenses parameter. This specifies a license SkuId and a service plan that's disabled in the license.

$A1FacultySku = @{
    SkuID = "94763226-9b3c-4e75-a931-5c89701abe66"
    DisabledPlans = "9aaf7827-d63c-4b61-89c3-182f06f82e5c"
}

The following code lists a SkuID that will be disabled.

$A1PlusFacultySku = "78e66a63-337a-4a9a-8959-41c6654dfb56"

The command that modifies the user license is below. Note that the UserId parameter will accept a UPN also.

Set-MgUserLicense -UserId $User.Id -AddLicenses $A1FacultySku -RemoveLicenses $A1PlusFacultySku

The RemoveLicenses and AddLicenses parameters are mandatory. If you don't provide an empty array, you'll get an error such as Set-MgUserLicense : One or more parameters of the function import 'assignLicense' are missing from the request payload. The missing parameters are: removeLicenses. If you don't want to remove any licenses, you need to provide an empty array for RemoveLicenses as shown below. If you are only removing licenses, you need to provide an empty array for the AddLicenses parameter.

Set-MgUserLicense -UserId $User.id -AddLicenses $A1FacultySku -RemoveLicenses @()

If you want to modify the disabled plans for a licenses, you build a new hash table with the license and all of the plans you want disabled. Then you apply the new hash table with the AddLicenses parameter. The new license assignment overwrites the existing license assignment.

If you want to add multiple licenses, you can provide a comma separated list of hash tables. I have not explicitly tested, but I think providing an array with the hash tables would also work.

If you want to remove multiple licenses, create an array with the SkuIDs that you want to remove.




Thursday, October 28, 2021

AADSTS90072 User Does not Exist in Tenant

During a recent migration project from one tenant to another, a test user was unable to sign in. The sign-in page in Office 365 redirected to AD FS on-premises for authentication. The user credentials worked in AD FS and the web browser was redirected back to Office 365. Then this error was displayed: 

Sign in

Sorry, but we’re having trouble signing you in.

AADSTS90072: User account 'Bob.Smith@domain.com' from identity
provider'urn:sso.domain.com:domain.com' does not exist in
tenant 'Byron Co' and cannot access the application '4765445b-
32c6-49b0-83e6-1d93765276ca'(OfficeHome) in that tenant. The
account needs to be added as an external user in the tenant
first. Sign out and sign in again with a different Azure
Active Directory user account.

This error indicates that the user authenticated by AD FS does not exist in Azure AD. Based on the UPN, Bob.Smith@domain.com existed both in on-premises AD and Azure AD. So, there is some other property being used to match the two objects after AD FS authentication.

To understand where this broke down, you need to understand how objects in AD are linked with objects in Azure AD. There is an ImmutableID property on Azure AD users that links Azure AD users to on-premises AD users. Early implementations of Azure AD Connect (or Dirsync) copied the object GUID from on-premises AD and used that value for the ImmutableID. This worked well until you migrated user objects to new AD domain or AD forest where they'd have a different GUID.

New implementations of Azure AD Connect use ms-ds-ConsistencyGUID in the on-premises user object instead of GUID. This value can be copied between domains to preserve synchronization during object migrations. By default ms-ds-ConsistencyGUID is populated with the same value as the object GUID the first time the object is synced.

AD FS authentication uses the object GUID or ms-ds-ConsistencyGUID during authentication. This value must match the ImmutableID in AzureAD to allow authentication to complete. The older instructions for configuring AD FS authentication manually had you configure a rule for object GUID. If you use Azure AD Connect to configure AD FS then it creates rules that use ms-ds-ConsistencyGUID if populated or object GUID. This article talks about the rule configuration: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-management#modclaims.

If you update your deployment of Azure AD Connect to use ms-ds-ConsistencyGUID as the source anchor and forget to update AD FS to allow ms-ds-ConsistencyGUID in the authentication process, AD FS authentication will continue to work because object GUID and ms-ds-ConsistencyGIUD are the same value by default. However when you start migrating objects and retain the ms-ds-ConsistencyGUID (which will now be different from the object GUID) authentication starts to fail because the token passed back to Office 365 for authentication contains the object GUID which doesn't match the immutable ID/ms-ds-ConsistencyGUID. Thus the error message above.

In our case, the AD migration tool we were using copied the ms-ds-ConsistencyGUID from a source AD domain to target AD domain which caused our authentication issue. Because users were getting new mailboxes in this migration, we didn't need to maintain ms-ds-ConsistencyGUID. Our short term fix was to copy the object GUID value and place that in ms-ds-ConsistencyGUID and immutableID. However, the correct long term solution is to update AD FS to correctly use ms-ds-ConsistencyGUID during authentication.

This article has some examples you can use to convert object GUID to ms-ds-ConsistencyGUID and ImmutableID: http://byronwright.blogspot.com/2020/10/convert-immutableid-to-hex.html.





Wednesday, October 20, 2021

Query the Signed in User When Running Script as System

I'm working on a desktop migration project where we run some PowerShell scripts to prepare the computer for migration. As part of this we need the locally signed in user.

Normally, you can obtain locally signed in user from an environment variable:

$env:USERNAME

However, we're running the script as SYSTEM. So, that returned value is incorrect. That value is the username associated with the PowerShell instance.

You can query the signed in user when you run a script as SYSTEM by using Get-WmiObject:

(Get-WmiObject -ClassName Win32_ComputerSystem).Username


Sunday, September 5, 2021

Set User Department Based on OU

When you create dynamic distribution groups on-premises, you have the option to create them based on organizational unit. In Exchange Online (EXO), you don't have this option because Azure AD doesn't have the OUs for your tenant.

There are many attributes available for creating dynamic distribution groups in EXO and one available through the web interface is department. So, to simulate OU-based groups, we can set the department attribute.

To do this, I created a script on a DC that runs once per hour and sets the Department attribute based on the OU. When you run a script as SYSTEM on a DC, it has the ability to modify Active Directory. The function below is the core of the script.

#Function requires the OU as a distinguished name
Function Set-UserDepartment {
    param(
        [parameter(Mandatory=$true)] $OU,
        [parameter(Mandatory=$true)] $Department
    )

    Write-Host ""
    Write-Host "Setting department attribute as $Department for users in $OU"
    
    #Find null values
    $nullusers = Get-ADUser -Filter {Department -notlike "*"} -Properties Department -SearchBase $OU
    
    #Find wrong value
    $wrongvalue = Get-ADUser -Filter {Department -ne $Department} -Properties Department -SearchBase $OU

    #Create one array of all users to fix
    $users = $nullusers + $wrongvalue

    Write-Host "null value: " $nullusers.count
    Write-Host "wrong value: " $wrongvalue.count

    #Set department
    Foreach ($u in $users) {
        Set-ADUser $u.DistinguishedName -Department $Department # -WhatIf
    }
} 

This function:

  • Expects the OU to be passed as a distinguished name
  • Finds users in the OU (and sub-OUs) with the department set to $null
  • Finds users in the OU (and sub-OUs) with the incorrect department
  • Sets the Department value as specified when you call the function for all users identified

Querying the users that don't have department set correctly and calling Set-ADUser for only those users is much faster than setting all users each time.

The count for null value or wrong value is incorrect when there is a single item because a single item is not an array. You can improve this by forcing them to be an array before populating them. Or, checking whether it's single item first, but for my purposes, this was sufficient.

Within the script, you can call the function as many times as required to set the attributes. You just pass the OU and the department value to the function like below.

#Call function to set department for Marketing
Set-UserDepartment -OU "OU=Marketing,DC=Contoso,dc=com" -Department Marketing


Tuesday, August 10, 2021

Script to Update DNS Record Permissions

 When you have secure dynamic update configured for DNS zones, the individual DNS records are protected by security permissions. The host records are typically secured by the associated computer account. The PTR records are typically secured by the DHCP server account or the associated computer account depending on whether it's a static or dynamic IP address.

If you have highly available DHCP servers, they should be configured with a user account for dynamic DNS updates. This user account is used by both DHCP servers to ensure that records created by one DHCP server can be updated by the other.

If you have highly available DHCP and don't use a shared account, then you'll see errors in the DHCP event log (Event ID 20322) indicating that the DNS record couldn't be updated. After you configure the shared account, the permissions on the DNS records will still be incorrect. The following script adds Full Control permissions on A and PTR records for the shared account. This allows the properly configured DHCP servers to update existing records.

You'll need to do some editing on this script for your environment:

  • $DynamicDnsUser needs to be set to your shared user account.
  • $Server needs to be set to the name of your DNS server.
  • $zones needs to contain the zones you want to modify. 

#DynamicDnsUser is the user configured on both DHCP servers for dynamic DNS
#This uses the SamAccountName of the user
$DynamicDnsUser = Get-ADUser ddnsuser

#Query the SID for this user and create a ACE allowing full control
$SID = New-Object System.Security.Principal.SecurityIdentifier $DynamicDnsUser.SID.Value
$ACE = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $SID, "GenericAll", "Allow"

#When running DNS cmdlets from a workstation
#you need to specify the server you are acting on
$server = "DNSServer"

#query a list of all zones to loop through and set permissions
#$zones = Get-DnsServerZone -ComputerName $server
#$zones = $zones | where ZoneType -eq Primary

$zones = Get-DnsServerZone "40.10.in-addr.arpa"

Foreach ($zone in $zones) {

    #Query all records in the zone
    #Record type ensures that the get the correct type of records
    #based on forward or reverse lookup zones
    If ($zone.IsReverseLookupZone -eq $true) {
        $recordType = "PTR"
    } Else {
        $recordType = "A"
    }

    $records = Get-DnsServerResourceRecord -ComputerName $server -ZoneName $zone.ZoneName -RRType $recordType

    #Loop through all records in the zone and add
    #the ACE for the dynamic DNS user
    #Need to set the location to AD: for the *-ACL cmdlets to work
    Foreach ($record in $records) {

        Push-Location -Path AD:
        $ACL = Get-Acl -Path $record.DistinguishedName
        $ACL.AddAccessRule($ACE)    
        $ACL | Set-Acl -Path $record.DistinguishedName    
        Pop-Location

    } #end foreach records

} #end foreach zones

Please be aware this only works to allow the DHCP server to update the DNS records. In most organizations, the host records are dynamically updated by the individual computers. If you want to add the correct computer account to a DNS record, then you need to approach this differently.

The following link has a script that finds a computer account that matches a host record and assigns permissions to that computer account. This script was used as a starting point for my script above.

Wednesday, July 21, 2021

Dynamic DNS Settings for Highly Available DHCP Servers

Windows DHCP servers can integrate with DNS to perform dynamic DNS on behalf of clients. This is useful when DHCP clients such as printers or mobile phones are not able to perform their own dynamic DNS updates. The DHCP server can also perform secure dynamic DNS updates when the client can't.

You can configure dynamic DNS settings at the IPv4 node (server level) or at the individual scope. If you don't configure dynamic DNS settings at the scope level, they are inherited from the server level. If you update dynamic DNS settings at the server level those new settings are used by all scopes that don't have dynamic DNS settings explicitly defined.

Unfortunately, there is no easy way to identify when dynamic DNS settings are configured at the scope level instead of the server level. If the settings are different then they are definitely configured at the scope level. But, if the settings are the same, they could be configured at either level.

When you have scopes configured for high availability with two Windows DHCP servers, then both servers can service the scope. If you have accidentally configure the dynamic DNS settings at the IPv4 node differently on the two servers, it can provide inconsistent settings for clients depending on which DHCP server provides the lease.

For example, DHCP1 and DHCP2 are configured with a failover relationship that is in load balancing mode. Scopes using this failover relationship service half of requests using DHCP1 and half of requests using DHCP1.

At the IPv4 node of DHCP1, it is configured to perform dynamic DNS updates on when requested by the clients.


At the IPv4 node of DHCP2, it is configured to perform dynamic updates for all clients.


If you create a new scope, named Client LAN and configure it to use the failover relationship, the scope appears on both servers. When you view the DNS tab in the properties of Client LAN, the settings match the server settings. So, the settings you see vary depending on which DHCP server that the DHCP admin console is connected to.

When a client leases an address from DHCP1, the dynamic DNS settings from the IPv4 node of DHCP1 are used. When a client leases an address from DHCP2, the dynamic DNS settings from the IPv4 node of DHCP2 are used.

To avoid this, you can do the following:

  • Ensure that the IPv4 settings are the same on both servers (you really should)
  • Manually configure the dynamic DNS settings in each scope

Secure Dynamic Update Credentails

Another consideration when using highly available DHCP with dynamic DNS updates is the credentials for secure updates in DNS. By default, when a DHCP server creates a DNS record that allows only secure dynamic updates, the record is secured with permissions based on the computer account of the DHCP server. When two DHCP servers are working together, this can result in DHCP1 creating a DNS record that DHCP2 can't update.

To ensure that both highly available DHCP servers can service all records created by either server, you need to configure a user account that is used by both servers to secure dynamic DNS records. This is configured on each server on the Advanced tab in the properties of IPv4.

 
After configuring the DNS dynamic update credentials on both servers, the DNS records are secured by that user account. Since both servers use the same user account, they can update DNS records created by the other DHCP server. This user account does not require any special permissions. It just needs to be a member of Domain Users. And of course, you should set the password to not expire.
 
If the DNS zones are configured to allow insecure dynamic updates then security is ignored during  dynamic DNS updates and the credentials are not important.