What you'll need Commercial users: All it is required to follow along is a Centrify zone and access manager with at least one AD group to map to a UNIX group. For each UNIX group ...
What you'll need
Commercial users: All it is required to follow along is a Centrify zone and access manager with at least one AD group to map to a UNIX group.
For each UNIX group that you need provisioned, you'll need an AD group.
Express users: Just like with users, the identity of a group is predetermined for you. The group's UNIX name will be the same as the group's sAMAccountName in AD, and the GID is generated uniquely based on the group's SID. All AD groups are visible to agents in Express (workstation) mode.
Unlike with Express, when using Centrify Standard Edition you have the flexibility to manipulate the UNIX name and GID of the group. This becomes important to retain existing naming conventions or to overcome the 8-character limitation in some legacy OSs.
Group Visibility: > Only UNIX-enabled groups (groups that have a unix-name and GID) in the target zone (or system) are visible to the OS. > Only UNIX-enabled users that belong to the UNIX-enabled group are actualmembers of the group. This is extremely important and a great advantage!!!! Example 1: This means that you can use a group membership in AD to control entitlements in Apps. E.g. If you use a Secondary UNIX group to grant Hadoop HDFS permissions, not only the user has to be UNIX-enabled, but the memberships are limited accordingly. Example 2: This avoids performance issues. There are many poorly written applications that make NSS calls like getgrent() or getpwent() that are extremely inefficient; by limiting the group memberships Centrify may give you a performance boost. These calls are extremely bad especially in Express mode.
AD + Centrify = a new way to look at UNIX groups.
UNIX architecture has stood the test of time, it's efficient and reliable; however when introducing newer technologies like AD, system administrators have to understand that there's many more efficient ways to do things because the "technical toolbelt" is wider. With Centrify in the picture, you should not look at UNIX groups the same way as before because:
Any group that was used for the purposes of controlling access to systems is obsolete and won't be needed anymore. For example, if you used the AllowGroups directive in SSH to control who could access a system, then that group is not needed.
Any group that was used for the purposes of granting system privileges is also obsolete. E.g. the wheel group to grant sudo rights.
This is because Centrify Zones and RBAC take care of this issue and augment capabilities that extend to granular PAM access, Fine-grained roles that can be also leveraged in Windows in addition to reporting and delegation.
Remember, the basic goal is Centralized Administration, access to systems and privileges can be now granted to user or group principals in AD.
In our experience, this is what we observe as a challenge for customers when trying to make the best use of Centrify; aside from the cultural differences between Windows and UNIX admins, applying UNIX principles alone won't necessarily produce the best solution; this is why we encourage customers to work together or use PS at least for training and design.
A little bit of planning
Just like we stated in the previous post, the right thing is to normalize. If that's not an option, leverage the ability to generate a GID based on the SID for new groups, and keep the "old GID scheme" for existing groups.
Is this group going to be deprecated?
Like outlined above. If the group is for access or privileges, discontinue its use. If you "fear the unknown" then keep it (but it will be redundant).
Group Provisioning Process
After all users and groups have been migrated, a process have to be put in place to provision (or deprovision) group memberships. There are several ways to do it:
Manually with Access Manager or Active Directory Users and Computers
Automatically via any Centrify-supplied utilities (zone provisioning agent), PowerShell, adedit
Automatically with your own program.
For example, with ZPA just by adding (or removing) an AD user to a group, they can automatically become members of the associated UNIX group.
Information to be gathered All it is required is a consolidated file with all groups in standard UNIX format. Access Manager can also extract information from a NIS file or from a Deployment Manager database. If you are normalizing your environment, you have to identify and fix inconsistencies like:
Groups with more than one GID
GIDs with different unix names
Groups with the same definition but different members
Plan SLAs for Group Visibility and Membership
Unlike authentication and password changes, group creation and group membership are LDAP changes in AD; therefore you have to think that these changes are NOT instantaneous. AD Topology, replication, network links, external systems and the Centrify agent cache are in play; otherwise you have the adflush command as a last resort.
The process is very simple:
Migrate Unix identities from source
For each Unix Group, either create or match an existing AD group reconcile group memberships with UNIX-enabled AD groups (optional) rationalize the GID (make it unique)
Cleanup (& normalize) local accounts
On the windows (AD) side
First, perform the import
Save the consolidated user list of /etc/group file in a windows-accessible location.
Open Access Manager and open the target zone that will receive the users.
Expand the zone and right-click the Unix Data node and select "Import from UNIX" and the import wizard will start in the Select Import Source page
Select UNIX configuration files and in the /etc/group file, browse to the appropriate source (e.g. groups.txt file) and press Next
Make the appropriate selections in the select import objects page and press next
Select "Store in AD" in the Select Destination page.
Review the summary page and press finish.
At this point, the UNIX identities of the users contained on the file have been imported to AD, the next step is to match the Unix profile with its corresponding AD user and accept the changes.
The process of mapping UNIX groups differs from the users process
Navigate to the Zone > Unix Data > Groups> Pending Import. You will see a list of objects that represent the Unix identities imported from the file.
Select all objects on the list, right click and select "Check Status" At this point, access manager will do the best job to match the UNIX group with an AD candidate. If you haven't previously created the groups with a similar name, this won't work.
Review each group Identity to: make changes in the properties or review the status and make sure that the import candidate is the appropriate group in AD. If there are no candiates, you can: a) Create a New AD group b) Extend (associate) with an existing AD group. c) Merge (collapse) with an existing UNIX group
Ensure consistency: - Membership consistency - the AD group should contain the UNIX-enabled AD users that belong to the UNIX group. - Normalize: ask yourself, should this user be a member of this group? is the user UNIX-enabled?
At this point accepted entries will be in the Unix Data > Users container (please refresh), and you can still make changes like re-generating a new GID based on the SID.
On UNIX/Linux Normalize (if needed) and remove local accounts
Optional: If you chose to normalize the namespace (or are using Express), then you have a problem. GIDs in AD are different than the local GIDs, therefore if you use regular UNIX permissions or extended ACLs, with the GID change, users will lose access to the files or services tied to them. Centrify includes another utility (adfixid) that recursively makes the changes in the file system as needed.
$ ls -l appfile.txt
-rw-rw-r-- 1 dwirth myapp 2622 Nov 27 12:04 appfile.txt
$ ls -lan appfile.txt
-rw-rw-r-- 1 1627391058 50004 2622 Nov 27 12:04 appfile.txt
$ adquery group myapp
No user-id conflicts were found.
1 group-id conflict was found.
Local GID(Name/Map) Zone GID(Name) Resolution ID Map
------------------------------ ---------------------- -------------- ------
50004(myapp) 1627391622(myapp) Use zone ID 1627391622
In this example, the file appfile.txt is ACLd for the myapp group. However, the myapp group has a different GID in the local system than the normalized AD GID; in that case, the adfixid utility can help us recursively change the file/folder ownerships in the system.
If you did not choose to change the GID scheme for the purposes of normalization, all you need to do is delete the local groups. Centrify offers a utility called adrmlocal that is built for that purpose.
No duplicated local users are found against AD users
1 local group(s) that are duplicated with AD groups:
myapp:gid(50004):ADgid(1627391622) Conflicted with AD
From this point on, to control the membership of the UNIX group, all you need to do is add/remove UNIX-enabled users from the corresponding AD group. This opens the door for automation, workflow, approvals, etc.