Note: Please go to docs.rightscale.com to access the current RightScale documentation set. Also, feel free to Chat with us!
Home > ServerTemplates > Infinity > ST > Microsoft Active Directory (v14 Infinity) > Microsoft Active Directory (v14 Infinity) - Tutorial

Microsoft Active Directory (v14 Infinity) - Tutorial

 

Table of Contents    

Infinity

Leading edge features

    ►  Tutorial

Objective

Launch a Windows Active Directory (AD) primary domain controller and associated additional domain controllers in the cloud.

Note: Currently, this ServerTemplate only supports the following clouds: AWS EC2, Windows Azure, and Rackspace Open Cloud. (Note: Rackspace Performance Cloud Servers are not supported.)

Prerequisites

The following are prequisites for completing this tutorial:

  • Required user roles: actor, library
  • Either valid AWS credentials or Windows Azure credentials associated with the RightScale account

Overview

In this tutorial, the "primary domain controller" denotes the Windows domain controller with operations master roles (also known as flexible single master operations or FSMO roles) assigned. As described in the Microsoft documentation, when the first domain controller in a domain is installed, the installation assigns it all "operations master" roles.

To learn more about the technical details of the ServerTemplate, see Microsoft Active Directory (v13 Infinity).

Create Credentials

It's recommended that you create the following credentials before you start configuring the server. For more information on setting up credentials, see Create a New Credential.

  • WINDOWS_ADMIN_PASSWORD - Password for the local Windows administrator account on a domain controller. It will also serve as the password for the Windows domain user account, which is used to install Active Directory Domain Services.
  • SAFE_MODE_PASSWORD - Password for the administrator account when the domain controller is started in Safe Mode or a related variant such as Directory Services Restore Mode (DSRM).
  • AD_ADMIN_PASSWORD - Password for the user with Active Directory 'administrator' privileges (AD_ADMIN_ACCOUNT) that's used to install Active Directory Domain Services. User must have Active Directory privileges. 


If you are setting up a DNS record for the Active Directory server, create credentials for the login information that's required to update a record with your DNS provider.

  • DNS_USER* - Username that's used to log into your DNS provider and access your DNS records.
  • DNS_PASSWORD* - Password for DNS_USER.

* If you use Amazon Route 53 as your DNS provider, you do not need to set up separate DNS user name and password credentials because your AWS credentials are used for authentication purposes. 

Steps

Create a Security Group

Required for clouds that support security groups. (e.g. AWS EC2)

Set up an EC2 security group (in the region where you are going to launch the Active Directory server) with the following permissions. See Create a New EC2 Security Group. For an example, see this screenshot. For demonstration purposes, you can use the "group" option to allow all incoming connections to all ports in range 0..65535 for all instances having this security group. If you prefer to create more restrictive port-specific rules, see Active Directory and Active Directory Domain Services Port Requirements.

You should also add firewall rules to open the ports below to any IP unless you already have a separate security group (with these permissions) that you can use instead.

  • TCP:3389  (Required for RDP access)
  • TCP:80  (Required for HTTP access. If you are going to create a DNS record that points to the Active Directory server, open TCP port 80.)
  • TCP:443  (Required for HTTPS access.)

Important!
When you add a server to the deployment in the next step, be sure to select this security group.

Add a Server

Follow these steps to add a Microsoft Active Directory server to the deployment.

  1. Go to the MultiCloud Marketplace (Design > MultiCloud Marketplace > ServerTemplates) and import the most recently published revision of the following ServerTemplate into the RightScale account.
    • Microsoft Active Directory Server - Beta (v14.x)   <<<Add MCM link once ST is published. Currently privately shared only>>>
  2. From the imported ServerTemplate's show page, click the Add Server button.
  3. Select the cloud for which you will configure a server. 
  4. Select the deployment into which the new server will be placed.
  5. Next, the Add Server Assistant wizard will walk you through the remaining steps that are required to create a server based on the selected cloud.
    • Server Name - Provide a nickname for your new load balancer server (e.g. Windows AD). 
    • Select the appropriate cloud-specific resources that are required in order to launch a server into the chosen cloud. The required cloud resources may differ depending on the type of cloud infrastructure. If the cloud supports multiple datacenters / zones, select a specific zone. Later, when you create the other load balancer server you will use a different datacenter / zone to ensure high-availability. For more information, see Add Server Assistant.
  6. Click Confirm, review the server's configuration and click Finish to create the server.

