Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >
article

KB-9565: Enable DirectControl and DirectAudit functionalities inside Docker Container

Centrify DirectControl ,  

14 December,17 at 10:11 PM

 Question:

How to enable DirectControl and DirectAudit functionalities inside Docker container?


Answer:

Introduction
Centrify starts support CoreOS platform in Centrify Infrastructure Services 2017.3.  This KB describes how one can enable DirectControl and DirectAudit functionalities inside docker containers after the host has installed and enabled such functionalities.  All the docker containers share the same identity as the host;  there is no need for individual container to join to Active Directory and there is only one computer from the Active Directory perspective.

Note: You can also install and join the docker container to Active Directory.  This will result in unique identity (computer object) in Active Directory.

Files for docker container support (Attached to KB) 
centrify.repo:  Information for Centrify repository.  
dockerfile.centos.dc: docker file for enabling DirectControl in Centos docker image.  
dockerfile.centos.dcda:  docker file for enabling DirectControl and DirectAudit in Centos docker image.  
dockerfile.ubuntu.dc:  docker file for enabling DirectControl in Ubuntu docker image.  
dockerfile.ubuntu.dcda: docker file for enabling DirectControl and DirectAudit in Ubuntu docker image.  
ubuntu_startup.sh:  Startup script for Ubuntu docker image.

Enable DirectControl functionality inside docker container
Follow these steps to enable DirectControl functionality inside docker containers:

  1. Install DirectControl in CoreOS host.

  2. Join the CoreOS host to zone.

  3. Login to an account that can run docker commands and can run sudo commands as root (e.g., core)

  4. Run the following commands set up a sandbox environment:

    1. mkdir ~/sandbox

    2. cd ~/sandbox

    3. sudo tar -cvf docker.copy.tar /etc/centrifydc /etc/krb5*  

  5. For creating and running a Ubuntu container:

    1. Copy the attached files dockerfile.ubuntu.dc and ubuntu_startup.sh to ~/sandbox

    2. Edit the file dockerfile.ubuntu.dc:

      1.  Replace $CENTRIFY_REPOSITORY_KEY by your Centrify support repository credential.

      2. Replace $ROOT_PASSWORD by the password of the root user in the container

    3. Run this command to build the docker image:

      1. docker build -t "ubuntu:dc" -f ~/sandbox/dockerfile.ubuntu.dc .  (note the period as the last parameter)

    4. Run this command to run the docker image

      1. docker run -d -p $SSHD_PORT:22 -v /var/centrifydc:/var/centrifydc ubuntu:dc

        1. Replace $SSHD_PORT by the port to be used for sshd service for this container

      2. ​​​Note:  If rsyslog cannot be started, you may need to add "--security-opt seccomp:unconfined" to the docker run command line

  6. For creating and running a CentOS container:

    1. ​Copy the attached files dockerfile.centos.dc and centrify.repo to ~/sandbox

    2. Edit the file centrify.repo and replace $CENTRIFY_REPOSITORY_KEY by your Centrify support repository credential

    3. Edit the file dockerfile.centos.dc to replace $ROOT_PASSWORD by the password of the root user in the container

    4. Run this command to build the docker image

      1. docker build -t "centos:dc" -f ~/sandbox/dockerfile.centos.dc .  (note the period as the last parameter)

    5. Run this command to run the docker image

      1. docker run -d -p $SSHD_PORT:22 -v /var/centrifydc:/var/centrifydc -v /sys/fs/cgroup:/sys/fs/cgroup --cap-add=SYS_ADMIN centos:dc

      2. Replace $SSHD_PORT by the port to be used for sshd service for this container


Enable both DirectControl and DirectAudit functionalities inside docker container
Follow these steps to enable both DirectControl and DirectAudit functionalities inside docker container:

  1. Install DirectControl and DirectAudit in CoreOS host
  2. Join the CoreOS host to zone.
  3. Login to an account that can run docker commands and can run sudo commands as root (e.g., core)
  4. Run the following commands set up a sandbox environment:
    1. mkdir ~/sandbox
    2. cd ~/sandbox
    3. sudo tar -cvf docker.copy.tar /etc/centrifydc /etc/centrifyda /etc/krb5*  
  5. For creating and running a Ubuntu container:
    1. ​Copy the attached files dockerfile.ubuntu.dcda and ubuntu_startup.sh to ~/sandbox
    2. Edit the file dockerfile.ubuntu.dcda:
      1. Replace $ROOT_PASSWORD by the password intended for root in the container

      2. Replace $CENTRIFY_REPOSITORY_KEY by your Centrify support repository credential.

    3. Run this command to run the docker image
      1. docker build -t "ubuntu:da" -f ~/sandbox/dockerfile.ubuntu.dcda .   (note the period as the last parameter)
    4. Run this command to build the docker image:
      1. ​​docker run -d -p $SSHD_PORT:22 -v /var/centrifydc:/var/centrifydc -v /var/centrifyda:/var/centrifyda ubuntu:da
      2. Replace $SSHD_PORT by the port to be used for sshd service for this container
      3. Note:  If rsyslog cannot be started, you may need to add "--security-opt seccomp:unconfined" to the docker run command line
  6. For creating and running a CentOS container:
    1. Copy the attached files dockerfile.centos.dcda and centrify.repo to ~/sandbox
    2. Edit the file centrify.repo to replace $CENTRIFY_REPOSITORY_KEY by your Centrify support repository credential
    3. Edit the file dockerfile.centos.dcda to replace $ROOT_PASSWORD by the password intended for root in the container
    4. Run this command to build the docker image
      1. docker build -t "centos:da" -f ~/sandbox/dockerfile.centos.dcda .  (note the period as the last parameter)
    5. Run this command to run the docker image
      1. docker run -d -p $SSHD_PORT:22 -v /var/centrifydc:/var/centrifydc -v /var/centrifyda:/var/centrifyda -v /sys/fs/cgroup:/sys/fs/cgroup --cap-add=SYS_ADMIN centos:da
      2. Replace $SSHD_PORT by the port to be used for sshd service for this container



