Open hshmilov opened 3 years ago
techBeck03
commented
3 years ago I had this exact issue when I set the winrm_hostname to my domain name example.com. My theory (and I'm no AD expert) is that the create is happening on one of my domain controllers and the read is getting DNS load balanced to the other domain controller which isn't yet in sync. When I changed my winrm_hostname to a specific domain controller I no longer got this error.
ryantho6
commented
3 years ago I got this error too while using second hop. I suspect, as @techBeck03 said, it's due to reading from multiple DCs. I believe the get-adobject command (and probably other) uses a -server DOMAIN.COM rather than -server SPECIFICDC
juanjojulian
commented
2 years ago Hi, we are getting this same problem here when creating ad_computer resources, we have a pretty big multisite and multi region domain with several domain controllers. ad provider is configured with Double hop Authentication. I assume that this is due to the way the provider works, once the creation of the Computer Object is done the function calls resourceADComputerRead() in order to verify the creation:
func resourceADComputerCreate(d *schema.ResourceData, meta interface{}) error {
computer := winrmhelper.NewComputerFromResource(d)
guid, err := computer.Create(meta.(*config.ProviderConf))
if err != nil {
return fmt.Errorf("error while creating new computer object: %s", err)
}
d.SetId(guid)
return resourceADComputerRead(d, meta)
}In my case the Computer Object is successfully created:
2022-02-24T15:48:56.399Z [INFO] provider.terraform-provider-ad_v0.4.3_x5: 2022/02/24 15:48:56 [DEBUG] Constructing powerrshell command: $Password = ConvertTo-SecureString -String "<REDACTED>" -AsPlainText -Force
$User = "ADTest"
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User, $Password
New-ADComputer -Passthru -Name "terraform-test3" -Path "OU=Servers_TEST,OU=Servers,DC=XXX,DC=XX,DC=com" -Description "terraform-test3 - Private Cloud" -Credential $Credential -Server XXX.XX.COM | ConvertTo-Json: timestamp=2022-02-24T15:48:56.399Z
2022-02-24T15:48:56.400Z [INFO] provider.terraform-provider-ad_v0.4.3_x5: 2022/02/24 15:48:56 [DEBUG] Executing command on remote host: timestamp=2022-02-24T15:48:56.400ZBut Get-ADComputer command is failing (directory object not found):
2022-02-24T15:48:59.677Z [INFO] provider.terraform-provider-ad_v0.4.3_x5: 2022/02/24 15:48:59 [DEBUG] Constructing powerrshell command: $Password = ConvertTo-SecureString -String "<REDACTED>" -AsPlainText -Force
$User = "ADTest"
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User, $Password
Get-ADComputer -Identity "1abe1178-f263-418c-8e80-aaa2b066ceb2" -Properties * -Credential $Credential -Server XXX.XX.COM | ConvertTo-Json: timestamp=2022-02-24T15:48:59.677Z
2022-02-24T15:48:59.677Z [INFO] provider.terraform-provider-ad_v0.4.3_x5: 2022/02/24 15:48:59 [DEBUG] Executing command on remote host: timestamp=2022-02-24T15:48:59.677Z
Only 3 seconds between the New-ADComputer command and the Get-ADComputer command but if I'm not mistaken and due to the way winrm works both commands are completely separated and independent winrm sessions which means that the first "New-ADComputer" could be issued against one domain controller and the "Get-ADComputer" against a different one and only 3 seconds could not be enough for AD replication in big multi-region domains.
Could it be possible to delay the verification a little bit? Maybe by adding a time.Sleep(30 * time.Second) to both "resourceADComputerCreate" and "resourceADComputerUpdate"?
func resourceADComputerCreate(d *schema.ResourceData, meta interface{}) error {
computer := winrmhelper.NewComputerFromResource(d)
guid, err := computer.Create(meta.(*config.ProviderConf))
if err != nil {
return fmt.Errorf("error while creating new computer object: %s", err)
}
d.SetId(guid)
time.Sleep(30 * time.Second)
return resourceADComputerRead(d, meta)
}
Sdougal
commented
1 year ago Just want to add I've just hit this as well...
Double hop Kerberos auth in azure using a self hosted terraform cloud agent using a mgmt VM to create OUs in Azure Active Directory Domain Services.
The OUs were created but Terraform Cloud reported a failure and therefore the resources don't appear in the state file.
"Error: Provider produced inconsistent result after apply When applying changes to ad_ou., provider "provider[\"registry.terraform.io/hashicorp/ad\"]" produced an unexpected new value: Root resource was present, but now absent.
This is a bug in the provider, which should be reported in the provider's own issue tracker."
jwhite-ac
commented
1 year ago Only 3 seconds between the New-ADComputer command and the Get-ADComputer command but if I'm not mistaken and due to the way winrm works both commands are completely separated and independent winrm sessions which means that the first "New-ADComputer" could be issued against one domain controller and the "Get-ADComputer" against a different one and only 3 seconds could not be enough for AD replication in big multi-region domains.
Could it be possible to delay the verification a little bit? Maybe by adding a time.Sleep(30 * time.Second) to both "resourceADComputerCreate" and "resourceADComputerUpdate"?
Hitting this exact issue today, you are dead right, one session is creating the object, another is verifying, and they're both hitting different DCs - the change has not had a chance to propagate against all of them.
We've worked around this by targeting a specific DC, and it appears the solution for the provider is simple (wait and/or retry). Incredible that this has been open for 2 years and not fixed...
Terraform version: 1.0.3 / terraform-provider-ad_v0.4.3_x5 apply new AD Host(s) ( using double hop authN ) result with :
Error: Provider produced inconsistent result after apply When applying changes to ad_computer.AxonHost[1], provider "provider[\"registry.terraform.io/hashicorp/ad\"]" produced an unexpected new value: Root resource was present, but now absent.
This is a bug in the provider, which should be reported in the provider's own issue tracker.
do note all host created successfully on AD . it looks as someting related to post verification with state
creating a single ad host will succeed most of the time.
Terraform Configuration Files
variable "generate" { default = 2 }
resource "ad_computer" "AxonHost" { count = var.generate name = "AXON-${count.index}" description = "AXON HOST ${count.index}" container = "OU=Computers,OU=hanan-domain-2,DC=hanan-domain-2,DC=axonius,DC=test" pre2kname = "AXON${count.index}$" }