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  >

Walk-through of procedures for joining *NIX systems to a domain, using Centrify - part 2

11 April,19 at 11:50 AM

In part 1 of the series, we've looked at the various methods available to join a system to Active Directory in one go. In the second and final instalment of the article series, the security implications are discussed, the available alternatives, and the additional benefits that these alternative join procedures bring to the table.


Security implications of using adjoin with on the spot object creation

What can an attacker, who gets their hands on a current version of the keytab/password of the service account, used for joining the machine to the domain, do with these credentials?


  • Create computer objects in the OU to which they have the permission to create computer objects

This allows an attacker to connect to Active Directory and any network services that allow access to the machine account (and keep in mind that in addition to the Domain Computers group, the Authenticated Users group in Active Directory also has all computer objects as member).

Alternatively, the attacker could start creating a near-endless amount of computer objects in the domain, in order to try and perform a denial of service attack against AD.


  • Reset passwords on all computer accounts in the same OU

This can be abused for a denial-of-service attack on computer systems, that will prevent them from refreshing their group policies from Active Directory, and require a system administrator to re-synchronise the trust relationship between Active Directory and the system whose password was changed. 


  • Create/update serviceConnectionPoint objects in the target Centrify Zone

As a result of the create object right, an attacker could use this to create a near-endless amounts of objects in Active Directory.


Pre-staging of the computer object

To address these risk, the creation of computer objects in the UNIX Servers OU in Active Directory, as well as the creation of serviceConnectionPoint objects in the Centrify Zone, can be separated from the adjoin procedure on the target system.

As a result, two different Active Directory accounts will be required; one that can create the required objects in Active Directory (such as delegated to the ComputerManagers group by deploy.ps1), and a second account that performs the join procedure. The second account type only requires the password reset permission on the computer object that has been pre-staged.


This procedure is commonly referred to as pre-staging the computer object, and brings additional advantages when using Centrify:

  1. It allows validation of the resultant Centrify authorizations, applied through zone and computer role membership, prior to joining the machine to Active Directory. This can easily be incorporated in the company's workflow, and can be enforced when combined with application of the reset password delegation by the people who sign off on the validated authorizations.
  2. If you need the computer to be in a specific computer role, the object can also be added to any desired computer groups prior to it joining the domain.


Using Centrify Server Suite, pre-staging of the computer account can be performed through a variety of methods.


Manual pre-staging using the Centrify graphical console

This method is usually the first method people learn when they start using the Centrify Server Suite. A Centrify Zone administrator uses the Centrify DirectManage Access Manager console to use the Prepare UNIX computer wizard to pre-stage the computer object in Active Directory:




Among a number of other options, the console operator can then choose to allow a self-service join, or to delegate the join operation to members of a 'join operators' group (usual *NIX system administrators):



Note that the above presentation may lead to the incorrect idea of granting access for either one operation or the other, but this is not the case; even when delegating a specific Active Directory user or group the ability to join the computer to the zone, the computer will also be able to join itself (Thank you Frédéric for pointing this out).

Instead, to revoke the self-serve ability when delegating to an AD principal or AD group, you will need to initialize the computer account password to a value different from the default, which is the sAMAccountName minus the trailing dollar sign ($).


Joining the pre-staged system to the domain

After having pre-created the computer object and its profile in the Centrify Zone, the target machine can autonomously join itself to Active Directory, in this example to the domain, by running the following command:


# sudo adjoin --selfserve 


Automated pre-staging of the computer object

Pre-creation of the computer object and the computer profile in the Centrify Zone (represented by a serviceConnectionPoint object and in case machine overrides need to be created, also a container object) can be scripted from any UNIX machine with the Centrify agent package installed that can communicate with the Active Directory domain controllers, or on a Windows machine joined to the domain that has the Centrify Access module for PowerShell installed.


Automated pre-staging of the computer object on UNIX

For pre-creation on a UNIX machine, repeat the process of creating a service account and downloading its keytab with adkeytab using the procedure described in the section Kerberized adjoin with on the spot object creation, as discussed in Walk-through of procedures for joining *NIX systems to a domain - Part 1. The service account needs to be delegated the permissions in Active Directory to create the required objects, for example by membership of the Active Directory group ComputerManagers, created by deploy.ps1. In this example, the service account is called svc-prestage


To pre-create the computer object for a system with hostname rhel-01 from a UNIX system that has the keytab for the svc-prestage account in /etc/svc-prestage.keytab, run the following commands:


# kinit -kt /etc/svc-prestage.keytab svc-prestage
# sudo adjoin --precreate --name rhel-01 --zone LinuxServers --container " Servers"
# kdestroy 

Note as mentioned in part 1 of the article series, this will automatically register the DNS zone of the Active Directory domain in the fully qualified name of the computer object's dNSHostName attribute. If the --name parameter is omitted, the hostname of the machine is automatically used as first component of the hostname when setting the value of dNSHostName of the computer object in Active Directory.

To register a different DNS zone for the computer object, specify the desired fully qualified hostname as argument of the --name parameter.

Please study the man page of the adjoin command to use other advanced features, such as registering additional Kerberos service principals or support for use in a DMZ with a RODC.

Note further, that in addition to creating the computer and serviceConnectionPoint objects, adjoin --precreate also automatically delegates the required permission on the computer object to join itself to the zone, as well as initializes the computer password to the default value.

This allows the target machine rhel-01 to autonomously join itself to Active Directory using the adjoin selfserve option:


# sudo adjoin --selfserve

In certain scenarios, using the default computer password for pre-staged computer objects is not desirable, as certain personnel may have access to the computer name of the pre-staged account, and can use this information to anonymously connect to Active Directory, prior to re-initialisation of the computer password by the adjoin command.


In these scenarios, it is possible to re-initialize the computer account password directly after pre-creating it in Active Directory, and to delegate the join procedure to another Active Directory principal.


On a UNIX machine where pre-staging is performed, the following procedure could be used, to change the computer password for the pre-staged computer:


# kinit -kt /etc/svc-prestage.keytab svc-prestage
# sudo adjoin --precreate --name rhel-01 --zone LinuxServers --container " Servers"
# kdestroy
# echo -e $COMP_PASSWORD\\n$COMP_PASSWORD | /usr/bin/adpasswd --adminuser rhel-01$ --adminpass rhel-01

Note that the should be replaced by a procedure to generate a complex password on the spot, and should not appear in any logs, bash history or variables once the pre-staging has been completed.

For this reason, the above example does not specify the new password on the command line using the --newpass parameter for adpasswd; when omitted, adpasswd will prompt twice for the new password. This new password can be fed by assigning a random password to a variable, it passed it twice to the adpasswd binary, through separation with the escaped hard return character \\n


Automated pre-staging of the computer object on Windows

On Windows, a PowerShell script could be used, that is executed using the principal that has the permissions to create the required objects in Active Directory:


# Import-Module Centrify.DirectControl.PowerShell
# New-CdmManagedComputer -Zone (Get-CdmZone -name "LinuxServers") -Container "OU=UNIX Servers,OU=Centrify,DC=company,DC=com" -Name "rhel-01"

Note to run Get-Help New-CdmManagedComputer -detailed in a PowerShell window to see more details on how to use this CMDlet, such as with advanced capabilities for registering Kerberos SPNs, non-standard DNS names for the computer object, delegations, support for RODC in a DMZ, etc.


As with adjoin --precreate, New-CdmManagedComputer also initializes the permissions and default password required for a self-service join operation.

To change the default computer password, various methods can be used; the PowerShell module ActiveDirectory, included as a feature with Windows Server or the Remote Server Administration Tools, contains the Set-ADAccountPassword CMDlet, that can be used to reset the default computer password:

# $computer_credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "company\rhel-01$",(ConvertTo-SecureString -AsPlainText "rhel-01" -Force)
# Set-ADAccountPassword -Identity rhel-01$ -NewPassword (ConvertTo-SecureString -AsPlainText $RandomPassword -Force) -Reset -Credential $computer_credential 

Note generation of the random password and assigning it to the $RandomPassword variable is not shown in this example, but is nevertheless required to perform the above operation.