Configure Inputs

The next step is to define the properties of your server by entering values for inputs. As a best practice, you should define required inputs for the servers at the deployment level. For a detailed explanation of how inputs are defined and used in Chef recipes and RightScripts, see Inputs and their Hierarchy.

To configure inputs for the scripts that will run on your server, open the deployment's Inputs tab, click Edit, and use the following settings to configure input values. It's recommended that you set up credentials for password values and any other sensitive data as shown in the examples.

ACTIVE DIRECTORY

Input Name Description Example Value
AD_ADMIN_PASSWORD The local administrator and domain administrator password. cred: AD_ADMIN_PASSWORD
AD_DOMAIN_NAME This is fully qualified Active Directory domain name for this server. (Example: mydomain.local) text: mydomain.local
AD_NETWORK_INTERFACE Use this input to specify which network interface should be used for network communication between domain controllers and member servers. The recommended option is to use private interface. (Example: text:private) cred: AD_ADMIN_PASSWORD
AD_SAFE_MODE_ADMIN_PASSWORD

Administrator's account password for safe mode. This password is used for disaster recovery of Active Directory. It's strongly recommended that you use a RightScale Credential (Design > Credentials) to hide the actual password from non-admin users while still allowing them to pass the appropriate value as an input. 

cred: AD_SAFE_MODE_ADMIN_PASSWORD
AD_RESTORE_MODE Indicates whether this server will be restored from System State backup. Set this input to 'false' if you're going to set up an Active Directory from scratch. (Default = false)  text: false

BACKUP

Input Name Description Example Value
AD_LINEAGE_NAME

A string that is used to track all Active Directory backups in a certain 'set', usually deployment wide. If the server is locked, then you will not be able to take a backup. 

text: my_lineage_name

AD_BACKUP_VOLUME_SIZE Used to specify the size in GB of the Active Directory backup volume.  text: 100

CLOUD

Input Name Description Example Value
AWS_ACCESS_KEY_ID

The Access Key ID is an Amazon Access Credential that's used to authenticate your requests to AWS services. It's unique to your AWS Account Number. The Access Key ID and Secret Access Key are used to retrieve objects from an S3 bucket that are 'private'. Log into your AWS account at aws.amazon.com to retrieve your access identifiers. It's strongly recommended that you use a RightScale Credential (Design > Credentials) to hide the actual key value from non-admin users while still allowing them to pass the appropriate value as an input. Ex: 1JHQQ4KVEVM02KVEVM02

cred: AWS_ACCESS_KEY_ID

AWS_SECRET_ACCESS_KEY The Secret Access Key is an Amazon Access Credential that's used to authenticate your requests to AWS services. It's unique to your AWS Account Number. The Access Key ID and Secret Access Key are used to retrieve objects from an S3 bucket that are 'private'. Log into your AWS account at aws.amazon.com to retrieve your access identifiers. It's strongly recommended that you use a RightScale Credential (Design > Credentials) to hide the actual key value from non-admin users while still allowing them to pass the appropriate value as an input. Ex: XVdxPgOM4auGcMlPz61IZGotpr9LzzI07tT8s2Ws cred: AWS_SECRET_ACCESS_KEY

DNS

If you are not using a DNS record to point to the primary Active Directory server, leave these inputs unset.

Input Name Description Example Value
DNS_DOMAIN_NAME

FQDN of the DNS record to be updated. This input is used for DynDNS, Rackspace Cloud DNS, Route53. Set to "text:" and leave blank to bypass DNS registration on boot. Ex: my.domain.com

text: ad.example.com

DNS_ID ID of DNS record or zone to be updated. This input has specific meaning for each DNS provider: DNS Made Easy: 7-digit DNS record ID provided by DNS Made Easy. Ex: 1234123 DynDNS: not used Rackspace Cloud DNS: ID of record in DNS domain to be updated. To find out the ID you could run this script with empty value for DNS_ID input. Ex: 123456 Route53: ID of Route53 zone of the record to be updated. Ex: Z1BINKNIEY8Y9L Set to "text:" and leave blank to bypass DNS registration on boot. text: 1234567
DNS_IP_ADDRESS IP address to update the DNS record. Type a specific IP address or select whether to use the instance's public or private IP address. Set to "text:" and leave blank to bypass DNS registration on boot. Ex: 1.2.3.4 text: private
DNS_PASSWORD

