Planning Organizational Units and Security Groups

One of the important steps in planning a successful deployment of Server Suite is to consider how the software fits into your Active Directory infrastructure. This section describes the issues you should consider in the planning phase that affect how Active Directory and Centrify-specific objects are organized and suggests an organizational model you can use to successfully deploy Centrify within an existing Active Directory infrastructure.

If you are planning a deployment for managing and monitoring access to Windows computers, only Licenses and Zones parent containers is applicable and you can skip the other topics in this section. If you are planning a deployment that includes a mix of different platforms, however, you should review the recommendations for using organizational units (OUs) and groups.

If you plan to audit activity on any platform, Centrify recommends creating separate Active Directory security groups for auditors, administrators, and the computers that make up the audit and monitoring service infrastructure. Planning a deployment that includes the audit and monitoring service infrastructure requires additional resources and expertise. For more information about deploying auditing components, see the Auditing Administrator’s Guide.

Identifying Stakeholders and Business Processes

Deploying Server Suite requires you to add objects to the Active Directory forest and, in most cases, update business processes for provisioning and removing users. It is important to identify who will be affected, which processes will be updated, how planned changes affect different parts of the business, and when you plan to deploy as early as possible in the planning stage.

It is also important to contact one or more Active Directory administrators to establish who will be creating the necessary objects in Active Directory and communicate the permissions required to create and manage those objects. If internal policies only allow Active Directory administrators to create organizational units (OUs) or security groups, you may need to negotiate when those activities take place and who will own the objects after they are created.

Identifying the appropriate people and processes early in the project helps eliminate unnecessary delays to the deployment and adoption of Centrify software. Communicating how the deployment affects the user and administrative communities helps ensure you can deploy rapidly and complete the project on-time.

The single biggest obstacle to storing UNIX data in Active Directory is overcoming internal process issues, such as change control restrictions, naming convention requirements, or proper authorization to perform administrative tasks. If you identify and resolve these challenges at the start of the project, deploying Centrify software across the enterprise becomes a fairly straightforward and painless task.

If you are a UNIX administrator, keep in mind that changes to Active Directory often require a formal change request and approval process, which can take time and delay the project. The earlier you begin planning the changes to Active Directory and the appropriate separation of duties for managing UNIX objects before, during, and after migration, the more successful the deployment will be.

Designing Organizational Units for Centrify

You can store Centrify-specific objects anywhere in the Active Directory structure if you choose. However, Centrify recommends that you create a single, high-level organizational unit (OU) specifically for Centrify objects at or near the top-level of an Active Directory forest root domain. Using one high-level organizational unit simplifies the management of Centrify containers and UNIX data.

Consolidating all UNIX data under a single organizational unit also enables you to establish an appropriate separation of duties without affecting any other previously-established OUs or permissions in Active Directory and reduces the need for additional process documentation or training. The disadvantage is that there may be strict authorization policies against setting up new organizational units.

Selecting a Location for the Top-Level OU

If you plan to follow the Centrify recommendation to create a top-level organizational unit for Centrify-related objects, such as Linux and UNIX computers, this high-level OU should be named so that it is easy to identify. For example, name the OU Centrify or Centrify UNIX. In deciding where this top-level OU should be placed, you should review your current Active Directory infrastructure.

There are several common scenarios:

Single forest with a single domain
Single forest with an empty root domain
Single forest with account and resource domains
Multiple forests with trust relationships
Forests separated by a firewall (DMZ)

Single Forest with a Single Domain

If you have a single forest with a single Default-First-Site domain, you can create the top-level OU fat the same level as the default containers for Computers, Users, and other top-level objects. This is the simplest implementation of an Active Directory infrastructure. In this scenario, the top-level Centrify OU might look similar to this:

Single Forest with an Empty Root Domain

In this scenario, the forest root domain is used for the DNS namespace with one or more child domains that store information about computers, users, and groups. This is the most common Active Directory implementation. There are two important considerations if this is your Active Directory infrastructure:

