Looking for community feedback on the AD provider

[redeux]

Hi!

I'm Phil, the product manager for the team working on the Active Directory provider. We're trying to determine the future of the provider, and I could use your help. If you're actively using the provider, or if you'd like to use the provider but can't, I'd like to speak with you for a few minutes to learn more about your use cases.

If that's something you're willing to do, please book time directly on my calendar.

Thanks in advance.

[tonglil]

We looked at using this but are currently using this other one: https://github.com/GSLabDev/terraform-provider-ad

[redeux]

Thanks for the reply @tonglil. I have a couple follow-up questions, if you don't mind.

Is there something that the provider you referenced covers that this one doesn't, that's preventing you from switching?

Is there a part of your AD workflow that neither of these providers cover, that you have do manually or use another tool?

[swickera]

Basic auth and only support for local accounts is a non-starter for us. Is there an ETA for maturing the security of the provider?

[briantist]

Same, basic auth/local accounts only == unusable. I wouldn't even set up a test domain that way. Also #54

Group membership was recently added in #51 but I can't tell if it has the flexibility we need (to be able to add any member type supported by an AD group, including Foreign Service Principals to support cross-forest trusts).

[kevinclev]

I imagine that most use cases for this provider are going require support for domain authentication (probably kerberos, cert, and NTLM as well). However, I do want to point out that the lack of support for domain accounts is not a native problem of the provider itself but rather an issue with the winrm golang library that is being used here. Which that library currently doesn't domain accounts.

[jpatigny]

I have the same challenge.
I can only use kerberos authentication protocol.

I have two possibilities :

• supporting kerberos for winrm
• use terraform inside a docker container using a gmsa (execute cmdlet locally and not connecting to a remote host)

For now, none of those options are usable with this provider.
It has been discussed in the following issue : https://github.com/hashicorp/terraform-provider-ad/issues/34
I might be able to test it with this provider soon 👍

I also have some resources missing but it's less important at the moment

[fabiotito]

Can you tell me what are the specific user permissions for the provider? The blog just says that you need a user with administrator privileges. Is it absolutely necessary to add the user in the administrators group?

[redeux]

Thanks for all the feedback so far! I want to let you all know that we're planning to cut a release with Kerberos (#57) and (hopefully) NTLM (#56) support early next week.

[Enteris]

I'd be very interested to use it, but we would require functional AWS support #40 .

[koikonom]

Hello, just wanted to let you know that version 0.4.0 of the provider was released yesterday with support for Kerberos and NTLM authentication.

[awasilyev]

Just tried it. Is it possible to auth on winrm without having password defined in a plaintext?
Using existing kerberos token or ntlm for example..

[eramnes]

First off, I'd like to say that I like the idea of an officially maintained Active Directory provider and I'm looking forward to seeing where this project goes. I spent a few hours experimenting with the plugin yesterday and I have some feedback on the current state.

• The Kerberos authentication option for the provider requires the krb_realm option to be set, but this isn't clear in the existing documentation. The section on Kerberos auth only mentions the krb5.conf file.
• As far as I can tell, the provider can only function if it connects directly to an Active Directory domain controller. If I specify a separate winrm_host than is configured in a custom krb5.conf file under the kdc and admin_server the provider fails to provision a computer account with a Kerberos error. I suspect this is due to the double-hop authentication problem, since the provider appears to use PowerShell provisioning.

The double-hop issue isn't really a problem with the provider per se, but at least in my use case I'd prefer not to have a domain admin account required for simply creating computer objects. I suppose we could set up resource-based Kerberos constrained delegation to a particular DC for a service account, but this seems like a burden just to create a computer/user/group. Honestly, I'm not even sure that would solve this issue since it doesn't support the second hop on WinRM. CredSSP could work as well, but it's somewhat of a security risk.

In the end, I ended up using the GSLabDev AD Provider. Their LDAP-based approach to managing AD objects seems to be much simpler than having to mess with delegation, double-hop, needing direct use of a domain controller, etc. Perhaps adding an LDAP-based connection type to the provider could help use cases where users didn't want or weren't able to directly access a domain controller? The Hashicorp provider is available from the registry, while the GSLabDev one isn't, which is a huge benefit for using the Hashicorp provider.

As I mentioned, I only spent a few hours experimenting, so it's possible that I could have missed a configuration step somewhere along the way which would make this work the way I want. The provider is still experimental, so I understand the documentation being a bit lacking at this point. I've always been impressed with Hashicorp documentation for every other Terraform function I've used, so I know it will be addressed at some point.