Password or authentication key that is used to access and modify DNS records. It's recommended that you use credentials to hide the actual password value. (Example: DNS_PASSWORD)

Provider-specific details:

  • DNS Made Easy: Password of your DNS Made Easy account
  • DynDNS: Password of your DynDNS account
  • Rackspace Cloud DNS: Rackspace API authentication key. (Ex: cred:RACKSPACE_AUTH_KEY)
  • Amazon Route53: Your AWS Secret Access Key. (Ex: cred:AWS_SECRET_ACCESS_KEY)
cred: DNS_PASSWORD
DNS_SERVERS

Comma-separated list of DNS servers to set for specified network interface. Example: text:8.8.8.8,192.168.0.2

text: 8.8.8.8,192.168.0.2
DNS_SERVICE One of the supported DNS providers: DNS Made Easy, DynDNS, Rackspace Cloud DNS (US and UK regions), Route53. Please use predefined value and don't override the dropdown. text: 3
DNS_USER Username or account ID that is used to access and modify DNS records. Provider-specific details: DNS Made Easy: Username of your DNS Made Easy account: Ex: mydnsacct DynDNS: Username of your DynDNS account. Ex: mydnsacct Rackspace Cloud DNS: Username of your Rackspace account. Ex: cred:RACKSPACE_USERNAME Route53: Your AWS Access Key ID. Ex: cred:AWS_ACCESS_KEY_ID Set to "text:" and leave blank to bypass DNS registration on boot.

 

cred: DNS_USER

SYSTEM

Input Name Description Example Value
ADMIN_PASSWORD

Set the new password for the local Administrator account on the domain controller. The password must satisfy Window's minimum requirements for a Windows administrator password, otherwise the random password that is generated for you at boot time (located under the server's Info tab,'Initial Admin Password' field) will be used instead. The password should be at least 7 characters long with at least one upper case letter, one lower case letter and one digit. 

When you RDP into the server, you will use this password to log in as the Windows 'Administrator' user.

It's strongly recommended that you use a credential to hide this value. However, anyone who needs to log into the server will need to know the actual value.

Note: Once the server is operational, you can use the AD Change Administrator password operational script to change the value.

cred: WINDOWS_ADMIN_PASSWORD

SYS_WINDOWS_TZINFO

Sets the system timezone to the timezone specified, which must be a valid Windows timezone entry. You can find a list of valid examples in "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones". Some examples have been provided in the dropdown, which you may override if you do not see your timezone listed.

It's strongly recommended that you use, "GMT Standard Time" (Greenwich Mean Time).

text: GMT Standard Time
ADMIN_ACCOUNT_NAME Used only if setting up an additional (non-primary) domain controller, this is the Windows domain user account used to install Active Directory Domain Services. This account must have Active Directory administrator permissions. This input is also used for transferring FSMO roles as well. text: administrator

Click Save.

Launch the Server

Once all of the inputs are configured, you are ready to launch the server.

  1. Go to the deployment's Servers tab and launch the server. When you view the input confirmation page, there should not be any required inputs with missing values. If there are any required inputs that are missing values (highlighted in red), cancel the launch and add the missing values at the deployment level before launching the server again. Refer to the instructions in Launch a Server if you are not familiar with this process. Because there are no required inputs that are missing values for any boot scripts, you can click the Launch button at the bottom of the input confirmation page. 

    Important!
    Because the AD Create a Directory Controller boot script requests a server restart (reboot), the domain controller server will temporarily enter the "decommissioning" state before it becomes "operational." Refer to the Audit Entries tab for details. (See screenshot.) 

Note: It's not uncommon to experience launch times that exceed 2 hours.

screen_Primary-1.png

Set the Backup Policy

Run the following operational script to create a scheduled Windows task to create a periodic backup of the database. You will need to run the script on each server that you want to configure for periodic backups. So, if you have a Primary and Additional AD server, you should run the script on each server. It's recommended that you run the script at the server level (and not the deployment level) so that you can set up backup policies with different backup policies. For example, you might want the backups to be offset from each other.

  1. Go to the Scripts tab of the the primary server.
  2. Run the AD DS Configure backup policy (v14.x) recipe. The applied policy configuration is based on the values set for the AD_BACKUP_KEEP_LAST  and AD_BACKUP_SCHEDULE inputs.

Create a Backup

To manually take a backup of the current state of the Active Directory database, run the AD DS Perform system state backup operational script with appropriate values for the following inputs.

Input Name Description Example Value
AD_LINEAGE_NAME

The Active Directory's lineage name is used to tag the volume snapshots appropriately for identification purposes. (e.g. rs_backup:lineage=ProjectName) Later when you restore the database on a new server, you will specify the lineage name so that the appropriate backup can be properly selected. (e.g. ProjectName)

text: ProjectName

AD_BACKUP_KEEP_LAST The total number of Active Directory backups to keep on backup volume. When this limit has been reached, the oldest backup will be deleted but still could be restored from older snapshots. Default value is 5. Example: text:10 text: 5

Check the backup to make sure that it contains the appropriate tags and is "available" for use before you attempt to use it for a restore task. For example, if you are using AWS, backups are saved as volume snapshots. 

  1. Go to Clouds > EC2-Region > Volume Snapshots.
  2. The snapshot should have a database lineage tag that matches the AD Lineage Name. In the example below, AD_LINEAGE_NAME = vitaly.

​​screen_AD-Backup-Snapshot_v1.png

Launch an Additional Server (Optional)

Clone the existing AD server and launch an additional AD server, if desired. If you are launching the secondary/additional server in a cloud that supports multiple zones, it's recommended that you edit the additional server's configuration to launch into a different zone before you launch it. You do not have to wait for a backup of the primary AD server to be completed and available before you launch the additional AD server because it will use tags to join the existing AD domain when it's launched. 

Once the server is operational, both AD servers should have the same tags. Make sure they both belong to the same AD domain. In the example screenshot below, they are connecting to a local domain (AD_DOMAIN_NAME = rightscale.local). 

screen_Primary-Additional-1.png

Add a Domain Member (Optional)

Now that you have an operational Active Directory setup consisting of either one or two servers, you can now launch a server that will join the AD domain as a member. Fortunately, you can use the standard "Base ServerTemplate for Windows" ServerTemplate to quickly test this functionality because the template contains a script that will connect it to an AD domain. For this reason, it's recommended that you either build custom Windows ServerTemplates by cloning and modifying this base ServerTemplate or import and add the SYS Join AD domain (v14.0) and SYS Leave AD domain (v14.x) RightScripts to your existing Windows ServerTemplates if you want to enable servers to easily connect to an AD server that was launched with the ServerTemplate described above.

  1. Go to the MultiCloud Marketplace (Design > MultiCloud Marketplace > ServerTemplates) and import the most recently published revision of the following ServerTemplate:
  2. Use the ServerTemplate to add a server to the same deployment as the other AD server(s).
  3. Launch the server. (Note: "Administrator" will be used as a default value for the AD_ADMIN_ACCOUNT input if it's unset at launch time. However, the input must match the value specified for the ADMIN_ACCOUNT_NAME input that was set for the AD servers.) 
  4. Once the server becomes operational, execute the SYS Install RightScale Powershell library (v14.x) operational RightScript to satisfy the prerequisites for the subsequent join/leave scripts. Wait for the script to be completed.
  5. Run the SYS Join AD domain (v14.x) operational RightScript. Once the script is completed, check the server's tags to verify that it properly joined the correct AD domain.

screen_Tags-AD_Join_v1.png

Set the Deployment's Tag Scope

If you followed the steps outlined above, the deployment probably had a default tag scope set to 'deployment', which is the default configuration. However, most users will want to set up a deployment specifically for hosting their dedicated Active Directory server(s), which will provide the user database service to all servers in the RightScale account. In such cases, you will need to change the tag scope of the AD deployment. 

  1. Go to the AD deployment's Info tab and click Edit.
  2. Change the Server tag scope to 'account' and click Save.

Post Tutorial Steps

Once you have an operational server you may want to launch an additional domain server, create a backup, enable continuous backups, or connect a remote server. For complete documentation about all the common operational tasks related to this server, please see the Microsoft Active Directory (v13 Infinity) - Runbook.

Once you are finished with your test deployment, terminate the servers.

You must to post a comment.
Last modified
15:07, 20 May 2014

Tags

Classifications

This page has no classifications.

Announcements

None


© 2006-2014 RightScale, Inc. All rights reserved.
RightScale is a registered trademark of RightScale, Inc. All other products and services may be trademarks or servicemarks of their respective owners.