Upgrade to azuread v3 leads to azuread_application_password recreation

[lra]

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

Terraform (and AzureAD Provider) Version

Terraform v1.9.6
on darwin_arm64
+ provider registry.terraform.io/hashicorp/azuread v3.0.1

Affected Resource(s)

• azuread_application_password

Terraform Configuration Files

resource "azuread_application_password" "this" {
  # The upgrade to azuread v3 triiger replacement if we leave this set
  display_name   = "some name"
  application_id = azuread_application.kv_client_sops_app.id
  end_date       = "2299-01-01T01:02:03Z"
}

Debug Output

Panic Output

Expected Behavior

When the azuread_application_password has been created under azuread v2, and we upgrade to azuread v3, the azuread_application_password should not be recreated.

Actual Behavior

Upgrading the provider to azuread v3 leads to recreating the resource:

  # azuread_application_password.this must be replaced
-/+ resource "azuread_application_password" "this" {
      + display_name   = "some name" # forces replacement
      ~ id             = "REDACTED" -> (known after apply)
      ~ key_id         = "REDACTED" -> (known after apply)
      ~ start_date     = "2021-08-11T22:22:34.7126128Z" -> (known after apply)
      ~ value          = (sensitive value)
        # (2 unchanged attributes hidden)
    }

Steps to Reproduce

1. Set the provider to azuread 2.53.1
2. terraform apply to create the azuread_application_password resource
3. Set the provider to azuread 3.0.1
4. 2. terraform plan will show that it wants to recreate the resource

Important Factoids

References

[babuga365]

Is it related to this one?

As per documentation: the [end_date_relative] (https://registry.terraform.io/providers/hashicorp/azuread/latest/docs/resources/application_password#end_date_relative) - (Optional) A relative duration for which the password is valid until, for example 240h (10 days) or 2400h30m. Changing this field forces a new resource to be created.

And in azuread provider v3.0.1, i'm getting below deprecation message. If I remove the paramer: end_date_relative from resource definition, its trying to recreate the whole resource; azuread_application_password

│ The end_date_relative property is deprecated and will be removed in a
│ future version of the AzureAD provider. Please instead use the Terraform
│ timeadd() function to calculate a value for the end_date property.

do we have any fix for this deprecation to disable the resource recreation?

[manicminer]

For existing passwords, you'll need to use ignore_changes to prevent recreation of the password. It's safe to continue using end_date_relative during the deprecation period, as it will not be removed until the next major version of the provider.

[babuga365]

For existing passwords, you'll need to use ignore_changes to prevent recreation of the password. It's safe to continue using end_date_relative during the deprecation period, as it will not be removed until the next major version of the provider.

@manicminer, thanks for the update. I will use end_date_relative as its for now.

[rlees85]

So in azuread 4 we can expect to have no decent way of managing relative expiration of passwords? Sure we can use timeadd and then set ignore on end_date (otherwise it will change all the time). But then if we wanted to actually change the relative time then we can't because the changes would be ignored.

Confused as to why we are removing functionality?

[manicminer]

@rlees85 You can use the Time provider to get a static datetime which will be persisted to state, or even use the time_rotating resource to automatically replace the password when it lapses. I can look to add examples to the documentation.

[rlees85]

thank you @manicminer . I am using time_rotating but I also wanted a sane value on the end date. Didn't know the time provider could provide me a static date time as well, that does not move. I will look into this.

[Noel-Jones]

Should the issue/discussion regarding the end_date_relative be taken to another issue? This issue is specific to the display_name, which is forceing replacement despite the only change being the azuread provider version moving to v3.

I note the reference to use ignore_changes to prevent recreation of the password. It certainly works but I trust this is only a workaround and not the recommended fix?

  lifecycle {
    ignore_changes = [
      display_name
    ]

[Noel-Jones]

I have tried the plan with debug and it's a bit weird! My password created through Terraform with AzureAd v2 shows in the console with display name "Terraform Managed" and the value is shown as "Hidden". I created a password with a display name "Delete Me" and the value is shown with a hint. Implies some differences depending on how the password was created. The Terraform debug output reveals the following:

"passwordCredentials":[
{"customKeyIdentifier":null,"displayName":"Delete Me","endDateTime":"2025...","hint":"te.",...
{"customKeyIdentifier":"VGVycmFmb3JtIE1hbmFnZWQ=","displayName":null,"endDateTime":"2099...","hint":null,...
]

What is particularly interesting is that the customKeyIdentifier "VGVycmFmb3JtIE1hbmFnZWQ=" is the base64 encoding of "Terraform Managed", i.e. it is the display name. Question is whether this can be used as the basis of a fix? Need to see what it looks like when the provider v3 is used to create a password. Tomorrow.