Most of the customers have a Microsoft Active Directory in place which is running in an on-premise data center. The Active Directory builds the foundation for their on-premise infrastructure for managing users, performing their network authentication and authentication to AD-integrated applications such as Microsoft Exchange Server. When AD-aware on-premise workloads are required to be migrated to the cloud, it requires extending AD also on the Cloud in order to build an efficient authentication mechanism.
ACME considers certain AWS and Microsoft best practices to extend on premise Active Directory Services to AWS Cloud.
To extend your existing AD DS into the AWS cloud, you’ll need to extend on premises network to the Amazon VPC. We’ll consider two ways to do this.
Additional Domain Controllers provide a reliable, low latency network connection for resources in AWS that need access to AD DS.
The newly created Windows Server instances are not automatically promoted to domain controllers, so you will need to promote Domain Controller.
You will need to perform the following tasks-
a single Active Directory forest has been extended from an on-premises deployment into an Amazon VPC using a VPN connection. Within the Amazon VPC, additional Domain Controllers configured as Global Catalog and DNS servers are deployed in the existing Active Directory forest.
For example, there will be a site definition that corresponds to the on-premises network, along with a subnet definition for the 192.168.1.0/24 network. The next step is to configure Active Directory Sites and Services to support the network components located in the Amazon VPC.
By properly configuring Active Directory Sites and Services, you can help ensure the AD DS queries and authentication requests that originate from the Amazon VPC are serviced by a local Domain Controller in the same AWS Availability Zone. This configuration reduces network latency and minimizes traffic that may otherwise need to travel across the VPN back to the on -premises infrastructure.
|Protocol and Port||AD and AD DS Usage||Type of traffic|
|TCP 42||If using WINS in a domain trust scenario offering NetBIOS resolution||WINS|
|TCP 135||Replication||RPC, EPM|
|TCP 137||NetBIOS Name resolution||NetBIOS Name resolution|
|TCP 139||User and Computer Authentication, Replication||DFSN, NetBIOS Session Service, NetLogon|
|TCP and UDP 389||Directory, Replication, User and Computer Authentication, Group Policy, Trusts||LDAP|
|TCP 636||Directory, Replication, User and Computer Authentication, Group Policy, Trusts||LDAP SSL|
|TCP 3269||Directory, Replication, User and Computer Authentication, Group Policy, Trusts||LDAP GC SSL|
|TCP and UDP 88||User and Computer Authentication, Forest Level Trusts||Kerberos|
|TCP and UDP 53||User and Computer Authentication, Name Resolution, Trusts||DNS|
|TCP and UDP 445||Replication, User and Computer Authentication, Group Policy, Trusts||SMB, CIFS, SMB2, DFSN, LSARPC, NbtSS, NetLogonR, SamR, SrvSvc|
|TCP 9389||AD DS Web Services||SOAP|
|TCP 5722||File Replication||RPC, DFSR (SYSVOL)|
|TCP and UDP 464||Replication, User and Computer Authentication, Trusts||Kerberos change/set password|
|UDP 123||Windows Time, Trusts||Windows Time|
|UDP 137||User and Computer Authentication||NetLogon, NetBIOS Name Resolution|
|UDP 138||DFS, Group Policy, NetBIOS Netlogon, Browsing||DFSN, NetLogon, NetBIOS Datagram Service|
|UDP 67 and UDP 2535||DHCP (Note: DHCP is not a core AD DS service but these ports may be necessary for other functions besides DHCP, such as WDS)||DHCP, MADCAP, PXE|