The information (in red) in this JSON file is based on my example configuration: CENTRIFY_REPO_CREDENTIAL is the cyphered username/password combination assigned to you in the Centrify Download repo page. CENTRIFY_ZONE_NAME is the name of the Centrify Zone in AD that I want my Linux systems to be joined to CENTRIFY_KEYTAB_S3_BUCKET is the name of the S3 bucket that contains the login.keytab file for the service account. CENTRIFY_ADJOIN_ADDITIONAL_OPTIONS: has been set with the --container option that points to the DN of where my service account can add computer objects (e.g. ou=servers,ou=centrify)
Press Add Stack
Add a Layer
The desired state is that when the system is launched, the Centrified system is joined to AD and to the Zone. Once the system is shutdown, the system leaves AD, the Centrify license is freed and the access/privilege reports reflect the proper information.
In your newly-created stack, click on layers and press Add Layer
Give it a name and a short name and press Add Layer
In the layers, click on Recipes tab, this will display the Custom Recipes lifecycle
Setup box: centrify_agents::deploy_centrifydc
Shutdown box:centrify_agents::undeploy_centrifydcPress Save
On the Network tab, select the option based on your AWS VPC setup (e.g. Public IP addresses yes)
On the Security tab, press Edit and in Security Groups select your Security group EC2 Instance Profile select the IAM Role created in the previous step (e.g. Centrify-IAM-Role-4EC2)
Adding instances to your stack
Adding instances is the opportunity to debug your newly-created stack recipes.
In your stack, click Instances and click Add an Instance
Hostname: give it a name (e.g. test1)
Size: select a size (e.g. t2-micro)
Subnet: select a subnet from your VPC (must have AD connectivity and DNS resolution)
Press Add Instance
Troubleshooting and Debugging
Your troubleshooting can happen from the OpsWorks console. If there's an issue with your setup, the console will provide you with an error and a log with the actions yielded by Chef. For example, while debugging, I saw this issue:
Note that the erros will be quite explicit. The category of errors that you'll see may be dependent on the sanity checks that you perform along the way.
Invalid CENTRIFYDC_ADDITIONAL_PACKAGES attribute: the JSON value contains an invalid value. Valid entries include: centrifydc-openssh, centrifydc-ldapproxy, etc. Modify the value of the custom JSON attributes in the stack.
Either user your-user@YOURDOMAINNAME. does not have sufficient permissions to update the YOUR_ZONE zone computer information: this means that the service account can't create the computer object in the target container. Note that if you did not modify the JSON parameter for the stack called CENTRIFY_ADJOIN_ADDITIONAL_OPTIONS to have the --container switch with the proper DN, adjoin will try to add the system to the default computers container in AD. This is atypical.
Verifying Success - Provisioning
The layman's test is to be able to sign-in to the system and perform privilege elevation
The OpsWorks console shows the system online.
In Active Directory, there should be a computer object in the target OU:
Attestation reports can be generated with who has access to which system(s), what type of access they have, what privileged commands they can run, and where the privileges came from.
Verifying Success - Deprovisioning
The best test here is to stop the system and verify that the objects don't exist in AD and the system no longer is present in the Access/Privilege reports.
You can leverage Centrify's Github https://github.com/centrify/ for different private and public cloud configurations. This scenario is only the first of many to come.
Setting a Centrify AWS Test Lab:http://centrifying.blogspot.com/2017/04/building-test-lab-centrify-capabilities.html