Note further that the NETBIOS domain where the computer account is located, needs to be specified as argument of New-Object's ArgumentList parameter.


Delegation of join permissions

Once the computer object has been pre-created, and a random password has been initialized, the join operation would then be performed by a user that has been delegated the reset password permission on the target computer account in Active Directory. This delegation can be assigned when pre-staging the computer object using the New-CdmManagedComputer CMDlet, by specifying the join operator as argument of the -Delegate parameter, which can be combined with -AdjoinAndMachineOverrides to also delegate creation of machine overrides.

Run Get-Help New-CdmManagedComputer -detailed in a PowerShell window to see more details on how to use this CMDlet.

On UNIX, the Centrify supplied ADEdit application could be used to delegate these permissions.


Delegated Join of a pre-staged computer to the domain

When the computer password has been initialized to a random value, the self-serve operation on longer can be used. Instead, the interactive join operation (or non-interactive with hardcoded password when specified as argument of the --password parameter) needs to be performed by a principal that has been delegated the required reset password right, by running adjoin with the following parameters:


# sudo adjoin --zone LinuxServers --user  --force 

When using a service account keytab for the Active Directory principal svc-centrifyjoin, created using the same methods as described earlier in this guide, the join operation can be scripted as follows:


# sudo /usr/share/centrifydc/kerberos/bin/kinit -kt /etc/svc-centrifyjoin svc-centrifyjoin@COMPANY.COM
# sudo adjoin --zone LinuxServers --force
# sudo kdestroy
# sudo shred --iterations=1 --remove /etc/svc-centrifyjoin.keytab 

Further tightening of security

As soon as the domain join has succeeded, the reset password permission can be revoked, in order to prevent the Active Directory principal from being used for performing a denial-of-service attack on any *NIX systems that it has the reset password delegation for.


For example, the script that pre-stages a new computer object could easily be expanded to revoke the service account's reset password privilege on any computer objects belonging to machines that already have been joined to the domain, that can be identified by having a value assigned to the operatingSystem attribute.


Note that system administrators may need the reset password delegation for legitimate purposes, such as to fix the computer trust in case there has been a problem with the system changing its machine password.


Addendum on pre-staging computer profiles for *NIX machines with existing Samba file server deployments

The above pre-staging scenario may not be a feasible solutions for machines that have an existing trust relationship with Active Directory, for example *NIX servers that host CIFS/SMB file shares using Samba. Using the proposed methods above, pre-creating the computer profile in the zone will reset the computer password, and break the trust relationship for the existing samba deployment.

In this case, you will want to re-use the existing computer object, and create the computer profile at join time, while making sure Samba can continue using the trust relationship when adjoin resets the machine password.

For more complex deployment scenarios, such as when joining machines that run Samba, Centrify Professional Services can help to implement Centrify with minimal impact on a production environment.


Addendum on pre-staging computer profiles for Windows machines running the Centrify agent

Although this is an article detailing the different join methods for *NIX machines to the Active Directory domain, the New-CdmManagedComputer CMDlet in the Access module for PowerShell can also be used to pre-stage Windows systems to a Centrify Zone.

As Windows systems can leverage existing procedures for joining the Active Directory domain, the PowerShell CMDlet only needs to create the computer profile, represented by the serviceConnectionPoint object in the zone.


The procedure to pre-stage the computer profile in a Centrify zone "WindowsServers" for an existing Windows system WinMember with distinguished Name "CN=WinMember,CN=Computers,DC=company,DC=com", will then be:


# Import-Module Centrify.DirectControl.PowerShell
# New-CdmManagedComputer -Zone (Get-CdmZone -name "WindowsServers") -WindowsComputer "CN=WinMember,CN=Computers,DC=company,DC=com"

On a Windows machine where the Centrify agent that is part of Centrify Server Suite 2016, has been installed onto, the Centrify Zone join operation would then look like this:

# "C:\Program Files\Centrify\Centrify Windows Agent\dzjoin.exe" /s

Note that the dzjoin.exe binary has been introduced with Centrify Suite 2016.