Validate compatibility with AWS Directory Service

aareet commented 4 years ago

Description

[ ] Check if the provider is compatible with AWS Directory Service (https://aws.amazon.com/directoryservice/)
[ ] If it is, create an example to demonstrate to users how to quickly set up AD with AWS and use this provider to manage it
[ ] If it is, add acceptance test coverage to cover this usage

References

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/directory_service_directory

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

koikonom commented 3 years ago

AWS provides two Directory services. Unfortunately the provider will not work at all with the "Basic Directory" service, because it's essentially a managed Samba instance. The other service they provide is the "Managed AD" service which is a managed Active Directory cluster. The problem with this one is that it does not come with WinRM enabled, nor does it allow you to enable it.

tomwerneruk commented 3 years ago

I am currently evaluating this provider, like you say @koikonom Managed AD is effectively a blackbox. My solution so far is to use a companion EC2 administration host (which is AWS recommended for operational use anyway).

koikonom commented 3 years ago

Hi @tomwerneruk, This is what I was thinking to try next. I just don't know if the powershell commands the provider runs will work "as is" or if they require any changes (Such as add a -ComputerName parameter or something).

bart-parka commented 3 years ago

I too am trying to get this to work with AWS Managed AD and a separate admin host. I believe I have managed to connect via Kerberos authentication but am now facing the following error:

`Error: command Get-ADUser exited with a non-zero exit code 1, stderr: #< CLIXML

System.Management.Automation.PSCustomObjectSystem.Object1Preparing modules for first use.0-1-1Completed-1 1Preparing modules for first use.0-1-1Completed-1 ~~Get-ADUser : Unable to contact the server. This may be because this server does not exist, it is currently down, or it _x000D__x000A_does not have the Active Directory Web Services running._x000D__x000A_At line:1 char:1_x000D__x000A_+ Get-ADUser -identity "S-1-5-21-3057401248-2679340083-1116673353-1286" ..._x000D__x000A_+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~_x000D__x000A_~~ ~~+ CategoryInfo : ResourceUnavailable: (S-1-5-21-305740...1116673353-1286:ADUser) [Get-ADUser], ADServerDo _x000D__x000A_~~ ~~wnException_x000D__x000A_~~ ~~+ FullyQualifiedErrorId : ActiveDirectoryServer:0,Microsoft.ActiveDirectory.Management.Commands.GetADUser_x000D__x000A_~~ ~~_x000D__x000A_~~` Update: I have logged in as my user and opened up a Powershell session to confirm I have access to AD tools so I presume the problem is something to do with opening up a remote PS session and that not having necessary permissions. Update: I confirmed above by opening a remote powershell session (authenticated by Kerberos) to the admin host. When running AD cmdlets I get the same error. Update: I managed to progress further by allowing for Kerberos credential delegation on the admin host machine. This means I can now open a remote PS session and run AD cmdlets normally. This still doesn't work from my local macbook when running the ad-provider so it might mean that I have to join my local machine to the domain (I can get a Kerberos ticket as I'm on the network but not part of the domain). I believe this could also be solved by passing an extra -Credential param to the AD cmdlets running on the admin host (this is probably insecure though) Final update: I added my local machine to the domain and allowed for credential delegation - still no luck. I wonder if the issue is somewhere in the underlying krb5 go library or its implementation here. Final Final update: Only just saw this comment on the other thread: https://github.com/hashicorp/terraform-provider-ad/issues/53#issuecomment-762507375. This seems to confirm without solving the double-hop problem this provider will not be compatible with AWS managed AD.

Type1J commented 3 years ago

I would like to run this provider from my laptop, which is not in the AWS private network. The typical way to get into a VPC network isn't by VPN; it's by ssh or RDP through a bastion host. From the bastion host, which is joined to the domain, the provider could get access to the AD controller, but not with WinRM.

Are there plans to make this work? I would imagine that whatever solution is used for AWS Managed AD would work with other cloud providers.

SkUrRiEr commented 3 years ago

For future reference (mostly mine) the canonical way to manage AWS Managed Microsoft AD services is using RSAT: https://docs.aws.amazon.com/directoryservice/latest/admin-guide/microsoftadbasestep3.html (see the last step which essentially combines other Install-WindowsFeature commands elsewhere in the documentation) which is also the canonical way to manage Samba AD-DC servers from Windows. https://wiki.samba.org/index.php/Installing_RSAT (The Powershell command in the AWS documentation and the dism command in the Samba documentation are functionally equivalent)

So if we can update this provider to be able to be configured to talk the appropriate RSAT protocols, we should be able to manage AWS Managed AD servers and Samba AD-DC servers assuming we can get single-hop access.

Type1J commented 3 years ago

It would probably be a safe bet that if you're modifying the AD, then you have AD credentials. If there needs to be a hop, then a bastion server that's running ssh (which could be locked to only talk to the internal network and a few trusted IPs) that is joined to the domain and could start an ssh tunnel using AD credentials could be assumed to exist in some hop scenarios. The credentials may be separate from the AD credentials as well, if a general solution is desired.

Basically, what I just said is like many database GUI clients that have an option to do ssh tunneling before talking to the database instead of directly opening a connection to the database.

Type1J commented 3 years ago

@SkUrRiEr I agree, the provider should speak a protocol that the AWS Managed AD understands. It may be that the RSAT actually uses WinRM.

SkUrRiEr commented 3 years ago

@Type1J, my understanding is that RSAT (which I think refers to the Tools on Windows, not the actual protocol) pre-dates WinRM. I'd expect that the Powershell management commands (e.g. Get-ADUser) communicate with the AD server on Windows using the same protocol as the RSAT tools.

Type1J commented 3 years ago

@SkUrRiEr I hope so. Is the protocol documented?

koikonom commented 3 years ago

Hello,

Since WinRM connectivity on an AWS managed DC is not possible we would have to somehow work through an intermediate host. Since this has been requested a few times now I've opened a new issue to discuss about it.

I would love to hear your thoughts on https://github.com/hashicorp/terraform-provider-ad/issues/99 .

koikonom commented 3 years ago

Quick update on this issue. Starting with version v0.4.3 it is now possible to use most of the provider's functionality with the AWS managed AD service by leveraging the "double hop" authentication method. See this section in the provider docs that explains how double hop authentication is expected to work.

Pending work:

The GPO related functionality will not work. This is still work in progress.

shubhambjadhavar commented 3 years ago

Can you provide an documentation with steps to configure this provider to manage AWS Managed Active Directory Remotely?

hashicorp / terraform-provider-ad