I'm glad to see Hashicorp working on this provider and would be open to replacing my existing provider if the direct dependency on domain controllers is resolved in some way. Thanks for the work on this!

[jpatigny]

@eramnes ,

The "problem" that I see with the LDAP based approach is that you're limiting yourself to pure LDAP object while using powershell you can open many other possibilities (manage GPO's, DNS etc...).
As long as you have cmdlet matching the CRUD principal (New, Get, Set, Remove verbs) , possibilities are endless.

About the double hop issue,

I had similar problem and for security reasons. I ended up using a windows docker container including terraform authenticated as a gMSA. That way, you don't need to connect to any remote host, you can pass your cmdlet locally while being authenticated via kerberos.
It's a win win for me as I'm already using terraform inside docker container for CICD purpose.
I know it's a twisted setup but it's actually even more secure than using winrm because of the usage of gMSA instead of regulary service account which allows you to :

• not managed passwords
• limit the scope of hosts allowed to interact with the AD

[briantist]

There is another alternative, which is to connect to the domain controller with PSRP (PowerShell Remoting Protocol) instead of over pure WinRM + launch powershell.exe.

This would allow one to use constrained endpoints and JEA to allow unprivileged users to connect to the domain controllers, and execute a limited set of commands, where the account that runs the commands can have just domain privileges needed (and can even be a virtual account).

