Default $identity to $sam_account_name if it's set, $name if it isn't

[jimbo8098]

SUMMARY

Fixes an issue where the user's prior existence is checked based on the name parameter which is used as the display name of the user.

Currently, if both sam_account_name and name parameters are provided but no identity parameter is provided during runtime, the user will be created but later will cause errors since the New-ADUser cmdlet runs when the user already exists, causing an ADException. This is because the Get-ADUser cmdlet is run with the identity parameter set as it's -Identity parameter. identity defaults to the name parameter which would equate to the user's display name.

The current New-ADUser cmdlet creates users with the Name of the user as the SamAccountName and Name Property of the user. If you pass a separate SamAccountName property, the Name parameter is instead only set to the given Name parameter.

Here's an example showing how the PowerShell process works currently:

PS C:\Windows\system32> New-ADUser "Test User 2"
PS C:\Windows\system32> Get-ADUSer "Test User 2"


DistinguishedName : CN=Test User 2,CN=Users,DC=domain,DC=com
Enabled           : False
GivenName         :
Name              : Test User 2
ObjectClass       : user
ObjectGUID        : e4f36d2a-4d10-47d2-8bae-a7b6bf5eab97
SamAccountName    : Test User 2
SID               : S-1-5-21-370554974-2125117728-3394474177-1186
Surname           :
UserPrincipalName :



PS C:\Windows\system32> New-ADUser "Test User 3" -SamAccountName "test.user.3"
PS C:\Windows\system32> Get-ADUser "Test User 3"
Get-ADUser : Cannot find an object with identity: 'Test User 3' under: 'DC=domain,DC=com'.
At line:1 char:1
+ Get-ADUser "Test User 3"
+ ~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Test User 3:ADUser) [Get-ADUser], ADIdentityNotFoundException
    + FullyQualifiedErrorId : ActiveDirectoryCmdlet:Microsoft.ActiveDirectory.Management.ADIdentityNotFoundException,M
   icrosoft.ActiveDirectory.Management.Commands.GetADUser

PS C:\Windows\system32> Get-ADUser "test.user.3"


DistinguishedName : CN=Test User 3,CN=Users,DC=domain,DC=com
Enabled           : False
GivenName         :
Name              : Test User 3
ObjectClass       : user
ObjectGUID        : 6107d492-c4ee-46a8-ae20-905948904991
SamAccountName    : test.user.3
SID               : S-1-5-21-370554974-2125117728-3394474177-1187
Surname           :
UserPrincipalName :

The fix sets the identity module parameter to the sam_account_name provided preferentially, otherwise the name is used. This should mean that users updating the collection will be unaffected since if they were using just the name previously, the handling of the rest of the module is exactly the same.

Fixes #344

ISSUE TYPE

• Bugfix Pull Request

COMPONENT NAME

community.windows/win_domain_user

[jborean93]

I feel the justification here makes sense, essentially it's just prioritizing the default of identity to be the sAMAccountName value if set and finally falling back to the name specified in the case sam_account_name isn't set. Is it possible to update the documentation for this parameter here https://github.com/ansible-collections/community.windows/blob/main/plugins/modules/win_domain_user.py#L23 to reflect this new behaviour.

If you are are feeling up to it it would also be great if you can create a changelog fragment under https://github.com/ansible-collections/community.windows/tree/main/changelogs/fragments. Have a look at https://github.com/ansible-collections/community.windows/blob/main/changelogs/fragments/330_win_domain_user.yml to see how they are structured.

[jimbo8098]

Makes sense, will look to submit on Monday.

[jborean93]

Not sure why the CI status hasn't been updated but on a rerun the tests pass https://dev.azure.com/ansible/community.windows/_build/results?buildId=32041&view=logs&jobId=15e82602-2c7e-5cc7-d0a1-f15ef453aa70&j=1bcebbb2-61b8-532e-b461-2508a6839989 (the previous error was an unrelated startup problem).

Thanks for the great work here.