Oracle Identity Cloud Service


Deep Dive Series: AD Bridge High-Availability Configuration Using Docker and Windows Containers


By Ricardo Gutierrez


October 2017

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.

gutierrez-idcs-docker-fig01

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.

gutierrez-idcs-docker-fig02

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:

  • Windows Server Containers, the default container technology in Windows Server 2016, share the Windows kernel, providing standard isolation and rapid start-up.
  • 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:

  • Windows Server Core, a compact version (without the GUI ) of Windows Server, which runs most Windows Server applications (e.g., IIS, SQL Server and compatible .NET Framework applications)
  • 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.
gutierrez-idcs-docker-fig03

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.

gutierrez-idcs-docker-fig04

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.

Summary of Configuration Steps

Configuring Docker and AD Bridge
  1. Installing Docker on Windows Server 2016
  2. Creating Group Managed Service Account
  3. Download Windows Server Core Image
  4. Deploying Windows Server Core and AD Bridge in Windows Container
  5. Configuring Docker Swarm
Testing AD Bridge High-Availability Configuration
  1. Synchronizing Users with One-Node and Two AD Bridge Instances
  2. Synchronizing Users with Three-Nodes and Three AD Bridge Instances

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.
  • Download Docker for Windows Server 2016 Edge edition. Save the executable in a temporary folder.
  • Start the installation.

    From Windows Explorer, start the installer:

    C:\temp\Docker for Windows Installer.exe
    

    Complete the installation as instructed by the installation wizard.

  • 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:

    docker version
    

    You must get an output similar to the following text:

    C:\>docker version
    Client:
     Version:      17.06.0-ce-rc2
     API version:  1.30
     Go version:   go1.8.1
     Git commit:   402dd4a
     Built:        Wed Jun  7 10:01:32 2017
     OS/Arch:      windows/amd64
    
    Server:
     Version:      17.06.0-ce-rc2
     API version:  1.30 (minimum version 1.24)
     Go version:   go1.8.3
     Git commit:   402dd4a
     Built:        Wed Jun  7 10:03:57 2017
     OS/Arch:      windows/amd64
     Experimental: true
    
    
  • 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).
    gutierrez-idcs-docker-fig05

    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      : SRVCOREGROUP
    Group 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:
    Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))
    New-ADServiceAccount -Name oracleservice -DNSHostName oracleservice.other.com
    -PrincipalsAllowedToRetrieveManagedPassword SRVCOREGROUP
    -ServicePrincipalNames http/oracleservice.other.com
  • 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.

    Open a PowerShell ISE window and run the following commands:

    Import-Module ActiveDirectory
    Get-ADServiceAccount -Filter *
    Install-ADServiceAccount -Identity oracleservice
    Test-AdServiceAccount oracleservice

    The last command should return True, indicating that the account was successfully installed.

  • Download the CredentialSpecs script to generate the credentials file. This file will be passed to the Windows containers so they can run the AD Bridge agent using the group-managed service account.

    Once you have downloaded the script in a temporary folder, open a PowerShell ISE window and run the following commands:

    Add-WindowsFeature RSAT-AD-PowerShell
    Import-Module ActiveDirectory
    Import-Module C:\TEMP\CredentialSpec.psm1
    New-CredentialSpec -Name oracleservice -AccountName oracleservice

    Run the following command to verify the result:

    Get-CredentialSpec 
    

    The output should be similar to the following text

    Name              Path
    ------------- ----------------
    oracleservice C:\ProgramData\Docker\CredentialSpecs\oracleservice.json

3. Download Windows Server Core Image

  • In the first Windows Server 2016 (where we have installed the Docker engine), download the Windows Server Core image to the local Docker repository.
  • Login as Local or Domain Administrator to the first Windows Server 2016 and download the Windows Server Core image.

    Open a Command Prompt window and run the following command:

    docker pull microsoft/windowsservercore 
    

    This command will download the image from the Microsoft repository and make it available to the local Docker repository. The average image size is 10 GB for Windows Server Core.

    Run the following command to list the images in the local repository:

    docker images
    

    You should get an output similar to the following text:

    REPOSITORY                    TAG       IMAGE ID       CREATED        SIZE
    microsoft/windowsservercore latest 4f222178c921 2 weeks ago 10.2 GB

4. Deploying Windows Server Core and AD Bridge in Windows Container

  • Login as Administrator to the IDCS tenant service to define a new AD Bridge.
  • Go to Settings → Directory Integrations, then click Add to create a new definition.

    Write down the information generated by IDCS:

    Cloud Service URL   : https://mydemotenant1.idcs.internal.oracle.com:8943
    Cliend ID : e7c04e28bc12415190ea37f0e2fdf325
    Client Secret : 71d6b308-a21e-47ef-9dc1-f5ee907ce2e3

    Next, click the Download button to download the AD Bridge installer. Save the file to a temporary folder in the Windows Server 2016 that has the Docker engine installed.

  • Deploy the Windows Server Core image inside a Windows container.

    Open a Command Prompt window and run the following command (all in one line):

    docker run -it --name id1-docker --hostname id1-docker --security-opt "credentialspec=file://
    oracleservice.json" microsoft/windowsservercore cmd

    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.

  • Verify the status of the Windows container.

    In a Command Prompt window, run the following command:

    docker ps
    

    You should get an output similar to the following text:

    C:\>docker ps
    CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
    3950c998bc94 microsoft/windowsservercore:latest "cmd" 2 hours ago Up 2 hours id1-docker
  • Validate that the Window Server Core image running inside the container can reach the AD domain.

    Connect to the image inside the container:

    docker exec -it 3950c998bc94 cmd 
    

    This command connects to a running container and opens a Command Prompt window inside the container. Run the following command:

    nltest.exe /parentdomain 
    

    If successful, it returns the domain name, similar to the following output:

    C:\>nltest.exe /parentdomain
    other.com. (1)
    The command completed successfully

    Next, type exit to close the Command Prompt window inside the container and return to the host's Command Prompt window.

  • Copy the AD Bridge installer and IDCS SSL certificate to the Windows container.

    Run the following commands from a Command Prompt window:

    docker cp C:\TEMP\ad-id-bridge-17.2.2-rel.1314.exe 3950c998bc94:C:\TEMP\ad-id-bridge.exe
    docker cp C:\TEMP\idcs.cer 3950c998bc94:C:\TEMP

    These commands copy the AD Bridge installer ad-id-bridge-17.2.2-rel.1314.exe and idcs.cer file to folder C:\TEMP inside Windows container 3950c998bc94, which is running the Windows Server Core image.

  • Install the IDCS SSL Certificate and AD Bridge agent inside the Windows container.

    Connect to the image inside the container:

    docker exec -it 3950c998bc94 cmd 
    

    Start PowerShell and run the following commands:

    C:\powershell
    cd C:\TEMP
    $file = (Get-ChildItem -Path C:\Temp\idcs.cer)
    $file | Import-Certificate -CertStoreLocation cert:\LocalMachine\Root

    In order to install the AD Bridge agent in silent mode we need first to create two input files as follows:

    a. File name: SilentInstallData.json

    {
    "CloudServiceUrl": ""https://mydemotenant1.idcs.internal.oracle.com:8943",
    "ClientID": "e7c04e28bc12415190ea37f0e2fdf325",
    "ClientSecret": "71d6b308-a21e-47ef-9dc1-f5ee907ce2e3",
    "AdUserName": "oracle",
    "AdUserPassword": "P@ssw0rd",
    "UseLdapSsl": false
    }

    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:

    cd C:\TEMP
    ad-id-bridge.exe DomainDefs=domainDefs.json ResponseFile=SilentInstallData.json /quiet
    /log idbinstall.log

    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).

    gutierrez-idcs-docker-fig06

    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:

    docker images 
    

    The output should be similar to the following text:

    C:\>docker images
    REPOSITORY TAG IMAGE ID CREATED SIZE
    adbridge/winsrvcore2016 1.0 51e3b01191e9 56 minutes ago 10.3 GB
    microsoft/windowsservercore latest 4f222178c921 3 weeks ago 10.2 GB

    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-docker
    docker 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:

    docker load --input C:\TEMP\idbridge-srvcore.tar
    docker tag $(docker images | grep '^<none>' | awk '{print $3}') adbridge/srvcore2016:1.0

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.

    Run the following command to list the nodes available in the Swarm:

    docker node ls
    

    The output should be similar to the following text:

    ID                            HOSTNAME       STATUS   AVAILABILITY    MANAGER STATUS
    3sbj6rsvuewvaw78307keunxr * ID1-SRVCORE Ready Active Leader

    Since this is the first node joining the Swarm, it automatically assumes a manager role (Leader).

  • Create a Swarm service.

    Run the following command (all in one line):

    docker service create -t --name adbridge --detach=false --hostname id1-docker --credential-spec="file://
    oracleservice.json" --replicas 1 adbridge/srvcore2016:1.0 cmd

    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:

    docker service ls
    

    The output should be similar to the following text:

    ID            NAME        MODE         REPLICAS    IMAGE                    PORTS
    rawbq164eqz adbridge replicated 1/1 adbridge/srvcore2016:1.0

    The following command shows the running containers:

    docker ps
    

    The output should be similar to the following text:

    CONTAINER ID        IMAGE                      COMMAND    CREATED             STATUS              PORTS   NAMES
    ca0c41382737 adbridge/srvcore2016:1.0 "cmd" 2 minutes ago Up About a minute
    adbridge.1.m2c4yeaexhmunclj5qa6rfa2o
  • 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):

    ID             NAME        MODE         REPLICAS   IMAGE                    PORTS
    ryawbq164eqz adbridge replicated 2/2 adbridge/srvcore2016:1.0

    The following command will show the containers running:

    docker ps
    

    The output should be similar to the following text:

    CONTAINER ID        IMAGE                      COMMAND   CREATED              STATUS              PORTS   NAMES
    ca0c41382737 adbridge/srvcore2016:1.0 "cmd" About a minute ago Up About a minute adbridge.
    2.sew9xkw74tgrzjh68ewws55be
    9931a440fb8f adbridge/srvcore2016:1.0 "cmd" 5 minutes ago Up 5 minutes adbridge.
    1.m2c4yeaexhmunclj5qa6rfa2o
  • 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.

    docker exec -it <container_id> cmd
    type C:\ProgramData\Oracle\IDBridge\logs\IDBridge.log

    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:

    Powershell
    Stop-Service -name IDBridge
    exit

    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.

    Run the following command:

    docker ps
    

    The output shows that a new container has been added:

    CONTAINER ID        IMAGE                      COMMAND   CREATED           STATUS           PORTS   NAMES
    3155e78cb2e5 adbridge/srvcore2016:1.0 "cmd" 14 minutes ago Up 14 minutes adbridge.
    2.pxk7bfu66lbvgkm7iz7zgewsz
    9931a440fb8f adbridge/srvcore2016:1.0 "cmd" About an hour ago Up About an hour adbridge.
    1.60vcbqp4w4ctb5c9tg8gfdxp0
  • 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.

    gutierrez-idcs-docker-fig07

    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:

    To add a worker to this swarm, run the following command:

    docker swarm join
    --token SWMTKN-1-05zmd77r7fla384zx8dus28zpsv0n5rus38gugns2fe3o97f2u-5a9zp4mbpp3qolloa48gitog9 192.168.0.204:2377

    Run the following command on the second and third server:

    docker swarm join
    --token SWMTKN-1-05zmd77r7fla384zx8dus28zpsv0n5rus38gugns2fe3o97f2u-5a9zp4mbpp3qolloa48gitog9 192.168.0.204:2377

    Run the following command in the first server or manager node to list the nodes available in the Swarm:

    docker node ls 
    

    The output should be similar to the following text:

    ID                            HOSTNAME         STATUS      AVAILABILITY    MANAGER STATUS
    hdnactidu3kb8z00f47hwq0f5 ID3-SRVCORE Ready Active
    juehq3q313dazsxllhtbn0il2 * ID1-SRVCORE Ready Active Leader
    m9fih9k6p882z39w8yghrphl8 ID2-SRVCORE Ready Active
  • Now, let’s scale up the service to three replicas.

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

    docker service scale adbridge=3 
    

    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):

    ID             NAME         MODE          REPLICAS     IMAGE                      PORTS
    2jtgntraysn1 adbridge replicated 3/3 adbridge/srvcore2016:1.0

    The following command shows additional details of the service adbridge in the Swarm cluster:

    docker service ps adbridge
    

    The output should be similar to the following text:

    ID             NAME          IMAGE                      NODE          DESIRED STATE  CURRENT STATE              ERROR  PORTS
    h4nhqmckt96j adbridge.1 adbridge/srvcore2016:1.0 ID3-SRVCORE Running Running about a minute ago
    im8ypfbp9xlk adbridge.2 adbge/srvcore2016:1.0 ID1-SRVCORE Running Running 2 minutes ago
    82b1iqhsm0sd adbridge.3 adbridge/srvcore2016:1.0 ID2-SRVCORE Running Running about a minute ago
  • 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:

    docker exec -it <container_id> cmd
    type C:\ProgramData\Oracle\IDBridge\logs\IDBridge.log

    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:

    ID              NAME            IMAGE                      NODE          DESIRED STATE  CURRENT STATE             ERROR  PORTS
    h4nhqmckt96j adbridge.1 adbridge/srvcore2016:1.0 ID3-SRVCORE Running Running 19 minutes ago
    im8ypfbp9xlk adbridge.2 adbridge/srvcore2016:1.0 ID1-SRVCORE Running Running 19 minutes ago
    93mn9x7q1loe adbridge.3 adbridge/srvcore2016:1.0 ID1-SRVCORE Running Running about a minute ago
    82b1iqhsm0sd \_ adbridge.3 adbridge/srvcore2016:1.0 ID2-SRVCORE Shutdown Running 19 minutes ago
  • 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.

Save