By crafting the role definitions and role capabilities files carefully, it could be possible to set up a policy without even writing PowerShell-side wrapper functions (although that's also easy to do).

This also better allows for connections that don't directly hit a DC, since when using a RunAs account, you avoid the double-hop issue, so the server you connect to wouldn't have to be a DC (this wouldn't work with a virtual account, but would with a pre-defined domain service account).

The main impediment to this though, is that I don't think there is any existing Go library that implements this protocol on the level of something like pypsrp.

[eramnes]

@jpatigny
I have to preface this by saying that I'm not too familiar with Terraform usage - we're just at the start of an IaC push and I have a lot to learn. That being said, I can see your use case but I have some questions about why things would be done the way you're suggesting.

In my understanding, Terraform is used to define the machines/containers that things run on. In my use case, I just need to have a computer account created in AD that can be automatically removed when the resource is destroyed, so everything gets cleaned up. The LDAP-based provider module from GSLabDev does this easily without having to connect to a DC or handle double-hop authentication. This provider can also manage OUs, users, groups, etc.

The Group Policy and DNS cases you mentioned seem to me to be configuration steps which, to my understanding, are something that Terraform isn't meant to do. I'm not saying that it's not needed in some use cases, but in my use case, many of our GPOs are already defined on the OUs where Terraform-created computer accounts would be located. If we wanted to configure something that wasn't defined by a GPO, this seems like a situation where we could use the Ansible DSC module or manually create a GPO for the OU the systems go in. Since they would affect all systems in the OU, this isn't a burden for us at this time.

As far as I can tell, the ad_gpo resource can currently only create a blank GPO. PowerShell itself seems to be unable to create a configured GPO without having the exact Windows Registry settings that the GPO would set, which doesn't seem as accessible as using DSC. It seems to me that it would clutter up the .tf file written for that functionality if the configuration for a GPO was specified there. It's true that DSC has its limitations, but some GPOs can be converted to DSC by using ConvertFrom-GPO.

I can't speak about any of the DNS cases, since we use Infoblox for DNS and have no need for managing AD-based DNS.

In my opinion, the ideal would be for both WinRM and LDAP to be supported in the provider, with the understanding that if LDAP was selected as the method that some functionality would be unavailable:

provider "ad" {
      # Cannot use WinRM functionality with LDAP method
      # method could be winrm instead for WinRM functionality
      method        = ldap
      ldap_user     = username@ad.example.com
      ldap_password = password
      ldap_uri      = ldaps://ad.example.com
}

This would allow for WinRM functionality for those that need it, and basic LDAP for those who just need LDAP objects created.

What works in my use case is using Ansible dynamic inventory generated from Terraform to handle the configuration required for machines outside of the Terraform provisioning steps.

I guess it all depends on your use case and what you need Terraform to manage. No single provider for this functionality is likely to satisfy every use case, and that's OK.

@briantist
This seems like the best option for the double-hop problem. I'd not seen this option before.

[koikonom]

@briantist thanks for the PSRP suggestion I will take a look and see what would it take for the provider to use it.

I opened issue #78 to track this.

[koikonom]

Hi @eramnes.

Thanks for your feedback, much appreciated. I will try to address the points you made, please let me know if I miss something !

• Documentation is definitely something we are planning to improve, in the mean time feel free to open issues in this repository if something doesn't add up and we will do our best to respond to them.

• Initially the plan was to use LDAP to manage AD, but we soon realized that not everything we wanted to do was possible through the LDAP interface (GPOs being the most important one) and believed that asking users to use both LDAP and WinRM would be more problematic in the long run. As you noted this provider is still in tech preview, so nothing is set in stone !

• ad_gpo can only create empty GPOs as you noted already. The idea is that you can then use other resources to manage the contents of the policy. Currently only the security settings part of the GPO can be configured through the ad_gpo_security resource . We do plan to add more GPO related resources in the future, but wanted to see what the community needs first.

[koikonom]

@awasilyev I opened #79 to track adding keytab support.

[galad2003]

First off thanks for all the hard work on this. We all know its not easy and takes a lot of work. The community greatly appreciates it.

So my feedback:

• Improved documentation and examples. Until I read this thread I had no idea I had to run these commands against a domain controller and thus use a Domain Admin account. No way the is going to happen in a production environment for the simpler tasks.
• Better error messages to help us troubleshoot.

[cduranleau]

@redeux Any idea when the next release is planned for? We're looking to consume the 'run on the local machine' behavior.

[redeux]

@redeux Any idea when the next release is planned for? We're looking to consume the 'run on the local machine' behavior.

Hey everyone, if you're not already aware, we released this functionality yesterday. Special thanks to @jpatigny for the work on this!

[koikonom]

Hello again! I've opened #99 to focus on the subject of how can we get the provider to work without having to talk to a DC directly.

Please take a look and let me know what you think!

[MichaelSPaik]

Does this provider only run on windows or can it run on mac/linux?

[gramsa49]

Hello again! I've opened #99 to focus on the subject of how can we get the provider to work without having to talk to a DC directly.

Please take a look and let me know what you think!

I wrote a patch (Pull Request 107) that works around the double-hop issue by creating a System.Management.Automation.PSCredential object in the remote PowerShell session using the winrm_username and winrm_password defined in the provider's configuration, then using that object to authenticate to the AD DC.

This is the 'Pass credentials inside an Invoke-Command script block' referenced in this article:

The approach is different from the solution proposed in #99, but achieves the expected result.

I welcome any feedback on the proposed patch.

[pshamus]

@eramnes ,

The "problem" that I see with the LDAP based approach is that you're limiting yourself to pure LDAP object while using powershell you can open many other possibilities (manage GPO's, DNS etc...).
As long as you have cmdlet matching the CRUD principal (New, Get, Set, Remove verbs) , possibilities are endless.

About the double hop issue,

I had similar problem and for security reasons. I ended up using a windows docker container including terraform authenticated as a gMSA. That way, you don't need to connect to any remote host, you can pass your cmdlet locally while being authenticated via kerberos.
It's a win win for me as I'm already using terraform inside docker container for CICD purpose.
I know it's a twisted setup but it's actually even more secure than using winrm because of the usage of gMSA instead of regulary service account which allows you to :

• not managed passwords
• limit the scope of hosts allowed to interact with the AD

@jpatigny can you elaborate on your Windows docker setup?

[jpatigny]

@pshamus ,

Here is a more detailed setup : issue-34
If it's still not enough feel free to reach out to me :-)

[randomswdev]

@redeux, we are experiencing the problems described in the issue #113. We are interested in understanding if we can consider Linux equivalent to windows from a coverage, testing and support point of view. Currntly it appears that the Linux build is less stable than the Windows one.

We prefer using Linux because it is simpler to deploy or run in containers. For this reason we run all of our terraform based atomations in Linux and we would like to include automation of the AD, without having to migrate everything to Windows. If you want more details about our use cases we can arrange a call.

[ryantho6]

I want to use it, but I'm either not understanding based on the examples, or just having general issues with using Kerberos and WinRM. #62

[johnylippuner]

i also want to use it, mostly for adding and editing gpos and also for joining windows servers to the domain. for the gpo part it would be great if theres a possibility to import existing gpo configurations for using with this provider. like this it would be much easyer to migrate a existing gpo to terraform. export gpo as xml and use this file as input for the provider for example. is there any way to do so or are there any other ideas for this requirement?

[ht-accenture]

I am currently not using but would very much like to. Unfortunately, my use case is currently not covered by the functionalities provided. I would like to get group information to be able to iterate over (transitive) memberships. I acknowledge that group memberhships can already be managed as a resource using the 'ad_group_membership' resource but it would be nice to have the 'ad_group_membership' data source.

[hoivikaj]

@redeux Do you know if @koikonom is still maintaining this repo, there have been a few open PR's for a while now and the profile for @koikonom seems to indicate no hashicorp contributions since April/May, when the PR's stopped merging. Maybe @aareet knows?

[MarkRKar]

Hello, we also like to use this provider and are currently evaluating if we can.

---

@redeux Do you know if @koikonom is still maintaining this repo, there have been a few open PR's for a while now and the profile for @koikonom seems to indicate no hashicorp contributions since April/May, when the PR's stopped merging. Maybe @aareet knows?

#53 (comment)

Latest real change was over a year ago 67b4dfd

Is this provider still alive?

---

We would also like if we can use a linux container to run terraform with this provider.

Does this provider only run on windows or can it run on mac/linux?

#53 (comment)

@redeux, we are experiencing the problems described in the issue #113. We are interested in understanding if we can consider Linux equivalent to windows from a coverage, testing and support point of view. Currntly it appears that the Linux build is less stable than the Windows one.

We prefer using Linux because it is simpler to deploy or run in containers. For this reason we run all of our terraform based atomations in Linux and we would like to include automation of the AD, without having to migrate everything to Windows. If you want more details about our use cases we can arrange a call.

#53 (comment)

I found these comments which would indicate that:

Hello! Our goal is for the provider to work on all platforms terraform is expected to run. If there's something wrong that doesn't work on Linux then we'll figure out a way to make it work. [...]

#113 (comment)

Hello @Kronk74 ,

It doesn't have anything to do with powershell.exe.
As long as your winrm client (regardless of the os) can authenticate to the remote server it should work as it's the remote server (domain controller/ server with rsat installed) that will execute the cmd "powershell.exe -command ..." [...]

#98 (comment)

But why does the requirements than list a windows server? Because it is in the Terraform Registry documentation for the provider does it means the provider has to be executed on this os? Or does it have something to do with on what the AD/DC runs?

Requirements:
 - Windows Server 2012R2 or greater.
 - WinRM enabled.

terraform-provider-ad/docs/index.md

Line 12 in 7e28235

Requirements:

https://registry.terraform.io/providers/hashicorp/ad/0.4.4/docs

When using linux is the Double hop Authentication required like (linux runs terraform with ad provider) -> (windows server) -> (AD/DC)

Unfortunately I am only familiar with terraform and not with AD so I assume I don't understand it correctly.

[jku-sr]

I've resisted using this provider since it appears abandoned at this point. Some PR's are hitting their anniversary dates and they include a lot of large fixes

[gramsa49]

I use this provider. It does seem the maintainers have stopped maintaing it, but it does work.

@MarkRKar the provider does work from a Linux server, but it requires that intermediate servers running Windows be used for the provider to communicate with the AD DCs. These intermediate servers need to be joined to the domain and have WinRM enabled/configured. I believe this is because Microsoft does things where they don't open the APIs for integration purposes. It seems that most things related to managing Active Directory are not available on any platform outside Windows.

[FranckSallet]

Hi @redeux

Has this project been abandoned or will new releases be released?

Regards

[ThaVip3r]

1. Clone original repo

$ git clone https://github.com/hashicorp/terraform-provider-ad.git
$ cd terraform-provider-ad/

2. Pull "must have" patches (I want to thanks users who created these patches 👍)

$ git remote add bmhughes https://github.com/bmhughes/terraform-provider-ad.git
$ git pull bmhughes ad-user-name
$ git pull bmhughes fix-user-password-never-expires

$ git remote add hanneshayashi https://github.com/hanneshayashi/terraform-provider-ad.git
$ git pull hanneshayashi additional-group-attributes

$ git remote add shubhambjadhavar https://github.com/shubhambjadhavar/terraform-provider-ad.git
$ git pull shubhambjadhavar main

$ git remote add randomswdev https://github.com/randomswdev/terraform-provider-ad.git
$ git pull randomswdev main

3. Build provider as described here
4. Please note that there can be other issues which isn't reported here or fixed using patches above, so use your newly built provider on your own risk

Patches above solved the most of the issues that I have faced during tests but now I found another one - using commas in OU name will lead to the issue with it's distinguishedName due to the escaping backslash in state file after creating OU.

[FranckSallet]

Hi @katbyte

Will the development of the Active Directory provider resume?

Regards