Background
In order to automate Active Directory instance joins and unjoins, we need a keytab file corresponding to an AD user that has the proper rights in AD and in the Centrify zone.
Because a keytab is pretty much a credential, we are going to adhere to the following principles:
- The credential for the keytab shall have least minimum access
- The password for the credential shall be unknown
- The keytab file shall always be deleted once it's used.
What you'll need:
- You may need assistance from your Active Directory lead
- Why? First and foremost separation of duties. Also, in practicality, the UNIX/Linux/Mac teams in enterprises are different from the AD teams.
- What do they need to do for me? They need to create an AD account, provide delegation (see below) and they may have to type their credential when running the adkeytab command.
- How many times do we need to do this? Only once.
Create an AD User
When you create an AD service account, you have to align with the security policy governing these accounts. The overhead can come depending on the frequency of password changes. Since adkeytab scrambles the password and it's effectively unknown, the account can be set with a Password Never Expires/User cannot change password flag, however for due-diligence you may rotate it once a year. Each time the password is rotated, the key table file has to be generated again.
- Open Active Directory Users and Computers
- Navigate to the container or OU for this service account
- Select New > User
- In the New Object form, set the information based on your naming convention
Note: the "common name" of the user is typically the same as the display name. If this contain spaces, you have to make note of this for when you use the adkeytab command (samaccountname vs cn). - In the New Object - User form, type a password and set the options according to your service account policy
Remember, if you do the right thing, adkeytab will randomize the password and this can be a compensating control. If you are required to change this password, you must re-generate the keytab and redistribute, otherwise your scripts or recipes will fail.
If you prefer PowerShell instead, you can use the New-ADUser commandlet.
Now you should have a service account. Make note of the username (e.g. ad-joiner) vs. the cn (AD Joiner Service Account).
Delegate Permissions
There are 2 delegations needed to make sure the automation of joins/removals works. The service account should be able to create/remove computer objects in your designated AD container for UNIX/Linux or Mac systems, plus if you're using Centrify zones, the system has to have the ability to join, remove and modify computer profiles.
Optionally, there's a third delegation related to Computer Roles (contained in AD groups); for this you need to provide the "manage group membership" delegation to the target groups (or OU that contains the groups).
Let's illustrate the steps using this OU structure
In this scenario, I plan to add the UNIX/Linux computers to the Servers SubOU under Centrify; this means that I have to delegate at that level to preserve the least privilege principle. In a real-world deployment, you may have a different layout (perhaps based on sites), in that case you have to delegate in multiple places.
To delegate the computer object in the target OU
- In ADUC (as a privileged AD user), right click the Servers SubOU and select "Delegate Control"
- Welcome Page > Next
- Users or Groups > press Add, find the service account, select and press OK, then Next
- Task to Delegate > Select "Create custom task to delegate" and press Next
- Object Type > Select "Only the following objects in the folder"; check the Computer Objects box and check Create and Delete.
- Permissions tab > Check "Full Control" under permissions and press Next.
You can dial this down, however we have this scoped down to the OU and type of object. - Completing page > Finish
Now the service account can create/remove computer objects in the Servers container.
To delegate at the Centrify Zone level
You must know all the Centrify zones that the service account will be leveraged for automation. In my example I have one zone (AWS). Centrify provides PowerShell to perform bulk delegations (see Set-CdmDelegation, in this link)
- Open Centrify DirectManage Access Manager
- If needed, open your target zone(s)
- Right-click the zone and select "Delegate Zone Control"
- Selected Objects > Press Add and find and select your service account, press OK and Next
- Tasks to Delegate > check join and modify computer operations to the zone (3 check boxes)
- Completing Page > Press Finish.
At this point, if you're not using DirectAuthorize Computer Roles you are done.
Note: You can always verify delegations by running the "Zone Delegation Report"
Optional: To delegate for Computer Roles
Computer Roles allow the grouping of systems as "teams of servers" this gives administrators the flexibility granting access/privileges to systems to multiple user populations, the only operation required is the the system is a "Member" of the Computer role, and this can be accomplished any time or during system setup by automating add/removal of the computer account into the AD security groups that make-up the computer role.
In my example, I'm leveraging the Centrify recommended OU structure and all my AD Security groups for the purposes of Computer Roles are stored in the Computer Roles SubOU under the Centrify OU. This means that I only need to make one delegation. Based on your design, this may vary and you may have to perform multiple delegations.
- In ADUC (as a privileged AD user), right click the Computer Roles" SubOU and select "Delegate Control"
- Welcome Page > Next
- Users or Groups > press Add, find the service account, select and press OK, then Next
- Task to Delegate > Select "Modify Membership of a Group" and press Next
- Completing > Press Finish
From this point on, the service account will be able perform add/removals of objects into any existing or new AD group in that container.
Create the Keytab File
Creating the keytab may require two individuals. One individual can run privileged commands on UNIX/Linux/Windows, the other is an authorized AD user that can perform certain operations on the AD user (like changing it's password).
You need to know the account's samaccounname vs the common name. You can quickly see this using the Attribute Editor in ADUC or PowerShell
This is important because the last parameter of the adkeytab command is the common name. If you assume they are the same, you may hit this error:
AD Object found: CN=AD Joiner,OU=Service Accounts,OU=Centrify,DC=awsrealm,DC=centrifying,DC=net Error: The account name does not match the SAM account name. You must supply both on the command line. Adkeytab return code: 23 Failed: Adopt Account: ad-joiner
Here's a simple way of constructing an adkeytab command
- Elevation required: root or credential for sudo or dzdo required: sudo adkeytab
- Operation: adopt (needs the sammacount name, an authorized account and the common name): --adopt
- Authorized user (e.g. AD administrator): --user admin
- AD user: --samname ad-joiner
- Keytab File name (e.g. login.keytab): --keytab login.keytab (the file will be owned by root)
- Common Name (if the CN is different from samaccount name): "AD Joiner" (since there are spaces, it has to be double-quoted)
- Verbose output recommended (-V)
Here's the command
dzdo adkeytab --samname ad-joiner --adopt --user admin --keytab login.keytab -V "AD Joiner"
Here's a sample output:
dzdo adkeytab --samname ad-joiner --adopt --user admin --keytab login.keytab -V "AD Joiner" [dzdo] password for lisa: ADKeyTab version: CentrifyDC 5.4.0-286 Options ------- use machine ccache: no domain: awsrealm.centrifying.net server: null user: admin container: null account: AD Joiner trust: no des: no admin@AWSREALM.CENTRIFYING.NET's password: Attempting bind to awsrealm.centrifying.net site:Default-First-Site-Name server:dc1.awsrealm.centrifying.net: ccache:MEMORY:0x644640 Bind successful to server dc1.awsrealm.centrifying.net Searching for AD Object: filter = (samAccountName=ad-joiner), root = DC=awsrealm,DC=centrifying,DC=net AD Object found: CN=AD Joiner,OU=Service Accounts,OU=Centrify,DC=awsrealm,DC=centrifying,DC=net Key Version = 4 Activating AD account: CN=AD Joiner,OU=Service Accounts,OU=Centrify,DC=awsrealm,DC=centrifying,DC=net. Clearing existing SPNs: No Account 'CN=AD Joiner,OU=Service Accounts,OU=Centrify,DC=awsrealm,DC=centrifying,DC=net' All SPNs already present Adding managed account keys to configuration file: AD Joiner Changing account 'AD Joiner' password with user 'rpimentel@AWSREALM.CENTRIFYING.NET' credentials. Searching for AD Object: filter = (samAccountName=ad-joiner), root = DC=awsrealm,DC=centrifying,DC=net AD Object found: CN=AD Joiner,OU=Service Accounts,OU=Centrify,DC=awsrealm,DC=centrifying,DC=net Key Version = 5 Updated properties to config file /etc/centrifydc/centrifydc.conf. Success: Adopt Account: AD Joiner
Verify the keytab is correct. List the principals
dzdo /usr/share/centrifydc/kerberos/bin/klist -kt login.keytab Keytab name: FILE:login.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 5 04/20/2017 17:49:43 ad-joiner@AWSREALM.CENTRIFYING.NET 5 04/20/2017 17:49:43 ad-joiner@AWSREALM.CENTRIFYING.NET 5 04/20/2017 17:49:43 ad-joiner@AWSREALM.CENTRIFYING.NET 5 04/20/2017 17:49:43 ad-joiner@AWSREALM.CENTRIFYING.NET 5 04/20/2017 17:49:43 ad-joiner@AWSREALM.CENTRIFYING.NET
Testing your Keytab for Join/Removal Operations
You can test the keytab by removing and rejoining Active Directory. You'll need to use kinit to authenticate with the key table file, then leverage adjoin or adleave to check the results. Optionally, you can use the --computerrole switch of adjoin to check for those operations.
Authenticating using the key table file
- Sign-in to your system with a privileged user (remember, the key table file is owned by root)
- Change directories to the location of the key table file.
- Run the kdestroy command
/usr/share/centrifydc/kerberos/bin/kdestroy - Run kinit with the kt option to get a TGT for the service account and klist to verify the TGT
sudo /usr/share/centrifydc/kerberos/bin/kinit -kt login.keytab ad-joiner [dzdo] password for lisa: $ /usr/share/centrifydc/kerberos/bin/klist $ dzdo /usr/share/centrifydc/kerberos/bin/klist Ticket cache: FILE:/tmp/krb5cc_cdc1702888528_Hw29E6 Default principal: ad-joiner@AWSREALM.CENTRIFYING.NET Valid starting Expires Service principal 04/20/2017 17:59:19 04/21/2017 03:59:19 krbtgt/AWSREALM.CENTRIFYING.NET@AWSREALM.CENTRIFYING.NET renew until 04/21/2017 17:59:20
Testing adjoin and adleave operations
Depending on the state of your system, you may test removal or joining first. Since my system is already joined, I'm testing removal first (note that I switched to ec2-user since I was logged in as an AD user). Note that I'm copying the centrify-populated krb5.conf file, since this file will be rolled-back once the system left the domain.
$ dzdo su ec2-user $ sudo cp /etc/krb5.conf . $ sudo adleave --remove Using domain controller: dc1.awsrealm.centrifying.net writable=true Left domain. Centrify DirectControl stopped.
Attempting adjoin to the Zone an the "Utility-Servers" computer role.
$ sudo env KRB5_CONFIG=krb5.conf /usr/share/centrifydc/kerberos/bin/kinit -kt login.keytab ad-joiner $ sudo adjoin --zone AWS --container ou=servers,ou=centrify --computerrole Utility-Servers awsrealm.centrifying.net Using domain controller: dc1.awsrealm.centrifying.net writable=true Join to domain:awsrealm.centrifying.net, zone:AWS successful Centrify DirectControl started. Initializing cache . You have successfully joined the Active Directory domain: awsrealm.centrifying.net in the Centrify DirectControl zone: CN=AWS,CN=Zones,OU=Centrify,DC=awsrealm,DC=centrifying,DC=net You may need to restart other services that rely upon PAM and NSS or simply reboot the computer for proper operation. Failure to do so may result in login problems for AD users.
What next?
At this point you have to distribute your key table file to your distribution points web server, repository, file share, etc. Note that this file needs to be deleted after it's used for added security. For example, you can upload this file to an AWS S3 bucket to use it with your AWS OpsWorks or CloudFormation scripts.
No comments:
Post a Comment