How to set password for new user when provisioning users to on-premises AD DS using API-driven inbound provisioning

Question

Hi!
I have successfully set up inbound provisioning to on-premises AD DS. Everything works as planned, extended schema works flawlessly and Entra's provisioning logs shows that everything is working perfectly.

Except: The password that I have defined (using expressions) to be set during object creation in the provisioning schema is handled properly by the provisioning engine (Entra's side) up to the point where the user object is created in the on-premises AD DS directory. The password is listed in the provisioning log details in a proper format. The log entry result show "Success"under the "EntryExportAdd" in the details and all attributes are shown with proper values. Yet the password created during the user object creation doesn't match the assigned one. And yes, I have checked that the format of the password is allowed in the target OU of the AD DS directory, After the user object has been created I can manually change the password to match the one defined in the provisioning.

I have experimented with provisioning schema altering the password format (dynamic -> static) and account details (enabled/disabled etc.) to no avail.

I mean, if the AD DS inbound schema lists the password as a writable attribute then, grumble grumble, why cannot it be set?

BR, Jippe

Answer 1

When provisioning users to an on-premises Active Directory Domain Services (AD DS) using API-driven inbound provisioning, you typically need to set a password for the new user. The specific method may vary depending on the tools and APIs you are using, but here are general steps that can guide you through the process:

Steps to Set Password for New Users in On-Premises AD DS

1. Choose the Right API: Determine which API you will use for provisioning. Common options include Microsoft Graph API, LDAP, or custom scripts using PowerShell.
2. Prepare Your Environment:
   • Ensure you have the necessary permissions to create users and set passwords in AD DS.
   • If using PowerShell, ensure you have the Active Directory module installed.
3. Generate a Secure Password: Create a secure password that meets your organization's password policy. This can be done programmatically or manually.
4. Provision the User:
   • Use the appropriate command or API call to create the user account in AD DS.
   • For example, if using PowerShell, you might use:
   powershell New-ADUser -Name "New User" -GivenName "New" -Surname "User" -SamAccountName "newuser" -UserPrincipalName "******@domain.com" -Path "OU=Users,DC=domain,DC=com" -AccountPassword (ConvertTo-SecureString "YourSecurePassword123!" -AsPlainText -Force) -Enabled $true
5. Set Password Options:
   • When creating the user, ensure to set options such as requiring the user to change their password at the next logon if desired. For example:

powershell

 Set-ADUser -Identity "newuser" -ChangePasswordAtLogon $true

6. Error Handling: Implement error handling to manage any issues that arise during provisioning, such as password complexity failures or duplicate usernames.
7. Testing: Test the provisioning process with a few users to ensure that everything works as expected and that passwords are being set correctly.
8. Logging: Maintain logs of the provisioning process for auditing and troubleshooting purposes.

Example Using PowerShell

Here’s an example of how to provision a user with PowerShell:

powershell

Define user details

$username = "newuser"

$password = ConvertTo-SecureString "YourSecurePassword123!" -AsPlainText -Force

$ou = "OU=Users,DC=domain,DC=com"

Create new user

New-ADUser -Name "New User" `

       -GivenName "New" `

       -Surname "User" `

       -SamAccountName $username `

       -UserPrincipalName "$******@domain.com" `

       -Path $ou `

       -AccountPassword $password `

       -Enabled $true

Optionally require password change on first login

Set-ADUser -Identity $username -ChangePasswordAtLogon $true

Important Considerations

-Security: Ensure that passwords are handled securely. Avoid hardcoding passwords in scripts; consider using secure vaults or prompting for input.

- Policies: Be aware of your organization’s policies regarding password complexity and account management.

- Automation: If you're automating this process, consider implementing checks to avoid duplicate accounts or handle existing users gracefully.

Answer 2

@Jippe ZZZ Thank you for reaching out to us, As I understand your concern is related to password provisioning while using API-driven provisioning to on-premises Active Directory.

Provisioning passwords in not supported, we have documented the same here - https://learn.microsoft.com/en-us/entra/identity/app-provisioning/known-issues?pivots=app-provisioning#unsupported-scenarios:~:text=Unsupported%20scenarios

As a workaround, I suggested manually resetting the passwords for the provisioned users within your on-premises AD, also you can leverage PowerShell script to reset the passwords of the account created in on-premises AD or use a lifecycle workflow feature (This scenario assumes that the AD created on-premises will eventually sync to Entra ID).

Let me know if you have any further questions, feel free to post back.

Please remember to "Accept Answer" if answer helped, so that others in the community facing similar issues can easily find the solution.