PART 2: Configuring Windows and Linux Servers for CMU Testing

Posted in: Technical Track

This is the second in a four-part article series related to testing Oracle Database 18c Centrally Managed Users (CMU) by leveraging the Oracle Cloud Infrastructure (OCI) for Oracle DBAs to create a lab or testbed. The first article covered how to create a CMU testbed.

Using OCI and the commands provided in this article series, Oracle DBAs can quickly and easily set up all required infrastructure including components such as domain-joined servers and an Active Directory domain controller (DC) without requiring assistance from their Windows Administrator colleagues.

So, while this article does reference numerous Windows and Linux administrative commands, it is intended for use by the Oracle DBA.

For Oracle DBAs, having “command-based” setup instructions is probably more reliable and simpler to follow than providing a series of screenshots. Consequently, this article details the Active Directory domain setup and configuration via PowerShell commands (to be run on the OCI-hosted Windows servers). Of course, configuring Windows components through the associated GUIs (such as Windows Server Manager) is an alternative.

Having the testbed Linux and Windows application servers join the Active Directory domain isn’t required for basic CMU password (“directory synchronization”) testing but will be required if/when testing CMU Kerberos authentication. Since having these test servers join the domain is relatively simple, the process is included in this article.

Infrastructure Validation

The first thing to do is to validate the OCI created in the previous article is available and running. There should be four servers listed and running.

As per the previous article, the OCI CLI commands shown here are in Windows PowerShell format. Adjusting to run from a MacOS or Linux Bash shell should be relatively simple and mostly involves removing leading “$”s from variable declarations and changing line continuation markers from “`” to “\”. Additionally, Bash requires the “echo” command adjustments to display variable values.

OCI CLI commands:

# Extract the compartment OCID:
$COMP_OCID=$(oci iam compartment list `
                --query "data[?`"name`"=='CMU_TESTBED'].{id:id}" `
                --all `
             | jq -r '.[]."id"' `

# List all instances in the compartment:
oci compute instance list `
   --compartment-id $COMP_OCID `
   --query "data[*].{name:\`"display-name\`",state:\`"lifecycle-state\`",id:id}" `
   --output table

Sample output:

PS > # Extract the compartment OCID:
PS > $COMP_OCID=$(oci iam compartment list `
>>                 --query "data[?`"name`"=='CMU_TESTBED'].{id:id}" `
>>                 --all `
>>              | jq -r '.[]."id"' `
>>             )
PS >
PS > # List all instances in the compartment:
PS > oci compute instance list `
>>    --compartment-id $COMP_OCID `
>>    --query "data[*].{name:\`"display-name\`",state:\`"lifecycle-state\`",id:id}" `
>>    --output table
| id                                                                                  | name      | state   |
| ocid1.instance.oc1.phx.anyhqljtcty5iiycmxago4o24r7msvnhryncbtsl7q3je5l5du4xdgmbxpoq | APPLINUX1 | RUNNING |
| ocid1.instance.oc1.phx.anyhqljtcty5iiycd24v67rapvi6pwwwg6arsufwk6u75lo32ez7buydunlq | APPWIN1   | RUNNING |
| ocid1.instance.oc1.phx.anyhqljtcty5iiyclci7tvd4fno6alyhgrwmfv7e5cf3cguzaxy4obpydnoa | DBSERV1   | RUNNING |
| ocid1.instance.oc1.phx.anyhqljtcty5iiycasmpzf7aznestwabbmp7bfqbcuygumf6wnoku4z6qbfa | DC1       | RUNNING |
PS >

If any are not started, they can be started using a command such as:

oci compute instance action --action START --instance-id ocid1.instance.oc1.phx.anyhqljtcty5iiyclci7tvd4fno6alyhgrwmfv7e5cf3cguzaxy4obpydnoa

To remotely access via SSH or RDP, the external (or “public”) IPs of each server must be known. Either record from the OCI web console or from a command such as:

# Show the public IP for one of the VM instances:
oci compute instance list-vnics `
   --instance-id ocid1.instance.oc1.phx.anyhqljtcty5iiyclci7tvd4fno6alyhgrwmfv7e5cf3cguzaxy4obpydnoa `
   --query "data[?\`"is-primary\`"].{name:\`"display-name\`",IP:\`"public-ip\`"}" `
   --output table

Sample output:

PS > # Show the public IP for one of the VM instances:
PS > oci compute instance list-vnics `
>>    --instance-id ocid1.instance.oc1.phx.anyhqljtcty5iiyclci7tvd4fno6alyhgrwmfv7e5cf3cguzaxy4obpydnoa `
>>    --query "data[?\`"is-primary\`"].{name:\`"display-name\`",IP:\`"public-ip\`"}" `
>>    --output table
| IP            | name    |
| | DBSERV1 |
PS >

Internal (or “private”) IPs for each also must be known. Again, these are available from the OCI web console or CLI. For the remainder of this article, it is assumed that the private IPs used in the infrastructure provisioning steps from the previous article are used.

Preparing the Database Server

It makes the most sense to build the database server first. For testing CMU in this testbed, the database server configuration:

  • Is based on a simple “VM.Standard2.1” shaped VM instance, though using a different shape would be fine.
  • Uses the November 2019 Oracle Linux 7 image as the OS.
  • Has no extra block volumes added – using the provided boot volume will suffice.
  • Uses Oracle Database 18c Express Edition (XE) for license simplicity.

Testing with Oracle Database XE makes sense as XE has all Enterprise Edition features without licensing costs (but instead is capacity-constrained). Testing using an OCI “User-managed Database Service” 18c or 19c managed database environment is another possibility. However, CMU is not supported with Oracle Database Standard Edition and further, currently does not work with Oracle Autonomous Database suite of services.

On the database server VM “DBSERV1” created previously, log into the server as “opc” and sudo to the “root” user. Then install the Oracle pre-install RPM using:

curl -o oracle-database-preinstall-18c-1.0-1.el7.x86_64.rpm

yum -y localinstall oracle-database-preinstall-18c-1.0-1.el7.x86_64.rpm

rm -f oracle-database-preinstall-18c-1.0-1.el7.x86_64.rpm

# Update other packages as a good practice:
yum update -y

Then download the Oracle Database XE software from Oracle’s site. Note, Oracle no longer requires you to review and accept the licensing terms and conditions and hence this step can now be automated.

Download the XE software from

Once downloaded and staged (in this example, in the “opc” user’s home directory) on the database server, install with the single simple command:

yum -y localinstall /home/opc/oracle-database-xe-18c-1.0-1.x86_64.rpm

Then create the XE database instance using:

/etc/init.d/oracle-xe-18c configure

And finally, adjust the Linux firewall to allow remote access to the listener port using:

firewall-cmd --permanent --zone=public --add-port=1521/tcp
firewall-cmd --reload

Sample output:

[[email protected] ~]# firewall-cmd --permanent --zone=public --add-port=1521/tcp
[[email protected] ~]# firewall-cmd --reload
[[email protected] ~]#

If you like, test that the XE and, specifically the default pluggable database called XEPDB1, is available:

. oraenv <<< XE

echo "SELECT * FROM dual;" | sqlplus -s -L system/[email protected]//localhost:1521/XEPDB1

Configuring the Active Directory Server and Domain Controller

It makes sense to configure the Active Directory domain controller next (so that other servers can join the domain).

Initial steps:

  1. Using Remote Desktop Client, connect to the DC1 server using the OPC username and the initial password provided in OCI web console.
  2. Change password on initial logon as prompted.
  3. Sign in.
  4. Run PowerShell using the “Run as Administrator” option.

The “Run as Administrator” option can be found by right-clicking on the Start menu icon:

A prerequisite step is to manually set the local Administrator password which is unset by default. From the PowerShell prompt use:

net user Administrator <New Password>

Sample output:

PS C:\Windows\system32> net user Administrator *****
The command completed successfully.

PS C:\Windows\system32>

The initial server build is just a basic server. It needs to have the Active Directory domain server role enabled which is simple enough to do via the following command (the pipe and Out-File argument is optional):

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools | Out-File -FilePath C:\Users\opc\AD_Feature_Install.txt

Sample output:

PS C:\Windows\system32> cd C:\Users\opc\
PS C:\Users\opc>
PS C:\Users\opc> Install-WindowsFeature AD-Domain-Services -IncludeManagementTools | Out-File -FilePath C:\Users\opc\AD_Feature_Install.txt

PS C:\Users\opc>

PS C:\Users\opc> cat .\AD_Feature_Install.txt

Success Restart Needed Exit Code      Feature Result
------- -------------- ---------      --------------
True    No             Success        {Active Directory Domain Services, Group P...

PS C:\Users\opc>

Next, a domain must be created. Use any domain name and top-level domain (TLD) you like. For these examples, we are using STAGECOACH.NET – change to your own value throughout.

To create the Active Directory domain forest, use a command similar to:

Install-ADDSForest -DomainName <Your Domain Name> | Out-File -FilePath C:\Users\opc\AD_Forest_Create.txt


  • The prompt for the “SafeModeAdministratorPassword” is for a new password, not the one specified earlier. Of course, both can be the same if you choose.
  • After the AD domain forest has been created, the server will automatically reboot.
  • It takes about 5 minutes to complete the reboot before the server can be connected again. Trying to log in before it’s done will show the message “Please wait for the Group Policy Client”.
  • It is safe to ignore the various WARNINGs in the command output for the sake of this test environment.
  • Ideally, a static IP address is assigned to the server prior to the AD configuration. This is not required for this OCI testbed.

Sample output:

PS C:\Users\opc> Install-ADDSForest -DomainName STAGECOACH.NET
SafeModeAdministratorPassword: **************
Confirm SafeModeAdministratorPassword: **************

The target server will be configured as a domain controller and restarted when this operation is complete.
Do you want to continue with this operation?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"):
WARNING: Windows Server 2016 domain controllers have a default for the security setting named "Allow cryptography algorithms compatible with Windows NT 4.0" that
 prevents weaker cryptography algorithms when establishing security channel sessions.

For more information about this setting, see Knowledge Base article 942564 (

WARNING: This computer has at least one physical network adapter that does not have static IP address(es) assigned to its IP Properties. If both IPv4 and IPv6
are enabled for a network adapter, both IPv4 and IPv6 static IP addresses should be assigned to both IPv4 and IPv6 Properties of the physical network adapter.
Such static IP address(es) assignment should be done to all the physical network adapters for reliable Domain Name System (DNS) operation.


After the reboot completes, log into the server again, but this time using the newly-created domain: