Oracle Identity Cloud Service

Overview

In the previous article in this series we introduced Oracle Identity Cloud Service (IDCS) and described an approach for multi-tenant provisioning and federated single sign-on using custom application templates and just-in-time provisioning with Salesforce and ServiceNow applications. We also reviewed a hybrid scenario for integration with Oracle Identity Manager (OIM) and the inherent synergies of integrating both solutions. In this article we continue to explore hybrid scenarios, this time focusing on the integration with Microsoft Active Directory, an on-premise infrastructure present in most organizations.

Integration with Microsoft Active Directory

Organizations moving gradually to the cloud commonly require the ability to capitalize on existing infrastructure; the integration with enterprise directories like Active Directory (AD) is a good example of such requirements. The Microsoft Active Directory Bridge (AD Bridge), is an IDCS component that can be deployed on-premises to facilitate the integration with AD by allowing organizations to synchronize AD identities with the IDCS identity store.

Some of the benefits of such integration using the AD Bridge include:

Facilitate the import of existing AD identities into IDCS

In conjunction with federation, to provide a seamless path for users transitioning to the cloud, as they can continue using their existing AD credentials when accessing applications in the cloud as well as on-premises

Automate the synchronization of AD users and groups with IDCS

Figure 1 depicts a typical deployment scenario in which the AD Bridge agent is used to facilitate the integration with on-premises AD.

Figure 1. IDCS Integration with Active Directory

The AD Bridge Agent

The AD Bridge agent is an IDCS component built using the .NET Framework and deployed as a Windows service in a machine member of the AD domain. As described earlier, its main task is to synchronize AD user identities and groups with the IDCS identity store.

The AD Bridge agent can be downloaded from an IDCS tenant service and installed using a graphical mode (GUI) or silent installation. The features currently available in the AD Bridge agent are:

Scheduled or on-demand synchronization

Configurable list of attribute mappings to be synchronized

Support for multiple domains, requiring at least one AD Bridge instance per domain

Centralized configuration model; once the AD Bridge agent is deployed on a target machine, its configuration and management are done through the IDCS console

Synchronization of users and groups from one or multiple organizational units (OUs)

About Docker Swarm and Windows Containers

Swarm is the native clustering system embedded in the Docker engine (as of version 1.12); it provides a fault-tolerant, self-healing, decentralized architecture. Nodes in a Swarm are Docker instances that run in a physical or virtual machine. The concept of service refers to the task definitions executed in nodes; examples of a service include a database, application or a web server. A task carries a Docker container and the commands to run inside the container, so you can assume that, each time a service is created, one or more containers are deployed across one or more nodes in the Swarm.

Within a Docker Swarm exist two types of nodes: manager and worker. Manager nodes dispatch tasks to worker nodes and perform the orchestration and management functions required to maintain the desired state of the Swarm. Worker nodes receive and execute tasks dispatched from manager nodes.

Docker recommends having an odd number of nodes; for example, a three-manager Swarm will tolerate a maximum loss of one manager node, while a five-manager Swarm will tolerate a simultaneous loss of two manager nodes. Seven is the maximum number of manager nodes that Docker recommends to have in a Swarm.

A Swarm with one manager node can still provide high-availability capabilities with worker nodes and services but no fault-tolerance (i.e., if the manager fails, services will continue functioning but the loss of the manager will require the creation of a new Swarm to recover).

The diagram in Figure 2 describes the concept of a Docker Swarm made with at least one manager node and one or more worker nodes.

Figure 2. Docker Swarm - Conceptual View

Windows Containers

Windows containers, Microsoft's native container technology (available in Windows Server 2016 and Windows 10), facilitates the porting of the Docker engine on Windows, along with Docker clients like Composer, Swarm and other tools. Based on the isolation level, two types of Windows containers exist:

Hyper-V Containers have their own copy of the Windows kernel (providing higher isolation and security), host Windows Server containers, and are the default container technology in Windows 10. Please note that Hyper-V containers are not VMs: they are stripped-down Hyper-V VMs instantiated only for containers.

Currently, two Windows OS images can be deployed in Windows containers:

Nano Server, a minimalist version of Windows Server, which can run IIS and applications based on the new .NET Core framework The diagram in Figure 3 depicts the concept of Windows containers and the Docker engine available in Windows Server 2016.

Figure 3. Windows Server and Hyper-V Containers

An Approach to HA using Docker and Windows Containers

