11 April,19 at 11:51 AM
Overview
Now, administrators can leverage the same convenient, centralized management capabilities inside of Access Manager that they use to manage end user accounts stored in Active Directory. Not only can they provision these local accounts on a large scale of UNIX/Linux computers, but they can perform the same task on individual computers, and they can control the state of these accounts dynamically.
Zone-based local user and group managment is supported on:
Implementation
As you can see from the following snapshot, management of local users and groups was added seamlessly to the existing UNIX Data node in the Access Manager console. Since the feature is also included for Computer Zones, you will see the same Local Users and Local Groups option under each Computer.
The default management behavior changed with the Centrify Server Suite 2016.1 release, and in order to begin managing local users and groups, you will first have to set the following local/group policy to true (it is false by default):
# adclient.local.account.manage
To enable this group policy for a particular Active Directory OU, you will need to set it at the following location:
Computer Configuration > Centrify Settings > DirectControl Settings > Local Account Management > Enable local account management feature
In addtion to these new group policies, there is a new command call admanagelocal (/usr/share/centrifydc/bin) that can be used to check management status, perform an immediate synchronization of the local users and groups, and view the attributes associated with those accounts.
The adedit utility has also been updated to include the list, add, delete, select, and get functions in order to perform additional automated management of local users and groups from the command line.
Example
Now, let's work with a simple example and see this feature in action. To provision a new local user and/or group in a particular zone, simply rt-click on the Local Users or Local Groups node under UNIX Data, and select "Add User to Zone...".
You will then define the UNIX attributes for the local user and select the "State" of the account. The State allows you to control the availability of the account and entails one of the following options:
Once the Local User is provisioned in Access Manager, you have the choice of waiting for the next refresh interval, which is controlled by the following group policy:
# adclient.refresh.interval.dz (located @ Computer Configuration > Centrify Settings > DirectControl Settings > Network and Cache Settings)
Alternatively, you can execute "admanagelocal -R" per the following screenshot, which will immediately synchronize the Local User and Local Group Zone data to all of the computers located in the Zone:
NOTE: You can use Delegate Zone Control to delegate both add local users/groups and remove local users/groups.
Once all of your local service accounts/groups are provisioned with the required State, you will still need to set the initial password, and optionally manage the password, for those accounts. You have 3 different options to set the passwords:
1) You can use a shell script to execute the passwd command on each Zone computer. You can either execute this script manually or enable the policy "adclient.local.account.notification.cli" to execute the script automatically when local accounts are refreshed.
NOTE: This is the least secure way to set passwords for local users, because the same password is assigned to each user when the script runs.
2) You can use the Centrify Privilege Service (CPS) to manage your local account passwords. Note that using CPS requires a subscription in the service if you are not an existing customer. CPS includes a CLI Toolkit which allows you to automatically add the Local User account to the service and set a random password. You would leverage a shell script, which would call the appropriate Toolkit command to set the password and then enable the adclient.local.account.notification.cli policy to execute the shell script automatically when local accounts are refreshed.
3) If you already have your own 3rd-party password manager, you can perform the same type of mangement as option #2 above but with your own solution.