Support password reset via azuread_user provider

[op7ic]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritise this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritise the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

I was recently investigating creation of VDPOOLs and ADDS users, along with the domain to spring up complete infrastructure which would allow for remote application access via an AVD. As part of this research process, I observed that terraform does not have a method of performing password reset on azuread_user provider. Terraform needs that ability to reset ADDS passwords for users in order to comply with Microsoft design as outlined below.

"""
To authenticate users on the managed domain, Azure AD DS needs password hashes in a format that's suitable for NT LAN Manager (NTLM) and Kerberos authentication. Azure AD doesn't generate or store password hashes in the format that's required for NTLM or Kerberos authentication until you enable Azure AD DS for your tenant. For security reasons, Azure AD also doesn't store any password credentials in clear-text form. Therefore, Azure AD can't automatically generate these NTLM or Kerberos password hashes based on users' existing credentials. The steps to generate and store these password hashes are different for cloud-only user accounts created in Azure AD versus user accounts that are synchronized from your on-premises directory using Azure AD Connect.

A cloud-only user account is an account that was created in your Azure AD directory using either the Azure portal or Azure AD PowerShell cmdlets. These user accounts aren't synchronized from an on-premises directory. For cloud-only user accounts, users must change their passwords before they can use Azure AD DS. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD. The account isn't synchronized from Azure AD to Azure AD DS until the password is changed. Either expire the passwords for all cloud users in the tenant who need to use Azure AD DS, which forces a password change on next sign-in, or instruct cloud users to manually change their passwords.

"""

Because of the password management design, it effectively removes the ability create new ADDS accounts to perform administrative actions such as joining the AVD systems to the AD domain as, without password reset, the account won't have NTLM hashes needed for the process to succeed. This results in JsonADDomainExtension failing on AVD creation.

New or Affected Resource(s)

• azuread_user

Potential Terraform Configuration

resource "azuread_user" "dc_admin" {
  user_principal_name              = "[email protected]"
  display_name                         = "AADDS DC Administrator"
  password                               = "Helo1235%"
  force_password_change       = false
  account_enabled                   = true
  disable_password_expiration = true
  reset_password                      = true # This would reset password to random value and set it back to original password 
}

References

• https://learn.microsoft.com/en-us/azure/active-directory-domain-services/tutorial-create-instance#enable-user-accounts-for-azure-ad-ds

[manicminer]

Hi @op7ic, thanks for requesting this. I agree that the ability to reset a password is an important part of user lifecycle management. However, I am not sure that the proposed implementation would work very well in the long term? Having a property reset_password, or something to that effect, would basically cause Terraform to attempt this on every apply operation - resetting user passwords every time you run Terraform. Using such a property non-disruptively would require adding it to your configuration, running Terraform, removing/unsetting it from your configuration, and running Terraform again.

It's actually possible to have Terraform "reset" the password to a known value, by deriving a password value like this:

resource "azuread_user" "example" {
  user_principal_name = "${var.name}@acme.net"
  password = "resetMe${var.name}54374186"
  force_password_change = true
}

or a proper random string

resource "random_password" "password" {
  length           = 16
  special          = true
  override_special = "!#$%&*()-_=+[]{}<>:?"
}

resource "azuread_user" "example" {
  user_principal_name = "${var.name}@acme.net"
  password = random_password.example.result
  force_password_change = true
}

When a user is first created, Terraform will set the specified password and force a password change when the user signs in. To have Terraform repeat this, simply change the password value somehow and re-apply, then both the password itself, and the force_password_change setting, will be re-set.

Most practitioner implementations of this resource take advantage of this behavior to manage users with Terraform, whilst also allowing users to set their own passwords out of band. Once a user has updated their password, Terraform has no record of this and cannot temporarily change the password and then change it back to the user's previous password. It can only reset the password to a known value - functionality which it does currently support.

I hope I have explained this well. Do you think this approach would work for you? The alternative, which I believe is suggested by Microsoft, is when you are initially replicating users to AADDS, to communicate to your users that they must themselves change their password in order for them to synchronize their NTLM hash and accordingly gain access to whichever services you are depending on AD.

[op7ic]

hi @manicminer apologies for late reply.

I think that could work. I came across password reset issue when deploying Azure AD and attempting to connect systems to newly created active directory during build process (so the account is without user interaction). The account used for this process needs to have password resetted before it can be used by JsonADDomainExtension as default user creation does not create NTLM hashes as per Microsoft documentation. In this case, would something like this work to create a password reset routine that could be used to automate the build?

resource "random_password" "password1" {
length = 16
special = true
override_special = "!#$%&*()-_=+[]{}<>:?"
}

resource "random_password" "password2" {
length = 16
special = true
override_special = "!#$%&*()-_=+[]{}<>:?"
}

resource "azuread_user" "example1" {
user_principal_name = "[email protected]"
password = random_password.example1.result
force_password_change = true
}

resource "azuread_user" "example2" {
user_principal_name = "[email protected]"
password = random_password.example2.result
force_password_change = no
}

[manicminer]

@op7ic That would update the passwords and so it should achieve the goal of creating an NTLM hash for those users. The main thing to be aware of is that you'll likely want to know the value of the new/temporary password so it'll either need to be predictable, or you'd need to set an output variable.

[op7ic]

hi @manicminer so I tried above to see if it would force NTLM hash crreation but got an error back from Terraform: "UsersClient.BaseClient.Post(): unexpected status 401 with OData error: InvalidAuthenticationToken: Access token has expired or is not yet valid." Not sure why this errors pops out since token is currently valid and gives access to create all of the resources.

[manicminer]

@op7ic There's a known issue at the moment #918, which should be fixed in this week's release

[op7ic]

@manicminer just a quick note to say that timeout issue was fixed. I sorted password/NTLM password sync by creating AADS first, before creating users as opposed to creating users and then AADS.

[manicminer]

Thanks for the feedback, I'm going to go ahead and close this issue out for now, due to the reasons I mentioned earlier and that I believe we have the most tenable solution in place already for resetting passwords. Thanks for the discussion!