It is likely you will have a disjointed DNS namespace that you will need to resolve when you join computers to the domain.
You might want to use multiple top-level Centrify OUs for the site. For example, assume the empty forest root domain, sidebet.org, contains three child domains:

us.sidebet.org

europe.sidebet.org

asia.sidebet.org

In this scenario, you might have a top-level Centrify OU in each child domain that includes UNIX computers to allow for more efficient data management and delegation of administrative tasks. However, if the child domains are centrally managed, you might want to create a single OU for Centrify in the forest root or one of the child domains. In general, you should base your decision on who will be responsible for managing the Centrify objects. If there are separate administrative groups for each child domain, create a top-level Centrify OU in each child domain.

Single Forest with Account and Resource Domains

In this scenario, the forest root domain has at least two child domains. One child domain stores computer principals and related information. This domain is the resource domain. Another child domain stores the user and group principals. This domain is the account domain. This scenario requires a trust relationship that allows the computers in the resource domain to trust the users and groups in the account domain. If this is your Active Directory infrastructure, you should store the Centrify data in the resource domain. For example, if the root domain, sidebet.org, contains the child domains accounts.sidebet.org and resources.sidebet.org, you would define the top-level Centrify OU in the resources.sidebet.org (OU=Acme,DC=resources,DC=sidebet,DC=org).

Multiple forests with Trust Relationships

In this scenario, you have more than one forest needing access to Centrify data. If you have multiple forests in your organizations, you should create the top-level OU for Centrify in the forests that have UNIX computers. The forests must also be configured with either a one-way or two-way trust relationship. Cross-forest authentication requires a forest functional level of Windows Server 2003 or later. Trust relationships that involve Windows NT 4.0 domains or Kerberos V5 realms are not supported.

Cross-forest Authentication for Two-way Trust Relationships

For forests that have a two-way trust relationship, users from either forest can be authenticated to log on to the other forest. For example, if you have configured a two-way trust relationship between the forest root domain sidebet.org and youbet.org, and there are both UNIX computers and UNIX users in both forests, you would create one top-level Centrify OU in each forest and users from either forest can be authenticated to the computers in either forest.

Cross-forest Authentication for One-way Trust Relationships

To allow for cross-forest authentication with a one-way trust, Centrify authenticates users in the trusted “accounts” forest to allow those users to log on to computers in the “resources” forest. Users in the trusting “resources” forest cannot log on to computers in the “accounts” forest.

For cross-forest authentication with a one-way trust, when you add the user from the “account” forest to the Centrify zone, the user’s samAccountName attribute is stored in the zone object. Therefore, once the user is added to the zone, their samAccountName cannot change without causing authentication to fail.

Analyzing Trust Relationship to Prevent Authentication Failures

If your Active Directory environment does not permit one- or two-way trusts between forests, however, or uses a complex combination of one-way and two-way trust relationships between forests, users who attempt to log on from a remote forest may be denied access if the forest they are logging on to or the forest they are logging in from do not share a trust relationship.

As part of your deployment planning you should review your entire Active Directory infrastructure and determine whether you will be authenticating users from multiple forests and how trust relationships are defined for the forests users need access to. You may want to change the trust relationships you have defined.

For information about configuring trust relationships, see your Active Directory documentation.

Forests separated by a firewall (DMZ)

If you have a firewall between a forest outside of the firewall (the perimeter or DMZ forest) and a protected forest inside the firewall (the internal or corporate forest), the best security practice is to make the DMZ a separate forest with no trust relationship.

In this scenario, the top-level Centrify OU is created in the corporate forest protected by the firewall. This configuration ensures that the domain controllers in the perimeter forest cannot compromise the corporate domain controllers or get access to the corporate global catalog (GC), which stores information about all domains in the forest. Although defining no trust relationship between the perimeter forest and the corporate forest is considered the best practice for security reasons, this configuration prevents authentication through the firewall.

If you want to enable authentication for users in the corporate forest and allow them to access resources in the perimeter forest, Centrify recommends that you create a separate Active Directory forest for the computers to be placed in the network segment you are going to use as the demilitarized zone. You should then establish a one-way outgoing trust from the internal forest to the DMZ forest. For more information about deploying Centrify in a DMZ, see Planning to deploy in a demilitarized zone (DMZ).

Creating Recommended Organizational Units

In addition to the top-level Centrify OU, Centrify recommends you create several additional organizational units for managing UNIX groups, users, and computer accounts and rights and roles. These additional organizational units are intended to help you establish an appropriate separation of duties before, during, and after migration.

Centrify recommends the following organizational units as a starting point:

Centrify Administration
Computer Roles
Computers
Provisioning Groups
Service Accounts
UNIX Groups
User Roles

Creating Organizational Units In Access Manager

If you want to create the recommended organizational unit structure for Centrify objects during your initial deployment, you can do so automatically using the Access Manager Setup Wizard. The first time you start Access Manager, it opens the Setup Wizard by default. From the Setup Wizard, you can create all of the containers for the recommended deployment structure automatically without any manual configuration. Alternatively, you can create a completely custom deployment structure by first creating a PowerShell script that creates the containers you want to use then running the custom script from within the Setup Wizard.

If you use the default script, the wizard adds the recommended organizational units and groups under the top-level Centrify OU and ensures all of the permissions are properly set on the objects within it. You can then select an existing organizational unit or create a new organizational unit for the components of the deployment structure. If you use the default deployment script without modification, it creates a structure like this:

If you want to customize the script, you can use the wizard to export it. After exporting the script, you can modify it in a text editor, then restart the wizard to use the modified script. The Setup Wizard will also create the parent container for Licenses and the parent container for Zones in the Active Directory location you select.

As you roll-out the deployment, you might find additional OUs are useful. For example, you might create additional OUs because specific permissions must be granted to create, modify, delete, and manage the objects within them. By creating this organizational structure, you can control who has permission to manage the Centrify objects contained in each OU.

By using the recommended deployment structure and associated permissions, you will have a solid foundation for deploying Centrify software across the enterprise without affecting any of your existing Active Directory structure. The recommended deployment structure will also enable you to easily apply group policies and manage user, group, and computer accounts.

For more information about the purpose of the additional organizational units, see the appropriate section.

Centrify Administration Organizational Unit

The Centrify Administration OU is intended to store Active Directory security groups that ensure the separation of duties and the segregation of Centrify-related administrative operations in Active Directory.

In most cases, you will want to allow your existing Active Directory account fulfillment or provisioning team to edit UNIX groups and, potentially, the user role groups that allow for elevated permissions in UNIX. If users you have identified as Centrify Administrators are stored in the same organizational unit as the rest of the UNIX groups, then members of the fulfillment or provisioning team could grant themselves permissions to create, modify, and delete zones. With these permissions, a disgruntled provisioning staff member could delete one or more zones and prevent access to production computers. To prevent this security risk, Centrify recommends you create a separate Centrify Administration organizational unit and protect access to it.

Computer Roles Organizational Unit

The Computer Roles OU is intended to store the computer group accounts that are associated with a specific computer role. For example, if you plan to have a computer role for computers that host Oracle databases and the set of users assigned the database administrator role, you might create an Active Directory security group called Oracle_Production_Computers in this OU for the computers that host Oracle databases. If you were to add a new Oracle database instance, you would add the computer account for that database server to the Oracle_Production_Computers in this OU.

In most cases, the computer groups in this organizational unit are associated with the user role groups you add to the User Roles OU. For example, if you have a computer role for computers that host Oracle databases, you might have user role groups for database administrators and another user role group for database users. If you were to change who should be allowed to use the database or perform database administration activities, you would modify the membership of these two user role groups.

Computers Organizational Unit

The Servers OU is intended to store new computer principals in Active Directory. This organizational unit enables you to efficiently deliver computer-based group policies from Active Directory. For example, you can use a group policy to turn off SNTP updates from Active Directory for Centrify-managed computers to prevent those computers from having two registered time sources. Having a separate OU also enables you control who has the permissions and authority to create, update, and delete computer objects in the domain.

Provisioning Groups Organizational Unit

