AADUser: Updating users and providing intial passwords at the same time.

[adrianvb]

Details of the scenario you tried and the problem that is occurring

My first use case for M365 DSC is to provision users for a small tenant. ApplicationID and certificate thumbprint are used to authenticate.

        AADUser Test
        {
            UserPrincipalName = "dsc.test@redacted"
            DisplayName = "DSC, Test Nutzer"

            ApplicationId         = $ApplicationId
            TenantId              = $TenantId
            CertificateThumbprint = $CertificateThumbprint
        }

After changing a property of the user and re-running the ressource i get (debug log further down)

VERBOSE: [DESKTOP]: [[AADUser]Test] Updating Office 365 User dsc.test@redacted Information
Insufficient privileges to complete the operation.
    + CategoryInfo          : InvalidOperation: ({ UserId = dsc....softGraphUser }:) [], CimException
    + FullyQualifiedErrorId : Authorization_RequestDenied,Microsoft.Graph.PowerShell.Cmdlets.UpdateMgUser_UpdateExpand
   ed
    + PSComputerName        : localhost

I checked the graph documentation and it seems applications cannot change passwords: https://learn.microsoft.com/en-us/graph/api/user-changepassword?view=graph-rest-1.0&tabs=http

But MSFT_AADUser.psm1 always tries to set the password (even if none is provided?).

My first idea was to provide an additional parameter for the Set-Resource Method called "$InitialPassword" which is only used when New-MgUser is called or to never update a password, when an application is used for authentication.

Which is the "M365 DSC way" to solve this?

Verbose logs showing the problem

debug log for patch method

HTTP Method:
PATCH

Absolute Uri:
https://graph.microsoft.com/v1.0/users/dsc.test@redacted

Headers:


Body:
{
  "displayName": "DSC 1, Test Nutzer",
  "passwordProfile": {
    "password": redacted
  },
  "userPrincipalName": "dsc.test@redacted"
}
DEBUG: [DESKTOP]:                            [[AADUser]Test] ============================ HTTP RESPONSE
============================

Status Code:
Forbidden

Headers:
[...]

Body:
{
  "error": {
    "code": "Authorization_RequestDenied",
    "message": "Insufficient privileges to complete the operation.",
    "innerError": {
[...]
    }
  }
}

Suggested solution to the issue

a.) never set the password when using application id and user is already provisioned
b.) add a new parameter $InitialPassword and use it when creating a user

if you point me in the right direction i'd love to implement the solution

Version of the DSC module that was used ('dev' if using current dev branch)

1.23.322.1

[NikCharlebois]

If no Password is provided, we generate a random password for the users via at creation:

$TokenSet = @{
                    U = [Char[]]'ABCDEFGHIJKLMNOPQRSTUVWXYZ'
                    L = [Char[]]'abcdefghijklmnopqrstuvwxyz'
                    N = [Char[]]'0123456789'
                    S = [Char[]]'!"#$%&''()*+,-./:;<=>?@[\]^_`{|}~'
                }

                $Upper = Get-Random -Count 5 -InputObject $TokenSet.U
                $Lower = Get-Random -Count 5 -InputObject $TokenSet.L
                $Number = Get-Random -Count 5 -InputObject $TokenSet.N
                $Special = Get-Random -Count 5 -InputObject $TokenSet.S

                $StringSet = $Upper + $Lower + $Number + $Special

                $stringPassword = (Get-Random -Count 15 -InputObject $StringSet) -join ''
                $passwordValue = ConvertTo-SecureString $stringPassword -AsPlainText -Force

[NikCharlebois]

There is a cmdlet to change a user's password, but it requires both the current password and the new password. Off course we cannot retrieve the current password with M365DSC so this is not something we can use:
https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.users.actions/update-mguserpassword?view=graph-powershell-1.0

My recommendation would be to update the code to simply stop to attempt to update the password when another property is modified. The resource would let you specify the initial password, but after that, the password can't be managed via DSC. Would that change solve your issue?

[adrianvb]

Yes, that would solve my use case.
I can try and implement the change, if that's ok with you.

[NikCharlebois]

That would be great. Let us know if you have any questions. Thanks

[adrianvb]

what a ride: i had to symlink/junction my fork in "C:\Program Files\WindowsPowerShell\Modules" so the LCM picks up the changes as well. Is there a better way?

The code change itself was rather quick, i hope this is in line with your idea for the solution.