Open singhalss opened 3 years ago
Hi @singhalss , thanks for opening this issue. You will need following the steps in the document to "Creating an identity representing the storage account in your AD manually" and then "Enable the feature on your storage account" by setting these AD directory options.
Thanks for your response @yupwei68.
Does that mean that we always first need to create the storage account via terraform and then domain join the storage account outside terraform (option 1 or 2 as mentioned in document) and then again update terraform code with azure_files_authentication block - storage_sid and other attributes with the values obtained from the domain join step, to finally save AD properties in terraform state for the storage account?
Please correct me if I am misunderstood this.
@singhalss I think so. Just I think if using option 1, you'll not need to set the AD directory options of the storage account in TF, I think "Join-AzStorageAccountForAuth" is a script which has included this step. As for option 2, you'll need to create a storage account, then "Creating an identity representing the storage account in your AD manually", then save the AD directory options in storage account.
Hi @yupwei68 - thanks again for your response.
What I am thinking is, in order to fully automate this domain join step, I can use a terraform provisioner for running the powershell given in option 1. Your thoughts please?
@singhalss Please have a try.
I'm glad to have found this thread because Terraform is trying to break our AD configuration on our storage accounts after upgrading to the latest Azure_RM Provider.
What is the purpose of the new code block? azure_files_authentication { directory_type = "AD"
Terraform does not create this. This configuration is created outside of Terraform. Terraform is coming along after the fact and destroying it if you don't then go and update TF with what you already did elsewhere. What purpose does that serve other than make you do extra work to tell Terraform what exists? Isn't there a way we can ignore this "feature?"
I actually just ran into this very issue. have to re-establish the ad connection. I have added this to my terraform to ignore changes in that configuration group.
lifecycle {
ignorechanges = [azure_files_authentication]
}
Still have to apply it to make sure it works.
this does not feel like its the best way to do any of this, if anyone knows of a terraform oriented way to accomplish this end to end it would be great to know.
Has anybody tried precreating the AD object and getting its SID?
Hi All, While looking at the documentation, I found that we need to specify storage_sid as one of the required values in azure_files_authentication block. storage_sid is generated once the storage account joins AD, not sure what value to specify to storage SID while creating the storage account.
Please refer to below documentation link.
https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/storage_account#active_directory
Also, one more doubt, while running terraform in context of service principal (SPN), what permissions are required to be given to SPN to accomplish this task. As per my understanding, service account/SPN will need to have domain join permissions for accomplishing this task and also in automation context, it needs to be executed from a domain join machine.
Please correct me if I am wrong and guide further to make use of this feature in terraform provider.
Originally posted by @singhalss in https://github.com/terraform-providers/terraform-provider-azurerm/issues/11485#issuecomment-862889366