The Provisioning Groups OU is intended to store Active Directory distribution groups that are used by the Zone Provisioning Agent. The Zone Provisioning Agent is a Windows service that processes the business rules for creating or deleting UNIX profiles in zones. For example, if a new Active Directory user principal is in one of these group principals, and the group is associated with a zone, the user is automatically provisioned with a UID and a GID in that zone.

The profile does not allow the user to log on to computers in the zone. Identity management is separate from access management. The user’s role assignments control access.

During the migration process, users you have identified as Centrify Administrators should have the appropriate permissions and authority to create, delete, and manage the membership of these Active Directory distribution groups. After migration, the team that owns the process for the provisioning UNIX accounts will need the same permissions and authority. For details about the permissions required to perform these tasks, see Setting permissions for zone groups.

Service Accounts Organizational Unit

The Service Accounts OU is intended to store the Windows service account for the Zone Provisioning Agent and any UNIX-specific service accounts that do not correlate to existing Active Directory user accounts. For example, you can use this OU for application service accounts, such as Oracle or MySQL, to enable centralized password management and auditing. By migrating service accounts from UNIX, you can centrally manage the account information, passwords, and privileges for those service accounts and their associated UNIX groups.

Unix Groups Organizational Unit

In this deployment model, the UNIX Groups OU is intended to store Active Directory security groups that are migrated from /etc/group files or NIS group maps that you want to preserve.

As part of the initial migration, you should identify one or more users as Centrify Administrators who should be granted the appropriate permissions and the authority to create new Active Directory group principals, and to add Active Directory user principals to the new groups.

After the migration is complete, another team might be responsible for managing the UNIX groups migrated into Active Directory. The team that owns the process for adding UNIX users to a UNIX group, removing UNIX users from a UNIX group, or creating new UNIX groups will need the permissions and the authority in Active Directory to create and delete group principals and manage the membership of those group principals in this OU (for example, ou=unix groups,ou=Centrify). For details about the permissions required to perform these tasks, see Setting permissions for zone groups.

User Roles Organizational Unit

The User Roles OU is intended to store Active Directory security groups that are associated with user role definitions that grant privileges or restrict access. For example, a user role definition might grant permission to execute commands as root or using a service account such as oracle. By associating an Active Directory group with a role definition, you can grant or deny privileges by managing Active Directory group membership.

During the migration process, users you have identified as Centrify Administrators should have the permissions and the authority to add users to the appropriate user role groups and to create new Active Directory group objects in the OU (for example, ou=user roles,ou=Centrify). After migration, your organization should decide who should be responsible for creating new user role groups and associating them with zones and who should be able to add and remove users from the User Roles organizational unit.

Licenses And Zones Parent Containers

Regardless of whether you choose to create the organizational units for the recommended deployment structure or a custom deployment structure, Centrify requires the following parent containers:

Licenses parent container object for license keys. You must have at least one parent container for license keys in the forest. You can create more than one of these container objects to give you more granular control over who has access to which licenses.
Zones parent container object for individual zone (ZoneName) objects. You must have at least one parent container for zones. You can create more than one parent Zones container to give you more granularity for delegating administrative tasks.

You can select the parent containers for Licenses and Zones when you run the Setup Wizard, when creating a new zone, or when managing licenses in Access Manager.

Some organizations prefer to create and manage Active Directory objects manually to ensure tight control over the objects and their attributes. For example, you might want to manually create separate parent containers for different business departments or locations if you want to manually set permissions and refine who has access to them. However, managing permissions manually can be complex and error-prone. In most cases, Centrify recommends that you establish appropriate permissions on the deployment structure and use the Zone Delegation Wizard to manage administrative permissions on individual zones and the objects contained in zones.

Security Groups To Manage Centrify Information

If you use the default recommended deployment script, the script automatically creates the following Active Directory security groups for managing Centrify-related objects:

CentrifyAdministrators
AuthorizationManagers
ComputerManagers
UnixDataManagers

Each security groups is granted the appropriate permissions to perform specific administrative tasks. For example, users who are members of the Centrify Administrators group should be able to create, modify, and delete zones.

If you are not using the recommended deployment script, you should create similar security groups for managing Centrify-related objects.

