Terraform-provider-aws: import aws_directory_service_directory doesn't import connect_settings

[wjrogers]

Community Note

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

Terraform Version

Terraform v0.12.13

• provider.aws v2.34.0
• provider.http v1.1.1
• provider.null v2.1.2

Affected Resource(s)

• aws_directory_service_directory

Terraform Configuration Files

resource "aws_directory_service_directory" "corp" {
  type = "ADConnector"
  size = "Small"
  name = "CORP.local"
  short_name = "CORP"
  description = "CORP"
  password = "secret"

  connect_settings {
    customer_username = "aws"
    customer_dns_ips = [
      "10.1.1.1",
      "10.2.1.1",
    ]
    subnet_ids = [
      "subnet-1",
      "subnet-2",
    ]
    vpc_id = "vpc-1"
  }

  tags = {}
}

Expected Behavior

terraform import adds all attributes of the directory -- including connect_settings -- to the terraform state. Subsequent plans do not modify the AWS resource.

Actual Behavior

After import, the connect_settings attribute is missing from the state, and subsequent plans _replace_ the resource. Output of terraform state show:

resource "aws_directory_service_directory" "corp" {
    access_url        = "d-redacted.awsapps.com"
    alias             = "d-redacted"
    description       = "CORP"
    dns_ip_addresses  = [
        "10.3.1.1",
        "10.3.2.1",
    ]
    enable_sso        = false
    id                = "d-redacted"
    name              = "CORP.local"
    security_group_id = "sg-0"
    short_name        = "CORP"
    size              = "Small"
    tags              = {}
    type              = "ADConnector"
}

Output of terraform plan:

  # aws_directory_service_directory.corp must be replaced
-/+ resource "aws_directory_service_directory" "corp" {
      # ...

      + connect_settings { # forces replacement
          + customer_dns_ips  = [
              + "10.1.1.1",
              + "10.2.1.1",
            ] # forces replacement
          + customer_username = "aws" # forces replacement
          + subnet_ids        = [
              + "subnet-1",
              + "subnet-2",
            ] # forces replacement
          + vpc_id            = "vpc-1" # forces replacement
        }
    }

Steps to Reproduce

1. Create an AWS Directory Service AD Connector manually in the AWS console.
2. Write a terraform configuration that describes the resource e.g. as above.
3. terraform import aws_directory_service_directory.corp d-redacted
4. terraform plan

[erighi]

Hello,
I am trying to import my aws ms ad and I have the same issue

[DrFaust92]

i opened a PR to address this, the issue stems from trying to set a non existent connect_ips attribute and swallowing the error.

[wjrogers]

I just noticed that the provider also cannot detect changes to customer_dns_ips in an existing directory resource. When I manually change the "Existing DNS addresses" in the AWS Console then modify the Terraform configuration to match, Terraform always wants to destroy and re-create the directory, even though in reality there is no drift. Is this the same bug? Seems plausible that import and refreshing of state would use the same code path.

[DrFaust92]

I believe its the same issue because it just failed silently before when setting state. i saw it fail after adding error handling. customer_dns_ips was set in the same place i changed

[hashibot[bot]]

This has been released in version 2.65.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks!

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!