© Brian Beach, Steven Armentrout, Rodney Bozo, Emmanuel Tsouris 2019
B. Beach et al.Pro PowerShell for Amazon Web Serviceshttps://doi.org/10.1007/978-1-4842-4850-8_12

12. AWS Directory Service

Brian Beach1 , Steven Armentrout2, Rodney Bozo3 and Emmanuel Tsouris4
(1)
Raleigh, NC, USA
(2)
Mountlake Terrace, WA, USA
(3)
Sterling, VA, USA
(4)
North Bend, WA, USA
 

In this chapter, we will cover the AWS Directory Service, which is a highly scalable and managed multi-directory store; it can be used for authentication and Single Sign-On services. As mentioned, there are multiple directories supported by AWS Directory Service, each one helping solve a unique business problem, including authentication services for traditional applications, support for SaaS application developers, and cloud applications with complex authentication relationships. The directories available include Amazon Cloud Directory, AD Connector, Amazon Cognito, Simple AD, and Microsoft AD. As one can imagine, each of these directories has enough depth, nuance, and complexity to warrant a dedicated chapter in this book. However, in this section we will focus on the services that are most frequently used with Microsoft Workloads and managed with PowerShell; these are Microsoft AD, AD Connector, and Simple AD.

In this section we will guide you choose the right directory for your use case, as well as provide you with step-by-step instructions on how to get started with authentication and federation using these directories. The exercises at the end of the chapter will spend time deploying, configuring, and securing Microsoft AD, AD Connector, and Simple AD.

Selecting the Right Directory

As previously mentioned, AWS Directory Service has different options and selecting the right directory for your specific use case and business need is very important, as the wrong choice can result in compatibility problems or expensive rework. To help you make the right choice for your project or workload, we will review specifics of each directory.

AWS Directory Service for Microsoft Active Directory

AWS Directory Service for Microsoft Active Directory is a managed service that leverages an actual Microsoft Windows Server Active Directory (AD) infrastructure (Windows Server 2012 R2). As it does on premises, Managed Microsoft AD plays a critical role for Active Directory-aware applications in the AWS Cloud. Some of these applications include Microsoft SQL Server, Microsoft SharePoint, as well as a myriad of .NET applications. AWS Directory Service for Microsoft Active Directory, also known as Managed Microsoft AD, provides directory services for other AWS applications including Amazon WorkSpaces, Amazon QuickSight, and services such as RDS for SQL Server, Amazon Connect, and Amazon Chime.

If there is a requirement to have Active Directory- or LDAP-based directory services for a workload, AWS Managed Microsoft AD tends to be the right choice. There are additional benefits to using this directory option, including US Health Insurance Portability and Accountability Act (HIPAA) and Payment Card Industry Data Security Standard (PCI DSS) compliance eligibility, ability to extend the Active Directory schema, support for Secure LDAP access to the directory, AWS Single Sign-On, and Multi-Factor (MFA) authentication.

AD Connector

The AD Connector is a proxy service that provides on-premises based Active Directory users, access to AWS Enterprise applications, including QuickSight, WorkSpaces, WorkDocs, WorkMail, and Chime. Additionally, the service can also be used to provide seamless domain join to EC2 instances located in your VPC, with requirements being appropriate network connections and a service account to connect to the on-premises domain.

There are additional benefits the AD Connector can provide customers, including the ability to provide Multi-Factor Authentication (MFA) using an existing RADIUS implementation, provide AWS Console access using on-premises credentials, and also continue to leverage your existing domain’s security policies, such as password policies.

Simple AD

Simple AD is a fully Managed Microsoft Active Directory compatible directory, which is powered by Samba 4 and provides the ability to use Active Directory features such as users and groups, machine domain join for both Windows and Linux, group policies, LDAP access, and Kerberos-based authentication.

If your use case is to provide your users authentication service to access AWS applications, including Amazon WorkSpaces, Amazon WorkDocs, Amazon QuickSight, and Amazon WorkMail, and perhaps Simple Active Directory functionality, then Simple AD may be the right choice, especially if you’re price conscious. Currently, the cost for running a Small deployment of Simple AD is about half of what it costs to run a Standard Edition deployment of Managed Microsoft AD.

Managed Microsoft AD Architecture

Managed Microsoft AD is designed for high availability and is deployed in at least two subnets, in two different availability zones (AZs). At deployment time, the subnets can be explicitly selected or the service can randomly select two subnets. These subnets will be used to host two domain controllers (DCs), each of which will receive an IP address from the subnets specified. Once the directory is created, for greater resiliency, additional DCs can be added to either new or existing availability zones.

The aforementioned subnets can either be part of an existing VPC or a new VPC; VPC must use default hardware tenancy. In addition to a VPC, there is also a requirement to create a security group, which will allow the DCs to communicate with each other. The security group will be automatically created and attached to Managed Microsoft AD during directory creation. Let’s begin by configuring the VPC.

Prerequisites

To create a Managed Microsoft AD directory, there are some prerequisites that must be considered:

  • AWS created security group.

  • Default tenancy is required for the VPC hosting Managed Microsoft AD.

  • Directory cannot be created in a VPC using network address range 198.19.0.0/16.

  • Network Address Translation with Active Directory is not supported.

Creating a VPC

To create a Managed Microsoft AD directory, we must first configure a VPC to host the domain controllers in separate subnets. Alternatively, these subnets can be placed in existing VPCs (e.g., the VPC created in Chapter 5). For demonstration purposes, we will create a new VPC in the 192.168.0.0 private IP range.

The following line will create a new VPC and store the details in a variable:
$VPC = New-EC2Vpc -CidrBlock '192.168.0.0/16'

We will continue by creating two subnets in the newly created VPC. For resiliency, these subnets will be in two separate AZs, which is a requirement for the service. (If necessary, review Chapter 5, as we have done this before.)

Creating Private Subnets

The first two variables, delimited with a $, will store the details of the newly created availability zones and will be used when creating the new subnets.
$AvailabilityZone1 = 'us-east-1a'
$AvailabilityZone2 = 'us-east-1b'
$FirstSubnet = New-EC2Subnet -VpcId $VPC.VpcId -CidrBlock '192.168.5.0/24' -AvailabilityZone $AvailabilityZone1
$SecondSubnet = New-EC2Subnet -VpcId $VPC.VpcId -CidrBlock '192.168.6.0/24' -AvailabilityZone $AvailabilityZone2