Delegating Control For Centrify Administrators

The CentrifyAdministrators security group is intended for members of the administrative or security team who are responsible for managing all Centrify-related information stored in Active Directory. You should add members to the group to grant specific users the rights required to manage Centrify licenses, zones, user roles, computer roles, provisioning groups, and the user, group, and computer profiles in each zone.

Members of the Centrify Administrators security group are responsible for identifying an organization’s zone requirements and creating the zone hierarchy. Centrify Administrators also decide when to create new zones, delete obsolete zones, or consolidate existing zones. In most cases, Centrify Administrators define the basic access rights for zones and delegate administrative tasks to other users and groups on a zone-by-zone basis.

Permissions for the Centrify Administrators group are applied at the top-level of the deployment structure—for example, ou=Centrify—and grant privileges on the organizational units, containers, and object within the deployment structure. If you don’t create this group or a similar security group, only members of the Domain Admins group can create new zones.

If you are managing security and individual permissions manually for Active Directory objects, see Permissions required for administrative tasks for information about the permissions required for individual tasks.

Delegating Control For Authorization Managers

The AuthorizationManagers security group is intended for members of the security team who are responsible for managing role-based access rights. You should add members to the group to grant specific users the rights required to manage user roles, computer roles, access privileges, and role assignments.

You can delegate tasks to the AuthorizationManagers group on the User Roles and Computer Roles organizational units using Active Directory Users and Computers. You can delegate zone administration tasks to the group in Access Manager.

Delegating Tasks For User Role Groups

In Active Directory Users and Computers, select the User Roles organizational unit, right-click, then select Delegate Control to start the Delegation of Control Wizard. Select the security group you are using for authorization managers and delegate the following tasks:

Create, delete and manage groups
Modify the membership of a group

Delegating Tasks For Computer Role Groups

Create, delete and manage groups
Modify the membership of a group

Delegating Zone-specific Tasks

As a member of the CentrifyAdministrators security group, you can grant zone-specific permissions to the members of the AuthorizationManagers group. After you have created the appropriate zones, you can delegate the following zone administration tasks to authorization managers:

Manage roles and rights
Manage role assignments
Modify computer roles
Add computer roles

Delegating Control For Computer Managers

The ComputerManagers security group is intended for members of the UNIX administration team who are responsible for managing computer accounts. You should add members to this security group to grant specific users the rights required to manage computer objects in the Servers organizational unit in Active Directory.

As a member of the CentrifyAdministrators security group, you can also grant zone-specific permissions to the members of the ComputerManagers group. After you have created the appropriate zones, you can delegate the following zone administration tasks to computer managers:

Join computers to the zone
Remove computers from the zone

Delegating Control For Unix Data Managers

The UnixDataManagers security group is intended for members of the UNIX administration team who are responsible for managing computer accounts. You should add members to this security group to grant specific users the rights required to manage UNIX users and groups objects in the UNIX groups and Service Accounts organizational units in Active Directory.

You can delegate tasks to the UnixDataManagers group on the UNIX Groups and Service Accounts organizational units using Active Directory Users and Computers. You can delegate zone administration tasks to the group in Access Manager.

Delegating Tasks For Unix Groups

In Active Directory Users and Computers, select the UNIX Groups organizational unit, right-click, then select Delegate Control to start the Delegation of Control Wizard. Select the security group you are using for UNIX data managers and delegate the following tasks:

Create, delete, and manage groups
Modify the membership of a group

Delegating Tasks For Service Accounts

In Active Directory Users and Computers, select the Service Accounts organizational unit, right-click, then select Delegate Control to start the Delegation of Control Wizard. Select the security group you are using for UNIX data managers and delegate the following tasks:

Create, delete, and manage user accounts
Reset user passwords and force password change at next logon

Delegating Zone-Specific Tasks

As a member of the CentrifyAdministrators security group, you can also grant zone-specific permissions to the members of the UnixDataManagers group. After you have created the appropriate zones, you can delegate the following zone administration tasks to UNIX data managers:

Add users
Add groups
Remove users
Remove groups
Modify user profiles
Modify group profiles

Planning for Data Storage in Active Directory

Centrify stores all of the UNIX attributes required for users, groups, and computers in Active Directory, so that this information can be centrally managed. It stores these attributes without requiring you to make any modifications to the Active Directory schema you choose to use.

Changing The Zone Type

If you create a new zone using the default zone options, the new zone is created as a hierarchical zone that uses the Active Directory RFC2307-compatible schema attributes for user and group profiles. If you deselect the Use the default zone type option, you can choose to create either a hierarchical zone or a classic zone and how you want zone information stored in the Active Directory schema.

If you are not using the default zone type and storage model, you have the following options:

A Standard zone stores user and group attributes in the keywords attribute of the serviceConnectionPoint object for the user or group rather than in the user or group object.
An RFC2307-compatible zone stores user and group attributes in the attributes that are defined in the RFC2307-compatible schema for user and group objects.
An SFU zone stores user and group attributes in the Services for UNIX (SFU) schema attributes for the user or group object.

It is worth noting that in the default zone storage model—which uses the default Active Directory RFC2307-compatible schema—some schema attributes are not indexed. For example, in the default Active Directory RFC2307-compatible schema, the uid attribute is not an indexed attribute. Because of this limitation, queries that use this attribute might take longer than expected.

Modifying Indexed Attributes For Zones

Depending on the requirements of your organization, you might see improved performance either by creating standard Centrify zones rather than RFC2307-compatible zones or by indexing the uid attribute in default zones. Before selecting a strategy for all or selected zones, however, you should consider that indexing the uid attribute requires you to modify the Active Directory schema.

Modifying the Active Directory schema is an advanced operation that should only be performed by experienced administrators. In addition, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory or been delegated similar authority to perform this operation. If you choose to modify the schema to improve performance, you can use “Run as ...” to select an account with appropriate permissions before performing the following steps.

To index an attribute:

Open a Command Prompt window, then type the following command to register the schema management assembly on your computer:

regsvr32 schmmgmt.dll
Click Start, click Run, type mmc /a, then click OK.
In the console root, select the File menu, then click Add/Remove Snap-in.
Under Available Standalone Snap-ins, double-click Active Directory Schema, click Add, then click OK.
On the File menu, click Save, navigate to the %systemroot%/Sytem32 directory, type a file name for the console, then click Save.
Click Start > All Programs to select the Administrative Tools folder, right-click, then select Open.
- If necessary, select Organize > Layout > Menu bar to display menus.
- On the File menu, select New, then click Shortcut.
- In the Create Shortcut Wizard, click in Type the location of the item, type the name you used for the file in Step 5, then click Next.
- Select the file name in Type a name for this shortcut field, type Active Directory Schema, then click Finish.
Click Start > All Programs > Administrative Tools to select Active Directory Schema, right-click, then select Open.
Expand Attributes to select a specific attribute, such as uid, right-click, then select Properties.
Select Index this attribute, then click OK.

Viewing and Manipulating Data in Active Directory

You can view, access, and manage any information stored in Active Directory—including Centrify profiles, rights, roles, and role assignments—using ADSI Edit or using any tools that can perform standard LDAP operations such as ldifde and OpenLDAP commands such ldapsearch, ldapadd, ldapdelete and ldapmodify. For example, depending on the type of operating system and tools you prefer to use, you might view and manage Centrify profiles and zones using any combination of the following tools:

Access Manager
Access Module for Windows PowerShell
Audit Module for Windows PowerShell
Active Directory Users and Computers
The Server Suite Windows API
The ADEdit Tcl application and procedure library
Centrify command-line programs

By using these tools, you can manipulate Centrify information manually or create scripts to automate key tasks such as the provisioning of new accounts. For example, you can write scripts that access the Centrify Windows API or ADEdit procedures to automatically create computer, user, or group accounts, create new zones, or assign users to roles. As part of your planning process, you should determine whether there are tasks you want to automate through the use of scripts, so that members of the development team can create or modify the appropriate tools and test them thoroughly before deploying across the organization.