This section will demonstrate how high-availability (HA) deployment of the AD Bridge agent can be achieved by using Docker Swarm and Windows containers. As described above, the AD Bridge agent is a .NET application deployed as a Windows service that can be easily installed in a Windows Server Core instance. Consequently, and by leveraging the Docker engine available in Windows Server 2016, the AD Bridge agent can be hosted in a Windows container running on two or more Docker nodes forming a cluster, representing a single virtual system and ultimately one agent instance in IDCS.

Note: The approach described in this article represents a proof of concept (PoC) and is intended only to demonstrate how container technology works. This approach/solution is not supported by IDCS.

Solution Overview

The diagram in Figure 4 illustrates the environment chosen to test the solution: a Microsoft Active Directory domain (left) shows the target directory to be integrated with an IDCS tenant service (right). The center represents the AD Bridge cluster made up of three nodes, each hosting one Windows container. In this Swarm configuration, one node holds the manager's role, while the other two act as workers.

The nodes can be physical or virtual machines and host an arbitrary number of containers, each limited only by the resources available. Each container can have at least one AD Bridge agent; in our configuration we have deployed one container per node, running one agent per container, which makes a total of three agents. Although IDCS and the AD Bridge logic are unaware of the existence of a cluster, we rely solely on the Docker Swarm capabilities to provide high availability to the AD Bridge agent in the event of a node or service failure.

This solution could also facilitate the addition of logic in the agent to add extra features like distribution of the load between nodes, which is useful in domains with many users and groups to synchronize.

Figure 4. Solution Overview

Assumptions and Prerequisites

The configuration in this solution assumes an Active Directory 2012 domain on-premises, along with three member servers with Windows Server 2016 installed on each. An IDCS tenant service is also available for the integration.

The instructions will cover the installation of Docker on Windows Server 2016, deployment of a Windows Server Core image in a Windows container, installation of the AD Bridge agent and configuration in IDCS, and configuration and testing of the Docker Swarm cluster.

In order to demonstrate HA with the AD Bridge agent, we have pre-populated the domain with 1,000 users, allowing time during the synchronization to simulate failure and recovery events with nodes and containers.

It's important that all participant servers are reachable via their DNS names, so the containers and services running inside can reach the IDCS tenant service and AD domain.

Configuring Docker and AD Bridge

1. Installing Docker on Windows Server 2016

Before starting the installation of any component, make sure you have your Windows Servers 2016 up to date, by running the sconfig command from a Command Prompt window.

Login as Local or Domain Administrator and run the following command:

sconfig

From the menu, select option 6) Download and Install Updates to update your Windows Server 2016. Repeat this step with the remaining servers.

In Windows Server 2016, you have two options to install the Docker engine: Docker Enterprise Edition for Windows Server 2016 (Docker EE) and Docker Community Edition (Docker CE). The main difference is that Docker EE is a Microsoft stable and supported version of Docker engine while Docker CE is a community edition that usually contains new and experimental features that are expected to be included later in the enterprise edition. For the purpose of implementing our solution, we will use the community edition for Windows Server 2016 known as Docker for Windows Server 2016 Edge edition, which contains a feature not currently available in the enterprise edition.

Login as Local or Domain Administrator to the first Windows Server 2016. Note: In order to run Docker, users must be members of the docker-users group.

Once the installation is complete, switch to Windows Containers (Docker won't start otherwise). To do so, right click on the little whale icon in the task bar (see Figure 5) to open the context menu, then select the Switch to Windows Containers... option. Docker will enable this feature and re-start the machine. Note: the Hyper-V and Containers features must also be enabled.

Verify the installation by checking the version installed.

One way to check the client and server versions is by running the following command in a Command Prompt window:

Alternatively, you can also verify the version number and edition by right clicking the little whale icon in the task bar and selecting About Docker from the menu (Figure 5).

Figure 5. Docker for Windows Server 2016

Repeat the previous steps to install Docker in the remaining servers.

2. Creating Group Managed Service Account

Login as Domain Administrator to the AD domain controller and create a group-managed service account in Active Directory. The group-managed service account will be used by Windows Server Core to run the AD Bridge agent and to specify the target servers in the domain.

Open the Active Directory Users & Computers tool. Create a group as follows:

Group Name : SRVCOREGROUPGroup Type : Security Group

•Add as members the three Windows Server 2016 servers, e.g.:

ID1-SRVCORE, ID2-SRVCORE and ID3-SRVCORE

To create the group-managed service account, open Server Manager. Go to Tools → Active Directory Module for Windows PowerShell. Run the following commands in the PowerShell window:

In the second command, the Name parameter specifies the name of the service account oracleservice, parameter DNSHostName specifies the DNS hostname for the service account, PrincipalsAllowedToRetrieveManagedPassword is used to specify the group name containing the target servers allowed to use the group-managed service account, and ServicePrincipalNames is used to register its service principal name.

Install the new group-managed service account in the three Windows Server 2016 servers. To do so, login as Domain Administrator to each server. Note: You may need to re-start each server before running the following commands in order to pick up the changes for the new managed-service account created in the AD domain.

This command deploys the image microsoft/windowsservercore inside a Windows container, gives it a name (id1-docker) and hostname (id1-docker), passes the credential file (oracleservice.json) generated in the previous steps, and runs the command (cmd) that starts a Command Prompt interface or command interpreter to execute commands. Because the Command Prompt is interactive, the container will keep running until an exit command is executed or the container is stopped via the docker stop command.

Use the information generated by IDCS to populate the values of the CloudServiceUrl, ClientID and ClientSecret parameters. The AdUserName and AdUserPassword correspond to the AD domain account that will be used by the AD Bridge to perform look-up operations as part of the synchronization process. Make sure this account has the proper privileges to query data in the AD domain.

b. File name: domainDefs.json

[{"domain": "other.com","dc": "zeus.other.com"}]

The domain and dc parameters represent the AD domain name and hostname of the domain controller, respectively. Once the input files are created, do a silent installation of the AD Bridge by running the following commands inside the container:

Once the last command ends, review the log file to verify if the installation completed without errors. At this point if you login to the IDCS tenant service and go to Settings #→ Directory Integrations, you should be able to see the hostname of the container where the AD Bridge is installed (Figure 6).

Figure 6. Directory Integrations - AD Bridge

Now, let’s commit the running container into a new Docker image, so it can be copied to other Docker instances running in the remaining Windows Server 2016 servers. Note: This feature is one of the great benefits of using container technology as the applications running inside can be easily transported to other hosts without having to re-deploy them.

Run the following command to commit the running container 3950c998bc94 into a new image:

docker commit -m "AD-BRIDGE" 3950c998bc94 adbridge/winsrvcore2016:1.0

Verify that the new image is listed in the local repository by running the following command:

This output shows two images; one contains the base Windows Server Core image while the second, adbridge/winsrvcore2016, also contains our changes, including the import of the SSL certificate along with the AD Bridge agent installed. Due to the layering system in Docker, the new image shows as 10.3 GB but is actually using only 0.5 GB of physical space; the remaining belongs to the base image.

Save the image, so it can be transported to other Docker instances.

Run the following command to save the image into a compressed file:

docker save --output C:\Temp\idbridge-srvcore.tar 51e3b01191e9

Since we want to run Windows containers in a cluster, we will delete the current container to later deployed as a service within a Docker Swarm.

Run the following commands to stop and delete the current Windows container:

docker stop id1-dockerdocker rm 3950c998bc94

Copy the compressed image to a temporary folder in the remaining servers. Alternatively, you can copy the image to a share folder.

Once the image is copied to the servers, proceed to load the image into the local Docker repository on each server.

Run the following commands to load and tag the image into the local repository:

5. Configuring Docker Swarm

Login as Local or Domain Administrator to the first Windows Server 2016 and initialize the Docker Swarm.

Run the following command:

docker swarm init --advertise-addr 192.168.0.204

This command initializes the Docker Swarm, adding the current server as the first node. The advertise-addr parameter specifies the IP address of the server (in our case, the first Windows Server 2016) that will be advertised to other members of the Swarm for API access and overlay networking.

This command instructs the Swarm to create a new service using the adbridge/srvcore2016:1.0 image. The replica parameter specifies the number of replica tasks for a replicated service. By default, manager nodes can also run services as worker nodes do; therefore, the previous command results in a new Windows container running in the manager node. Run the following command to verify the services running in the Swarm:

Note: At this point, we have created a Docker Swarm with only one node, and deployed a service (AD Bridge running inside a Windows container). In the next steps we will increase the number of services and nodes in the cluster to have multiple instances of the AD Bridge, and test HA in case of service or node failure.

Testing AD Bridge High-Availability Configuration

1. Synchronizing Users with One-Node and Two AD Bridge Instances

In this step we will test the synchronization of users with one node running two services or instances of the AD Bridge; each instance will run on its own container. To do so, we will increase the number of services from one to two.

Run the following command:

docker service scale adbridge=2

The previous command instructs the Swarm to increase the number of services to two; basically, this means that a second instance of the AD Bridge will start running in a new container.

Run the following command to show the service status:

docker service ls

The output should be similar to the following text (notice the number of replicas now is two):

Now that we have two instances up and running, we will start the import process. Login as Administrator to the IDCS tenant service.

Go to Settings → Directory Integrations. Click the AD Bridge agent and configure the user and groups to be synchronized. In our case, we select the OU Other Users, which, in our domain, contains the test users we want to import into IDCS.

Click the Import tab and then the Import button to start the process. Optionally, the Refresh button can be used to monitor the status.

Once the import process is running, one of the AD Bridge instances will start processing user data from the AD domain into the IDCS identity store.

Before the process ends, we will simulate a failure of the instance by stopping the service and then removing the container from the Swarm.

Run the following commands to access the container and determine if the AD Bridge instance running inside is the one handling the import process.

Note: replace <container_id> with one of the container IDs from the previous output.

The second command will show the content of the log file and help determine if the instance is processing the import of user data. Otherwise, we will run the same commands in the second container. If the instance is processing the import, the following commands will stop the instance:

PowershellStop-Service -name IDBridgeexit

The last command exits the container and returns to the host server. We will then stop and delete the container using the following commands:

docker stop <container_id>docker rm <container_id>

Soon after the previous command is executed, the Swarm will detect the missing container and will automatically start a new AD Bridge instance in a new container to honor the number of services defined in the Swarm.

Wait for the import process to complete and then verify that all the user data in the OU was imported successfully in the IDCS identity store. Figure 7 shows the results in IDCS.

Figure 7. Directory Integrations - Import Process

At this point, we have successfully tested the synchronization of user data even after the AD Bridge instance running the process was taken down.

2. Synchronizing Users with Three-Nodes and Three AD Bridge Instances

In this final step, we will test the synchronization of users using three instances of the AD Bridge, spread out across three nodes in the Swarm cluster. This configuration will allow HA of the AD Bridge such that it will continue running in the event of one of the nodes becoming unavailable.

Join the other two servers to the Swarm cluster.

Run the following command on the first server or manager node:

docker swarm join-token worker

This command will display the token string needed to join other nodes to the cluster. The output is similar to the following text:

The above command instructs the Swarm to increase the number of replicas up to three for the adbridge service. Since there are now three nodes available in the cluster, it will start a Windows container on each of the remaining servers, making a total of three containers.

Run the following command to show the service status:

docker service ls

The output should be similar to the following text (notice the number of replicas now is three):

Now that we have three instances up and running, we will start the import process. Login as Administrator to the IDCS tenant service.

Go to Settings →= Directory Integrations. Click on the AD Bridge agent and configure the user and groups to be synchronized. In our case, we select the OU Other Users, which, in our domain, contains the test users we want to import into IDCS.

Click the Import tab and then the Import button to start the process. Optionally, the Refresh button can be used to monitor the status.

Once the import process is running, one of the AD Bridge instances will start processing user data from the AD domain into the IDCS identity store.

Before the process ends, we will simulate a failure of the instance by shutting down the node in which it is running.

Run the following commands on each node to access the container and determine if the AD Bridge instance running inside is the one handling the import process:

The second command will show the content of the log file and help determine if the instance is processing the import of user data. If so, we will shut down the node in which the instance is running.

Soon after the node is taken down, the Swarm will detect the missing node and will automatically start a new AD Bridge instance in one of the remaining nodes to honor the number of services defined in the Swarm.

Run the following command to see the service details:

docker service ps adbridge

The output reflects that one of the nodes is down, but also shows that two services are now running in the first node. This has been done to compensate for the loss of the second node and to keep the number of running services at three:

We wait for the import process to complete and then verify that all the user data in the OU was imported successfully in the IDCS identity store. The results were similar to what is shown in Figure 7.

At this point, we have successfully tested the synchronization of user data even after one of the nodes running the AD Bridge instance turned it down.

Conclusion

One of the reasons for Docker's wide adoption is its ability to make the packaging and shipping of applications very easy. The inclusion of Swarm in the Docker engine is a step forward in the expansion of its capabilities and a needed entry point into clustering technology, joining the likes of Kubernetes and Mesos.

In this article, we have explored an approach for implementing HA in the AD Bridge, an IDCS component used in the integration with Microsoft Active Directory.

Additional references to the products and features mentioned in this article can be found in the following links:

About the Author

Ricardo Gutierrez is a Senior Consultant with Oracle, working on new technologies, security and cloud computing. His areas of specialization include IDaaS, CASB, Identity and Access Management, Identity Analytics, Identity Governance, Enterprise SSO, Federation, Privileged Account Management, Database and Application Security. With over 25 years of experience, Ricardo has spent the last 13 years working with the full suite of security products from IBM, Microsoft and Oracle. He is also a PMP, CCSP and VMware Certified Professional, and has published a variety of white papers, articles, and training materials covering security and cloud computing.