Creating a Managed Microsoft AD Directory

Once the VPC and the subnets are created, we can move onto setting up the Managed Microsoft AD directory to the subnets.

The following line will create a new domain, with the fully qualified domain name (FQDN) of corp.example.com, a NetBIOS name of CORP, a short description, with the networking settings to use the subnets previously created.
New-DSMicrosoftAD -Name corp.example.com –ShortName corp –Password 'password' -Edition Standard –Description "Managed Microsoft AD" -VpcSettings_VpcId $VPC.VpcID VpcSettings_SubnetId $FirstSubnet.SubnetId, $SecondSubnet.SubnetId

Note

Never use “password” as a password. Please choose something complex and difficult to guess.

The previous command includes the minimum set of the parameters required to set up a Managed Microsoft AD directory into a VPC. These commands are

  • New-DSMicrosoftAD creates the directory.

  • Name is the fully qualified domain name used for the directory created, which can be accessed within the VPC.

  • ShortName is the NetBIOS name and will also be the name of the delegated OU created for your directory.

  • Description is the freeform text used to identify the directory.

  • Password is the password used for the Admin account, which is the delegated administrator account used to manage the directory.

  • Edition is used to set the edition for the directory, either Standard or Enterprise. The Standard Edition is recommended for small and medium size organizations with an estimated 5000 users or 30,000 directory objects. The Enterprise Edition is targeted for large enterprises and can support up to 100,000 users or 500,000 objects.

  • VpcSettings_VpcId is used to identify the VPC where the directory will be set up.

  • VpcSettings_SubnetId is used to specify the two subnets where the domain controllers will be deployed. The subnets must be in two separate availability zones, which are used to provide high availability for the service. Once the directory is set up, additional domain controllers can be provisioned for greater resiliency.

Creating Public Subnet

To manage the new Managed Microsoft AD directory, we will need to set up a public subnet and a Remote Desktop Gateway (RDGW), the latter will serve as an administration workstation.

The first step will be to create a new subnet, which will be public.
$AvailabilityZone3 = 'us-east-1c'
$PublicSubnet = New-EC2Subnet -VpcId $VPC.VpcId -CidrBlock '192.168.100.0/24'-AvailabilityZone $AvailabilityZone3

Creating Internet Gateway

Once the subnet has been created, the next step is to create an Internet gateway and associating it with the previously created VPC.

The following script will create an Internet gateway and attaching it with the VPC previously created.
$InternetGateway = New-EC2InternetGateway
Add-EC2InternetGateway -InternetGatewayId $InternetGateway.InternetGatewayId -VpcId $VPC.VpcID

After the Internet gateway is attached to the VPC, we must make sure the local traffic stays local and traffic intended for the Internet is routed to the Internet gateway as a default route.

Configuring VPC Routing

The next script will create a new routing table, associate it with the VPC we have been working with, and set the default route to use the Internet gateway.
$Route = New-EC2RouteTable -VpcId $VPC.VpcID
Register-EC2RouteTable -RouteTableId $Route.RouteTableId -SubnetId $PublicSubnet.SubnetId
New-EC2Route -RouteTableId $Route.RouteTableId -DestinationCidrBlock '0.0.0.0/0' -GatewayId $InternetGateway.InternetGatewayId

Configuring DNS Hostname Name Resolution

Next, to have DNS name resolution, we will enable DNS Hostnames for the VPC.
Edit-EC2VpcAttribute -VpcId $VPC.VpcId -EnableDnsHostnames $true

Creating Management Workstation

In order for administrators to connect to the administration workstation (i.e., RDGW), we must make sure there is a security group in place before the management instance is deployed. To create the security group with the appropriate inbound rules, we will run the following commands.

Note

It is recommended the inbound IP ranges are more restrictive than in the example provided.

The script that follows will create a security group to allow inbound Remote Desktop connections via port TCP 3389 to the management workstation.
$SecurityGroup = New-EC2SecurityGroup -GroupName RDGW -Description "Remote Desktop access from Internet" -VpcId $VPC.VpcID
$RDPRule = New-Object Amazon.EC2.Model.IpPermission
$RDPRule.IpProtocol='tcp'
$RDPRule.FromPort = 3389
$RDPRule.ToPort = 3389
$RDPRule.IpRanges = '0.0.0.0/0'
Grant-EC2SecurityGroupIngress -GroupId $SecurityGroup -IpPermissions $RDPRule

Once the security group rules are set up, the remote desktop instance can be deployed; we will use the latest version of the Windows Server 2016 Base image (ami-2d360152).

With the following line, we will deploy an EC2 Instance, granting it a public IP address and associating the security group we just created to it.
$RDPInstance = New-EC2Instance -ImageId ami-2d360152 -MinCount 1 -MaxCount 1 -KeyName 'key' -AssociatePublicIp $true -SecurityGroupId $SecurityGroup -InstanceType t2.medium -SubnetId $PublicSubnet.SubnetId

Configuring Management Workstation

Once the management instance is deployed, in order to connect to it, we will get the IP address and password of the instance from the AWS Console. See Figures 12-1 and 12-2.
../images/319650_2_En_12_Chapter/319650_2_En_12_Fig1_HTML.jpg
Figure 12-1

Running EC2 Instance from within the EC2 Console

../images/319650_2_En_12_Chapter/319650_2_En_12_Fig2_HTML.jpg
Figure 12-2

Connection information for accessing the EC2 Instance

Once we get the Public DNS name of the administration instance, as shown in Figure 12-1, we will right-click the instance and use the Connection information to connect to it using the Remote Desktop client. See Figure 12-3.
../images/319650_2_En_12_Chapter/319650_2_En_12_Fig3_HTML.jpg
Figure 12-3

Example of the Remote Desktop connection client

Joining EC2 Instance to the Domain

Once connected, we will change the DNS settings of the administration instance to point to the Managed Microsoft AD’s domain controller’s IP addresses. In order to do this, we can either go to the AWS Console (Figure 12-4) to get the information or run the command shown in the next section (i.e. Add-Computer -Credential CORPadmin-DomainName corp.example.com -Restart):
../images/319650_2_En_12_Chapter/319650_2_En_12_Fig4_HTML.jpg
Figure 12-4

Managed Microsoft AD details from the Directory Service Console