Access kerberos cache and/or keytab file of host machine account from inside docker container
The docker containers share the identity (and machine account) of the host.   The kerberos credential cache and keytab file are created and stored in the host; and are not available to the docker containers by default.  If a kerberos application running inside the docker container needs to use the kerberos credential cache and keytab files of the host machine account,  Centrify recommends the following steps:

  1. By default, the host machine account kerberos credential cache and keytab files are stored in /etc, and it is not good practice to share this directory with the containers.  So, we need to use a separate directory to store and share such files.
  2. Set up in CoreOS host:
    1. Create a directory /etc/centrify_krb5 for storing the host machine's kerberos credential cache and keytab file
    2. Set up the following configuration parameters in centrifydc.conf:
      1. adclient.krb5.ccache.file: /etc/centrify_krb5/krb5.ccache
      2. adclient.krb5.keytab: /etc/centrify_krb5/krb5.keytab
    3. Note that these two parameters are effective when the host is joined to Active Directory.   Please set up these two parameters before you join the CoreOS host to Active Directory.
    4. If there are any host applications/scripts look for machine kerberos credential cache and keytab files in /etc, create the following symlinks:
      1. ln -s /etc/centrify_krb5/krb5.keytab  /etc/krb5.keytab
      2. ln -s /etc/centrify_krb5/krb5.ccache /etc/krb5.ccache
  3. For the docker images:
    1. In the docker run command, specify -v /etc/centrify_krb5:/etc/centrify_krb5 to set up the bind mount mappin
    2. Point the kerberos applications/scripts to use krb5.keytab/krb5.ccache in /etc/centrify_krb5 (intead of /etc)

Please contact Centrify Technical Support if the docker applications cannot use alternate locatoins for the kerberos credential cache and keytab files.

Access kerberos credential cache file of Active Directory users from inside docker container
After an Active Directory user logins to a docker container, the kerberos credential cache file (krb5cc_<uid>, or krb5cc_cdc<unique_number>_<uid>) is created in /tmp in the CoreOS host, not in /tmp in the docker container.   The workaround for now is to for the docker container to mount the /tmp directory using "-v /tmp:/tmp" in the docker run command.
Active Directory user logins inside docker container

When Active Directory user logins inside a docker container, the home directory is not created inside the docker container.  You can work around this by:

  • Share the home directory of the host with the docker container by specifying "-v /home:/home" in the docker run command.

  • Modify the pam configuration in the docker container to invoke pam_mkhomedir.so for the PAM session management.

Note that the kerberos credential cache (krb5cc_<uid>, or krb5cc_<unique_id>_<uid>) is create in /tmp in the CoreOS host.


KCM support
KCM is supported in CoreOS, and Active Directory users can login to docker containers.  However, the kerberos credential cache is not available to kerberos applications running inside the docker container.
Notes about DirectControl utilities

  1. Do not run "adleave" inside any docker container.  This may affect the configuration in the host.

  2. If you run "adleave" from the host and then joins to Active Directory again using adjoin, all docker containers MUST be restarted.  Otherwise, DirectControl and DirectAudit functionalities will not work in the docker containers.

  3. "adreload" should not be run in the docker container.  It does not change anything in the container or the CoreOS host but generates an audit trail event in the docker syslog.

  4. If addebug is enabled in a docker container, all the debug messages are sent to the host, and cannot be found in the docker container itself.

  5. Instead of copying a snapshot of /etc/centrifydc and /etc/centrifyda to the docker containers, you can also share these directories with the docker containers by using the -v option in the docker run command.   If you decide to do this, running "addebug on/off" (and "dadebug on/off") on the host will enable/disable debug messages for all the containers.  


Notes about DirectAudit support inside docker container

  1. Command line auditing can be supported in a docker.  However, it is not recommended.   One issue is that once you enable command auditing in a container, running dainfo in the host OS or any container shows that the command is enabled for auditing in all container and the host OS.  However, this information is not correct.    Command auditing is not supported in CoreOS and only works in containers where it is enabled.

  2. Running dainfo in docker container will not show the status of Advanced Monitoring support.   In addition, it shows the error message "Usable to send lrpc2 message: 406 (Socket error)"

  3. Running "dacontrol -e/dacontrol -d" in the CoreOS host only enables/disables session auditing in the host.  There is no effect in the docker containers.   If you want to enable/disable session auditing in individual container, run "dacontrol -e"/"dacontrol -d" in  the container itself.  By default, session auditing is automatically enabled in the docker container.

  4. If auditing is required for any user, you MUST enable session auditing in both the host and docker container.  Otherwise, such user will not be able to login to a container even though it is enabled just on the container.

  5. Running dainfo in docker container only shows the session auditing status of the host, not that of the docker container.   To check session auditing status in the container, search to see if centrifyda is defined in file /etc/nsswitch.conf in the container.


Features that are not supported in docker containers

The following features are not currently support in the docker containers:

  1. DirectAudit Advanced Monitoring

  2. FIPS

  3. NIS

  4. Group policies

  5. Installation using Deployment Manager

  6. MFA diagnostic tool (adcdiag).    There is no need to run adcdiag in the docker container as the MFA processing is done in the container host. 

Attachments:

Still have questions? Click here to log a technical support case, or collaborate with your peers in Centrify's Online Community.

Related Articles

No related Articles