The line that follows will provide details of the Active Directory domain we will use in the chapter. We will first get the details of our domain and input them into the $Directory variable (Figure 12-5). Then, we will output the details of the variable.
$Directory = Get-DSDirectory -DirectoryID d-906711f2bb
../images/319650_2_En_12_Chapter/319650_2_En_12_Fig5_HTML.jpg
Figure 12-5

Active Directory domain details

The IP addresses of the domain controllers will be listed in the DNsIPAddrs section of the output.

Once connected to the management workstation/administration instance, we will need to ensure we configure the machine to use the right network interface card to join the domain. To set the IP address on the administration instance, we will need to identify the network interface that will get the DNS servers setting.

The next command will locate the active Ethernet network interface on the server.
Get-NetIPAddress | Where-Object {$_.InterfaceIndex -eq 3}
If the command does not yield any results, run the command without the filter (e.g., {$_.InterfaceIndex -eq 3}) and locate the active network interface on the public subnet. See Figure 12-6 .
Get-NetIPAddress
../images/319650_2_En_12_Chapter/319650_2_En_12_Fig6_HTML.jpg
Figure 12-6

Depicts Ethernet network card needed to be configured

Once the network interface has been located, run the following command:
Set-DnsClientServerAddress -InterfaceAlias "Ethernet 2" -ServerAddresses 192.168.5.33, 192.168.6.181
Alternatively, the changes can be made by right-clicking Start and selecting Network Connections and setting the DNS server settings manually. Additional information can be found in the “Manually Join a Windows Instance” documentation page https://docs.aws.amazon.com/directoryservice/latest/admin-guide/join_windows_instance.html . See Figure 12-7.
../images/319650_2_En_12_Chapter/319650_2_En_12_Fig7_HTML.jpg
Figure 12-7

Example of how to configure DNS manually

Once the DNS settings have been updated, we will use the following command to join the administration instance to the CORP domain.
Add-Computer -Credential CORPadmin -DomainName corp.example.com -Restart
When prompted, type the appropriate password and click the OK button (Figure 12-8). At this point, the instance will reboot as part of the domain join process.
../images/319650_2_En_12_Chapter/319650_2_En_12_Fig8_HTML.jpg
Figure 12-8

Authentication prompt required to join Corp domain

Install AD Tools

Once restarted, reconnect using the Remote Desktop client with the CORPadmin account. At this point, we will install the required AD administration tools to manage the directory. To do this, run the following command.

The command installs the Active Directory Windows Server Administration Tools.
Add-WindowsFeature RSAT-AD-Tools
Once the AD Tools are fully installed, go to Start/Run and type DSA.MSC. See Figure 12-9. This will open the Active Directory Users and Computes Snap-In, which can be used to manage the resources in the domain, including user and computer objects and so on. See Figure 12-10.
../images/319650_2_En_12_Chapter/319650_2_En_12_Fig9_HTML.jpg
Figure 12-9

Launching Active Directory Users and Computers Management Console

../images/319650_2_En_12_Chapter/319650_2_En_12_Fig10_HTML.jpg
Figure 12-10

Corp domain depicted via Active Directory Users and Computers Management Console

Additional information can be found in the “Installing the Active Directory Administration Tools” documentation page https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_install_ad_tools.html .

Delegation Model

Because Managed Microsoft AD is a managed service, with a similar delegation model to RDS, customers don’t get Domain or Enterprise Administrator access to the directory; therefore, we need to acknowledge some key details about the directory configuration.

Creating a Managed Microsoft AD Domain will result in the creation of a delegated Organizational Unit (OU), with the NetBios name that was specified during domain creation. For example, in our case the NetBios name was CORP. Under the delegated OU, there are a couple of other OUs, which are intended for computers and users. See Figure 12-11.

Along with the deleted OU, there are a set of security groups created to delegate privileges for the routine operational tasks and activities, required to manage domain resources for an organization. Some of these operational tasks include resetting password and unlocking accounts, joining machines to a domain , managing and configuring domain services such as DNS and DHCP, and deploying and administering licensing and certificate services. For a complete list of delegation security groups and their description, visit the “What Gets Created” documentation page https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_what_gets_created.html .

../images/319650_2_En_12_Chapter/319650_2_En_12_Fig11_HTML.jpg
Figure 12-11

Delegation security groups for the domain we created

As part of providing support services, AWS retains ownership of an OU called AWS Reserved . In this OU resides the administrator account, as well as security groups designated for support purposes; these include the AWSAdministrators and AWS Application and Service Delegated Group security groups. See Figure 12-12.
../images/319650_2_En_12_Chapter/319650_2_En_12_Fig12_HTML.jpg
Figure 12-12

View of Active Directory domain created

Add Additional Domain Controller

One of the common tasks for Managed Microsoft AD administrators is to add additional domain controllers to the domain for additional resiliency and performance. In this section, we will increase the number of domain controllers in the domain.

The following script will add an additional domain controller to the previously deployed directory.
Set-DSDomainControllerCount -DesiredNumber 3 -DirectoryID $Directory.DirectoryId
The list as follows explains in detail the command shown earlier:

  • Set-DSDomainControllerCount specifies the action that the command will execute, in this case is either add or remove domain controllers to the directory.

  • DesiredNumber specified the number of desired domain controllers in the directory.

  • DirectoryId identifies the directory that will get the additional domain controllers, or removal of DCs if appropriate.

Once the command is run, we can verify the number of domain controllers via the AWS Directory Service Console. See Figure 12-13. The “How to Increase the Redundancy and Performance of Your AWS Directory Service for Microsoft AD Directory by Adding Domain Controllers” blog is highly recommended for additional information ( https://aws.amazon.com/blogs/security/how-to-increase-the-redundancy-and-performance-of-your-aws-directory-service-for-microsoft-ad-directory-by-adding-domain-controllers/ ).
../images/319650_2_En_12_Chapter/319650_2_En_12_Fig13_HTML.jpg
Figure 12-13

List of additional domain controller being created

Create a Snapshot

Once the directory is operational, it is critical to make sure that backups are regularly taken. The following command will create a manual snapshot of the directory. There is a limit of five manual snapshots for the directory; once the limit is reached, one of the snapshots must be deleted in order to create any others. There are also daily automatic snapshots that are taken; these are in addition to the manual snapshot limit. Once a directory is deleted, all snapshots associated with that directory will be deleted and cannot be recovered.

The following line creates a manual snapshot of the directory, naming the snapshot “1stManualSnapshot”. See also Figure 12-14.
New-DSSnapshot -DirectoryId $Directory.DirectoryId -Name 1stManualSnapshot
../images/319650_2_En_12_Chapter/319650_2_En_12_Fig14_HTML.jpg
Figure 12-14

Image of manual snapshot being created

Note

Manual snapshots are highly recommended to be taken prior to any major directory change, such as extending the schema.

Restore a Snapshot

If you have an issue with the data integrity of your directory, a snapshot can be restored from either a manual or automatic snapshot.

The line that follows will restore the manual snapshot previously created:
Restore-DSFromSnapshot -SnapshotId s-906560c8e8

Note

A snapshot restore does a point-in-time restore of the entire directory, which means there is risk of data loss. Therefore, it is highly recommended that before a snapshot is restored, a support case is created from the AWS Support Center to request assistance with restoring the individual object(s) that may be in question.

Enable Single Sign-On

As previously mentioned in the beginning of the chapter, Managed Microsoft AD can also be leveraged to provide access to the AWS Enterprise applications. In this section, we will discuss the way to grant directory users access to WorkDocs using Single Sign-On; however, one of the requirements is the Creation of an Access URL. Currently, the process of creating an Access URL can only be via the AWS Console. Once the Access URL is created, the Single Sign-On can be configured using the commands in the following sections:

Creating an Access URL

An Access URL can be created by following the next steps. See also Figure 12-15.
  1. 1.

    Go to the AWS Directory Service Console and select the appropriate directory.

     
  2. 2.

    Go to the Directory details and select the Application Management tab.

     
  3. 3.

    In the directory alias field, enter the alias appropriate for your organization. In our case, the one selected is corpex.awsapps.com.

     
../images/319650_2_En_12_Chapter/319650_2_En_12_Fig15_HTML.jpg
Figure 12-15

Enabling Application access URL

Enabling Single Sign-On

The following command provides any machine joined to the domain, access to Amazon WorkDocs, without having to enter credentials separately:
Enable-DSSso -DirectoryId $Directory.DirectoryId -Username admin -Password 'password'

Disabling Single Sign-On

If required, Single Sign-On can be disabled by running the following command:
Disable-DSSso -DirectoryId $Directory.DirectoryId -Username admin -Password 'password'

Enabling AWS Apps and Services

Once the Access URL has been created, other AWS Apps and Services can be enabled to integrate with Managed Microsoft AD. Currently, enabling these services can only be performed via the AWS Console. Detailed documentation for enabling these services can be found in the Enable Access to AWS Application and Services documentation page: https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_apps_services.html .

  • Amazon WorkSpaces

  • Amazon WorkSpaces Application Manager

  • Amazon WorkDocs

  • Amazon WorkMail

  • Amazon QuickSight

  • Amazon Connect

  • RDS SQL Server

  • AWS Management Console

Enable Multi-Factor Authentication

Multi-Factor Authentication (MFA) is a mechanism that can be used to increase the security posture of your Microsoft Managed AD workloads, including Amazon Enterprise applications, such as WorkDocs, WorkSpaces, QuickSight, and Single Sign-On to the AWS Console. One of the requirements for enabling MFA is either having an MFA plugin or a Remote Authentication Dial-In User Service (RADIUS), which can be located either in your VPC or on-premises. In this scenario, the RADIUS server would authenticate users via username and one-time passcode. Step-by-step instructions and additional information can be found in the “How to Enable Multi-Factor Authentication for AWS Services by Using AWS Microsoft AD and On-Premises Credentials” blog ( https://aws.amazon.com/blogs/security/how-to-enable-multi-factor-authentication-for-amazon-workspaces-and-amazon-quicksight-by-using-microsoft-ad-and-on-premises-credentials/ ).

The following script will enable RADIUS for your Active Directory domain previously created:
Enable-DSRadius -DirectoryId $Directory.DirectoryId -RadiusSettings_AuthenticationProtocol <RadiusAuthenticationProtocol> -RadiusSettings_DisplayLabel <String> -RadiusSettings_RadiusPort <Int32> -RadiusSettings_RadiusRetry <Int32> -RadiusSettings_RadiusServer <String[]> -RadiusSettings_RadiusTimeout <Int32> -RadiusSettings_SharedSecret <String> -RadiusSettings_UseSameUsername <Boolean> -PassThru <SwitchParameter> -Force <SwitchParameter>

Disable Multi-Factor Authentication

The Multi-Factor Authentication server can be removed by running a command to disable RADIUS from the directory.
Disable-DSRadius -DirectoryId Directory.DirectoryId

Reset Admin Password

In some cases, there may be a need to change a user’s password, and more importantly there may be a need to change the Admin password. If necessary, the following command will reset the password for the Admin password in the working directory:
Reset-DSUserPassword -Username Admin -DirectoryID $Directory.DirectoryId -NewPassword 'password'
The following list of parameters decomposes the command:

  • Reset-DSUserPassword is the action to change the password for any user in the directory.

  • Username specifies the username that will get a new password.

  • DirectoryID identifies the directory where the user is located.

  • NewPassword sets new password for the user.

Create a Trust Relationship

If there is a need for customers to access resources that belonged to the Managed Microsoft AD using their on-premises credentials, there may be a need to create a forest trust between Managed Microsoft AD or on-premises directories. The forest trust grants access of AWS-based resources to users in a remote forest. To create the trust, the following command can be run to configure the forest trust. The command creates the forest trust between your Managed Microsoft AD and your on-premises domain.
New-DSTrust -DirectoryId $Directory.DirectoryId -ConditionalForwarderIpAddr 172.16.1.153 -RemoteDomainName onprem.corporate.local -TrustDirection OneWayOutgoing -TrustPassword ‘password’ -TrustType Forest

There is an extensive list of prerequisites for creating the trust; these include network connectivity for specific network ports, a user account for creating a trust, and conditional forwarders to route the authentication requests properly. To get a complete list of prerequisites, review the “Create a Trust Relationship Between Your AWS Managed Microsoft AD and Your On-Premises Domain” ( https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_setup_trust.html ) documentation.

Approve Trust Relationship

Once the forest trust actions have been put in motion, these must be manually approved to running using the commands in the following section:

The command that follows approves the trust previously created:
Approve-DSTrust -TrustId <String>

Remove a Trust Relationship

An existing forest trust can be deleted by running the following command:
Remove-DSTrust -TrustId <String> -DeleteAssociatedConditionalForwarder $true

Deleting the Managed Microsoft AD Directory

Once a Managed Microsoft AD directory is no longer needed, the following command can be used to delete the directory. This command will eliminate all components of the directory, including domain objects and domain controllers:
Remove-DSDirectory -DirectoryId $Directory.DirectoryId

AWS Created Security Group

When a directory is set up, a security group is created to provide communication between the domain controllers and the client machines in EC2 and RDS. The description of the security group should read like the following “AWS created security group for d-xxxxxx directory controllers”. This security group is also associated with the network interfaces the domain controllers are using to connect to the assigned subnets. The default ports configured in the security group are the following (subject to change):

  • TCP/UDP 53 – DNS

  • TCP/UDP 88 – Kerberos authentication

  • UDP 123 – NTP

  • TCP 135 – RPC

  • UDP 137–138 – Netlogon

  • TCP 139 – Netlogon

  • TCP/UDP 389 – LDAP

  • TCP/UDP 445 – SMB

  • TCP 636 – LDAPS (LDAP over TLS/SSL)

  • TCP 873 – Rsync

  • TCP 3268 – Global catalog

  • TCP/UDP 1024–65535 – Ephemeral ports for RPC

It is recommended that the default ports of this security group are reviewed and if necessary adjusted to meet your organization’s security policy.

AD Connector

Another component part of the AWS Directory Service is the AD Connector, which is a proxy service that can be used to redirect authentication requests to your on-premises Microsoft Active Directory, eliminating the need to have to extend your directory or move data to the cloud. The connector is intended to be used with AWS applications such as Amazon WorkSpaces, Amazon WorkDocs, or Amazon WorkMail. It can also be used to provide your on-premises users access to the AWS Console, leveraging existing credentials and user account and password policies. The AD Connector can also integrate with RADIUS-based Multi-Factor Authentication services to increase the security posture of your AWS applications. The AD Connector also provides the ability to perform EC2 Instance seamless domain join, which can programmatically join instances to the domain during deployment.

Note

If you need authentication services for Windows-based applications, Managed Microsoft Active Directory is recommended.

AD Connector Prerequisites

To deploy the AD Connector, the following prerequisites must be met:

  • VPC with at least two subnets, each in a separate availability zone.

  • The VPC must be configured in default hardware tenancy.

  • Network connectivity between the on-premises site, where Active Directory is hosted, and the VPC.

  • On-premises Active Directory domain must be in Windows Server 2003 functional level or higher.

  • Service account on the on-premises domain, with the following permissions:

    • Read users and computers

    • Create computer objects

    • Join computers to the domain

  • Firewall policies allowing inbound communication to the on-premises network, from the VPC, over the following network ports:

    • TCP/UDP 53 – DNS

    • TCP/UDP 88 – Kerberos authentication

    • TCP/UDP 389 – LDAP

  • Kerberos pre-authentication must be enabled.

Creating AD Connector

To create an AD Connector, we will use the VPC and subnets we used in the “Managed Microsoft AD” section of this chapter. See Figure 12-16. We will also mimic the on-premises setup by connecting to the Managed Microsoft AD directory instead of a domain located in your corporate network.

The command that follows will connect AD Connector to Managed Microsoft AD.
Connect-DSDirectory -Name corp.example.com -Password 'password' -ConnectSettings_CustomerDnsIp 192.168.5.33,192.168.6.181 -ConnectSettings_CustomerUserName admin -Description "AD Connector" -ShortName CORP -Size Small -ConnectSettings_SubnetId subnet-05873b56385adc497, subnet-098883977cc4701bf -ConnectSettings_VpcId vpc-0e7632d32bdd1ced6
The following are the parameters used in the command just completed:

  • Connect-DSDirectory is the action to create a new AD Connector.

  • Name corp.example.com is the fully qualified name of the directory that will be connected to AD Connector.

  • Password is the password for the service account used for the AD Connector.

  • ConnectSettings_CustomerDnsIp is for the IP address or addresses of the domain controllers of the on-premises directory.

  • ConnectSettings_CustomerUserName is the name service account for the AD Connector; it must have the right level of privileges to access the on-premises domain.

  • Description is the freeform text description of the AD Connector.

  • ShortName is the NetBIOS name of the on-premises directory.

  • Size specifies the size of the AD Connector; values can be either Small or Large.

  • ConnectSettings_SubnetId are the subnet IDs to be used with the AD Connector. Two subnets in separate availability zones must be specified.

  • ConnectSettings_VpcId is the name of the VPC that is hosting the preceding two subnets listed.
    ../images/319650_2_En_12_Chapter/319650_2_En_12_Fig16_HTML.jpg
    Figure 12-16

    AD Connector being created

Deleting AD Connector

If you no longer need the AD Connector or if you are moving to using Managed Microsoft AD, then the directory can be removed. In order to do this, we will run the commands in the next section:

Because we didn’t store the newly created AD Connector into a variable, what we will do is add the directory object into a variable. To do this, we will run the following command:
$ADConnector = Get-DSDirectory | where-object {($_.Type -like '*Connector
*')}
Once we have the $ADConnector variable storing the right object, then we well run the following command to permanently remove the AD Connector from your AWS account:
Remove-DSDirectory -DirectoryId $ADConnector.DirectoryId

Simple AD

Simple AD is a managed directory, which is an Active Directory (AD)-compatible service, and allows for many applications and workloads that require AD to use Simple AD in place of full-blown Active Directory. Examples of these applications include AWS applications, such as Amazon WorkSpaces, Amazon WorkDocs, and Amazon WorkMail.

As part of the managed offering, Simple AD provides backup and recovery services, with daily automated snapshots, with point-in-time recovery. High availability, monitoring, and maintenance are also included as part of the managed service.

Creating Simple AD

To launch and manage a new Simple AD directory, we will follow the networking requirements outlined in the “Microsoft AD” section. This includes creating the VPC, subnets, routing configuration, and the management workstation.

Prerequisites

As with the two other directory offerings, Simple AD requires that you have a VPC with multiple subnets, each associated with a separate availability zone for resiliency. Hardware tenancy for the VPC must also be set to default or shared.

Creating a VPC

One of the requirements for hosting Simple AD, the same as Microsoft AD and the AD Connector, is networking. To move forward, what we must do is first create and configure a VPC with separate subnets and place directory controllers in each one of these subnets, which should be in different availability zones for high availability. These subnets can also reside in an existing VPC, such as the VPC created in Chapter 5 or the one created earlier in this chapter. For completeness, we will create a new VPC in the 10.0.0.0 private IP range.
$SimpleADVpc = New-EC2Vpc -CidrBlock '10.0.0.0/16'

We will continue by creating two subnets in the newly created VPC. As it is always best practice, these subnets should be in separate AZs for resiliency and is a service requirement.

Creating Private Subnets

These sets of commands will create two availability zones with two separate subnets. We will also save the newly created objects into variables we will use in the rest of the chapter.
$AvailabilityZone1 = 'us-east-1a'
$AvailabilityZone2 = 'us-east-1b'
$FirstSubnet = New-EC2Subnet -VpcId $SimpleADVpc.VpcId -CidrBlock '10.0.1.0/24' -AvailabilityZone $AvailabilityZone1
$SecondSubnet = New-EC2Subnet -VpcId $SimpleADVpc.VpcId -CidrBlock '10.0.2.0/24' -AvailabilityZone $AvailabilityZone2

Creating Public Subnet

To manage the new Managed Microsoft AD directory, we will need to set up a public subnet and a Remote Desktop Gateway (RDGW), the latter will serve as an administration workstation.

The first step will be to create a new subnet, which will be public.
$AvailabilityZone3 = 'us-east-1c'
$PublicSubnet = New-EC2Subnet -VpcId $SimpleADVpc.VpcId -CidrBlock '10.0.0.0/24'-AvailabilityZone $AvailabilityZone3

Creating Internet Gateway

Once the subnet has been created, the next step is to create an Internet gateway and associating it with the previously created VPC.
$InternetGateway = New-EC2InternetGateway
Add-EC2InternetGateway -InternetGatewayId $InternetGateway.InternetGatewayId -VpcId $SimpleADVpc.VpcID

Configuring VPC Routing

After the Internet gateway is attached to the VPC, we must make sure the local traffic stays local and traffic intended for the Internet is routed to the Internet gateway as a default route.

The script that follows will create a new route table and add a default route:
$Route = New-EC2RouteTable -VpcId $SimpleADVpc.VpcID
Register-EC2RouteTable -RouteTableId $Route.RouteTableId -SubnetId $PublicSubnet.SubnetId
New-EC2Route -RouteTableId $Route.RouteTableId -DestinationCidrBlock '0.0.0.0/0' -GatewayId $InternetGateway.InternetGatewayId

Configuring DNS Hostname Name Resolution

Next, to have DNS name resolution, we will enable DNS Hostnames for the VPC:
Edit-EC2VpcAttribute -VpcId $SimpleADVpc.VpcId -EnableDnsHostnames $true

Creating a Simple AD

To create a Simple AD directory, we need to take the various prerequisite components previously created and use them when running during the directory creation. To do this, we will execute the following PowerShell command:
$SimpleAD = New-DSDirectory -Name corp.example.com -Password 'password' -Description "Simple AD" -ShortName CORP -Size Small -VpcSettings_SubnetId $FirstSubnet.SubnetId,$SecondSubnet.SubnetId -VpcSettings_VpcId $SimpleADVpc.VpcId

Note

Never use “password” as a password. Please choose a more complex password.

The previous command includes the minimum set of the parameters required to set up a Simple AD directory into a VPC. These commands are

  • New-DSDirectory creates the directory.

  • Name is the fully qualified domain name used for the directory created, which can be accessed within the VPC.

  • ShortName is the NetBIOS name for your directory.

  • Description is the freeform text used to identify the directory.

  • Password is the password used for the administrator account used to manage the directory. It is important not to lose this password, as it cannot be retrieved or reset. If this occurs, you will not be able to add objects to the directory.

  • Size is used to set the edition for the directory, either Small or Large. The Small is recommended organizations that will have a maximum of 500 users and 2000 directory objects, including users, groups, and computers. Large supports up to 5000 users and approximately 20,000 objects.

  • VpcSettings_VpcId is used to identify the VPC where the directory will be set up.

  • VpcSettings_SubnetId is used to specify the two subnets where the domain controllers will be deployed. The subnets must be in two separate availability zones, which are used to provide high availability for the service. Once the directory is set up, additional domain controllers can be provisioned for greater resiliency.

Creating Management Workstation

To administer Simple AD, we need a management workstation (i.e., RDGW), where we will have the tools to manage the directory. We will first create the security group to associate with management workstation. Note: It is recommended the inbound IP ranges are more restrictive than in the example provided.

The script that follows will create security group configure a policy to allow port 3389 (the Remote Desktop Protocol (RDP)) from the Internet to the management workstation:
$SecurityGroup = New-EC2SecurityGroup -GroupName RDGW -Description "Remote Desktop access from Internet" -VpcId $SimpleADVpc.VpcID
$RDPRule = New-Object Amazon.EC2.Model.IpPermission
$RDPRule.IpProtocol='tcp'
$RDPRule.FromPort = 3389
$RDPRule.ToPort = 3389
$RDPRule.IpRanges = '0.0.0.0/0'
The next command, will allow outbound access from the management workstation to the world.
Grant-EC2SecurityGroupIngress -GroupId $SecurityGroup -IpPermissions $RDPRule

Once the security group rules are set up, the remote desktop instance can be deployed; we will use the latest version of the Windows Server 2016 Base image (ami-2d360152).

The command that follows will deploy a new instance using a T2.Medium instance type and associate the security group we just created it:
$RDPInstance = New-EC2Instance -ImageId ami-2d360152 -MinCount 1 -MaxCount 1 -KeyName 'key' -AssociatePublicIp $true -SecurityGroupId $SecurityGroup -InstanceType t2.medium -SubnetId $PublicSubnet.SubnetId

Configuring Management Workstation

Once the management instance is deployed, in order to connect to it, we will get the IP address and password of the instance from the EC2 Console, where we will right-click the instance we just created and select Get Windows Password. See Figure 12-17.
../images/319650_2_En_12_Chapter/319650_2_En_12_Fig17_HTML.jpg
Figure 12-17

Management workstation connectivity information

Once we get the Public DNS name of the administration instance, we will use the Remote Desktop client to connect to it. See Figure 12-18.
../images/319650_2_En_12_Chapter/319650_2_En_12_Fig18_HTML.jpg
Figure 12-18

Remote Desktop client view

Joining EC2 Instance to the Domain

Once connected, we will change the DNS settings of the administration instance to point to the Simple AD’s domain controller’s IP addresses. See Figure 12-19. To get the DNS IP addresses, we can either go to the AWS Console or run output the contents of variable $SimpleAD.
../images/319650_2_En_12_Chapter/319650_2_En_12_Fig19_HTML.jpg
Figure 12-19

DNS IP address details

If the variable is empty, you can repopulate it by running the following command:
$SimpleAD = Get-DSDirectory -DirectoryId d-906710bc74

The IP addresses of the domain controllers will be listed in the DnsIPAddrs section of the output, as shown in Figure 12-19.

To change the DNS settings on the management workstation, we will need to identify the network interface that will get DNS servers setting. To get the specific network address, we will run the following set of commands:

The next command will locate the active Ethernet network interface on the server:
Get-NetIPAddress | Where-Object {$_.InterfaceIndex -eq 3}
If the command does not yield any results, run the command without the filter and locate the active network interface on the public subnet.
Get-NetIPAddress
Once the network interface has been located, run the following command to set the DNS servers to the Simple AD authentication servers:
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 10.0.1.44, 10.0.2.248
Alternatively, the changes can be made by right-clicking Start and selecting Network Connections and setting the DNS server settings manually. See Figure 12-20. Additional information can be found in the “Manually Join a Windows Instance” documentation page ( https://docs.aws.amazon.com/directoryservice/latest/admin-guide/join_windows_instance.html ).
../images/319650_2_En_12_Chapter/319650_2_En_12_Fig20_HTML.jpg
Figure 12-20

DNS server configuration

Once the DNS settings have been updated, we will use the following command to join the management workstation/administration instance to the CORP domain:
Add-Computer -Credential CORPadministrator -DomainName corp.example.com -Restart
When prompted, type the appropriate password and click the OK button. See Figure 12-21. At this point, the instance will reboot as part of the domain join process. You can use this same process to join additional machines to the domain.
../images/319650_2_En_12_Chapter/319650_2_En_12_Fig21_HTML.jpg
Figure 12-21

Authentication prompt

Install AD Tools

Once restarted, reconnect using the Remote Desktop client with the CORPadministrator account. We will then need to install the required AD administration tools to manage the directory. To do this, run the following command. The command will install the Active Directory Users and Computers Management Console.
Add-WindowsFeature RSAT-AD-Tools
Once the AD Tools are fully installed, go to Start/Run and DSA.MSC. This will open the Active Directory Users and Computes Snap-In, which can be used to manage the resources in the domain, including user and computer objects and so on. See Figure 12-22.
../images/319650_2_En_12_Chapter/319650_2_En_12_Fig22_HTML.jpg
Figure 12-22

Active Directory Users and Computers Snap-In

Additional information can be found in the “Installing the Active Directory Administration Tools” documentation page ( https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_install_ad_tools.html ).

AWSAdminD-xxxxxxx

When the Simple AD directory is created, there will be an administrator account created, used by the service to perform various automated maintenance operations. This account should not be disturbed, as it may impact service availability. See Figure 12-23.
../images/319650_2_En_12_Chapter/319650_2_En_12_Fig23_HTML.jpg
Figure 12-23

AWSAdminD-XXXXX account

Create a Snapshot

As with Managed Microsoft AD, backups are critical to ensure there is an ability to recover from human error or any other unexpected event. The following command will create a manual snapshot of the directory. There is a limit of five manual snapshots for the directory; once the limit is reached, one of the snapshots must be deleted in order to create any others. There are also daily automatic snapshots that are taken, which are in addition to the manual snapshot limit. Once a directory is deleted, all snapshots associated with that directory will be deleted and cannot be recovered.

The command that follows will create a manual snapshot of the recently created Simple AD directory. Also see Figure 12-24.
New-DSSnapshot -DirectoryId $SimpleAD.DirectoryId -Name 1stManualSnapshot
../images/319650_2_En_12_Chapter/319650_2_En_12_Fig24_HTML.jpg
Figure 12-24

View of snapshot being taken

Note

Manual snapshots are highly recommended to be taken prior to any major directory change.

Restore a Snapshot

If you have an issue with the data integrity of your directory, a snapshot can be restored from either a manual or automatic snapshot.

The command that follows will restore the directory from a snapshot:
Restore-DSFromSnapshot -SnapshotId s-90655b5c66

Note

A snapshot restore does a point-in-time restore of the entire directory, which means there is risk of data loss.

Enable Single Sign-On

As with Managed Microsoft AD, Simple AD can be used to grant users in your organizations access to AWS Enterprise applications. In this section, we will configure your directory’s users access to WorkDocs using Single Sign-On; however, one of the requirements is the Creation of an Access URL. Currently, the process of creating an Access URL can only be via the AWS Console. Once the Access URL is created, the Single Sign-On can be configured using the commands in the following section.

Creating an Access URL

An Access URL can be created by following these steps:
  1. 1.

    Go to the AWS Directory Service Console and select the appropriate directory.

     
  2. 2.

    Go to the Directory details and select the Application Management tab.

     
  3. 3.
    In the Application access URL, click the Create button (Figure 12-25).
    ../images/319650_2_En_12_Chapter/319650_2_En_12_Fig25_HTML.jpg
    Figure 12-25

    Enable Application access URL

     
  4. 4.
    When we get the popup, we will enter excorpo.awsapps.com (Figure 12-26).
    ../images/319650_2_En_12_Chapter/319650_2_En_12_Fig26_HTML.jpg
    Figure 12-26

    Configuring custom Application access URL

     
  5. 5.
    Once the URL has been created, we will be able to enable Single Sign-On to AWS applications for the directory (Figure 12-27).
    ../images/319650_2_En_12_Chapter/319650_2_En_12_Fig27_HTML.jpg
    Figure 12-27

    Enabled Application access URL

     

Enabling Single Sign-On

The following command provides any machine joined to the domain, access to Amazon WorkDocs, without having to enter credentials separately:
Enable-DSSso -DirectoryId $SimpleAD.DirectoryId -Username administrator -Password 'passwor'

Disabling Single Sign-On

If required, Single Sign-On can be disabled by running the following command:
Disable-DSSso -DirectoryId $SimpleAD.DirectoryId -Username administrator -Password 'password'

Enabling AWS Apps and Services

Once the Access URL has been created, the following AWS Apps and Services can be enabled to integrate with Simple AD. Currently, enabling these services can only be performed via the AWS Console. Detailed documentation for enabling these services can be found in the Enable Access to AWS Application and Services documentation page ( https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_apps_services.html ).

  • Amazon WorkSpaces

  • Amazon WorkSpaces Application Manager

  • Amazon WorkDocs

  • Amazon WorkMail

  • Amazon QuickSight

  • Amazon Connect

  • RDS SQL Server

  • AWS Management Console

Enable Multi-Factor Authentication

Simple AD can also be configured to use Multi-Factor Authentication (MFA). One of the requirements for enabling MFA is either having an MFA plugin or a Remote Authentication Dial-In User Service (RADIUS), which can be located either in your VPC or on-premises. In this scenario, the RADIUS server would authenticate users via username and one-time passcode. Step-by-step instructions and additional information can be found in the “How to Enable Multi-Factor Authentication for AWS Services by Using AWS Microsoft AD and On-Premises Credentials” blog ( https://aws.amazon.com/blogs/security/how-to-enable-multi-factor-authentication-for-amazon-workspaces-and-amazon-quicksight-by-using-microsoft-ad-and-on-premises-credentials/ ).

The command that follows will enable RADIUS for Simple AD; parameters for the settings used will be specific to the RADIUS solution being used.
Enable-DSRadius -DirectoryId $SimpleAD.DirectoryId -RadiusSettings_AuthenticationProtocol <RadiusAuthenticationProtocol> -RadiusSettings_DisplayLabel <String> -RadiusSettings_RadiusPort <Int32> -RadiusSettings_RadiusRetry <Int32> -RadiusSettings_RadiusServer <String[]> -RadiusSettings_RadiusTimeout <Int32> -RadiusSettings_SharedSecret <String> -RadiusSettings_UseSameUsername <Boolean> -PassThru <SwitchParameter> -Force <SwitchParameter>

Disable Multi-Factor Authentication

The Multi-Factor Authentication server can be removed by running a command to disable RADIUS from the directory.
Disable-DSRadius -DirectoryId $SimpleAD.DirectoryId

Deleting Simple AD Directory

If the directory is no longer needed, it can be removed from your AWS account using the following PowerShell command. This will permanently delete the entire directory.
Remove-DSDirectory -DirectoryId $Simple.DirectoryId

AWS Created Security Group

When a directory is set up, a security group is created to provide communication between the domain controllers and EC2 instances. The description of the security group should read like the following “AWS created security group for d-xxxxxx directory controllers”. This security group is also associated with the network interfaces the domain controllers are using to connect to the assigned subnets. The default ports configured in the security group are the following (subject to change):

  • TCP/UDP 53 – DNS

  • TCP/UDP 88 – Kerberos authentication

  • UDP 123 – NTP

  • TCP 135 – RPC

  • UDP 137–138 – Netlogon

  • TCP 139 – Netlogon

  • TCP/UDP 389 – LDAP

  • TCP/UDP 445 – SMB

  • TCP 636 – LDAPS (LDAP over TLS/SSL)

  • TCP 873 – Rsync

  • TCP 3268 – Global catalog

  • TCP/UDP 1024–65535 – Ephemeral ports for RPC

It is recommended that the default ports of this security group are reviewed and, if necessary, adjusted to meet your organization’s security policy.

Application Compatibility

Because Simple AD is running Samba under the covers, it provides the basic features of Active Directory. If you have a third-party application, which requires advanced Active Directory features, Simple AD may not be a good fit. It is recommended that thorough testing is performed to ensure your third-party application will have no issues. Microsoft services and server applications compatible with Simple AD include IIS, SharePoint, and SQL Server.

Exercise 12.1: Create Domain User in Microsoft AD

In this section, we will install and use the Active Directory PowerShell module.

To begin, we will go to the management workstation used for managing the Microsoft AD directory. We will then import the Active Directory module, so we can begin our exercise.

Open PowerShell and run the following command:
Import-Module ActiveDirectory
Once successfully imported, we use PowerShell to create new domain user and set the title and e-mail address.
New-ADUser -Name "Bob Smith" -OtherAttributes @{'title'="CEO";'mail'="[email protected]"}
Once the user is created, we will need to enable the user. However, we won’t be able to do that because the account does not have a password set. We will first set a password for the AD account.
$NewPassword = (Read-Host -Prompt "Provide New Password" -AsSecureString)
Set-ADAccountPassword -Identity 'Bob Smith' -NewPassword $NewPassword -Reset
Once the password is set, we can then enable the user in the directory.
Enable-ADAccount -Identity "Bob Smith"

Once the user is enabled, it can be used to authenticate to directory resources, assuming the user has been granted privileges to access those resources.

To get a full understanding of the user attributes that can be set when creating an account and also the commands used in this exercise, review the following articles on the Microsoft documentation sites: New-ADUser ( https://docs.microsoft.com/en-us/powershell/module/addsadministration/new-aduser?view=win10-ps ), Set-ADAccountPassword ( https://docs.microsoft.com/en-us/powershell/module/addsadministration/set-adaccountpassword?view=win10-ps ), and Enable-ADAccount ( https://docs.microsoft.com/en-us/powershell/module/addsadministration/enable-adaccount?view=win10-ps ).

Summary

In this chapter, we saw how AWS Directory Service can be used to centralize access and resource management using Managed Microsoft AD, AD Connector, and Simple AD. We also saw how existing on-premises credential can be used to access resources hosted on the AWS Cloud.

Throughout the chapter, we created directories, configured multi-factor authentication, created forest trust between on-premises directories and Managed Microsoft AD, and finally used the AD Connector and Simple AD to grant on-premises users access to AWS applications, such as WorkDocs. As we saw, there are multiple options for access and resource management. It is important to understand how each one option works and what it was designed to do, so you can select the one that fits your use case. Of course, you can always mix and match if your use case justifies the need.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset