Managing zones
Zones are the key component for organizing identity attributes, access rights and role assignments, and delegated administrative activity for Linux and UNIX computers. This chapter describes how to use Access Manager to create zones and manage zone properties and explains the advantages of using hierarchical zones. It also shows how to manage without zones by using Auto Zone.
The following topics are covered:
Understanding Centrify zones
Using the Access Manager Setup Wizard Creating a new parent zone
Creating a child zone Opening and closing zones
Delegating control of administrative tasks Setting zone properties
Renaming a zone
Changing the master domain controller Adding a computer to a zone
Changing the location of a zone in Active Directory Provisioning user and group profiles automatically Running reports for zones
Searching for profiles in a domain Connect to a domain using Auto Zone
For more detailed information about zone types, different strategies for using zones, and planning the migration of existing users and groups to zones, see the Planning and Deployment Guide.
Understanding Centrify zones
A Centrify zone is similar to an Active Directory organizational unit (OU) or Network Information Service (NIS) domain. Zones allow you to organize the computers in your organization in meaningful ways to simplify account and access management and the migration of information from existing sources to Active Directory.
Understanding Centrify zones
How you use zones, depends primarily on the needs of your organization. In some
organizations, a single zone is sufficient. In other organizations, using multiple zones might be a necessity.
Although using multiple zones can provide flexibility for managing user accounts and computer access, you are not required to do so. Creating a single zone, or for that matter, multiple zones, can be done simply through the Administrator’s Console or by using ADEdit. You only need to be concerned with planning and populating additional zones if multiple zones would be useful for your organization. You can then create the additional Centrify zones as you need them.
On the other hand, you may choose to define no zones at all by connecting to a domain through Auto Zone. With Auto Zone, every Active Directory user and group defined in the forest, as well as any users defined in a two-way trusted forest are valid users or groups for the joined computer.
Understanding identity and access in hierarchical zones
Centrify supports the creation of a hierarchical zone structure of parent and child zones that allows for the inheritance of data from the top to the bottom of the tree. This section explains how you can use this hierarchical structure to maintain identity and control access to a UNIX environment through Active Directory, but it begins from the perspective of a single, self-contained zone, then expands to include how user management works in a hierarchical structure.
After you create a zone you can add any of your AD users to it and define their identity in UNIX for any computer that joins the zone. To define an AD user’s UNIX identity, you create an NSS profile that contains the same data as the /etc/passwd file on a UNIX
computer: login name, UID, primary group, etc.
In addition, you can control access to computers in a zone by assigning roles to AD users, either individually or through AD groups. In fact, you must assign roles to users for them to have access to Centrify-managed computers. A user with an identity, and a role assignment in a zone, is considered an effective user for that zone. Users with an identity but without a role, have no access to a managed computer.
The ability to define identity separately from access is one of the key features provided by hierarchical zones. Its utility is not immediately obvious in a flat zone structure, but as you will see, it is a powerful feature in a tree structure.
Hierarchical zones
In a hierarchical-zone structure, identity and access are determined in much the same way as for a single zone, except the zone tree determines who users are and what access they have. When a computer joins a domain, the profile and access settings (role assignments) in effect for the zone determine who can access the computer and their identities on the computer. In a zone hierarchy, the profiles and access definitions may be defined in the
Understanding Centrify zones
zone, inherited from a parent zone, or defined specifically for the joined computer, and it is all of these together that determine a user’s profile and access.
Note In a zone hierarchy, in addition to parent zones and child zones, you have to take into
account the actual joined computers. If you think in terms of nodes, a parent node can have child nodes, a child node has a parent and may have a child node or may be a leaf node (at the bottom of the tree), while a computer node is always a leaf node.
Inheritance of identity information
Of course, the most prominent feature of a hierarchical zone structure is inheritance. Both identity and access control flow down the hierarchy, from parent to child to leaf nodes — though how inheritance works is different for identity and access.
For identity, the salient points are:
Profile data can be defined at any level, parent, child, or computer.
It is possible to define a partial profile at any level, that is leave one or more of the NSS
fields blank. A complete profile is required to have access to a computer, but a profile in a child zone can complete the missing fields from the parent zone.
Profiles are inherited down the tree but profile definitions in a child zone override the
definition in the parent zone, and computer-level definitions override both the joined zone and any parent definitions. Computer-level profile definitions are also known as computer-level overrides.
From this viewpoint, when considering which users have an identity for a particular zone or joined computer, it makes sense to talk about the profile tree, rather than about the users or profiles defined in the zone.`
Practically, this scheme solves some of the classic problems of managing a heterogenous UNIX environment, such as creating a unified name space. For example, in a typical UNIX environment, the same user may have different UIDs on different computers. You can address this problem by defining a user profile for a zone while overriding just the UID field in the profile for that user on one or more specific computers that have joined the zone. Another practical application is to override home directory and shell defaults on specific computers, for example, on a Mac OS X computer, you can specify the home directory as / User rather than /home, or you could specify a shell such as /bin/bash for a zone, but
override it with /usr/bin/ksh on an AIX computer that joins the zone.
Inheritance of access
Access data is also inherited, and role assignments can be made at each level of the
hierarchy. However, role assignments do not override each other. Rather they accumulate, such that a user’s potential rights include all the rights granted by all the role assignments in the access tree. The reason these are potential rights is that rights granted to a user by a role assignment are only effective if the user has a complete profile defined for a zone.
Using the Access Manager Setup Wizard
In other words, when a computer joins a zone, the profile tree determines a pool of potential users, and the access tree determines a different set of users with rights, and where the two intersect is the set of effective users.
In practice, defining access and inheritance separately allows quick and easy provisioning of a UNIX environment. For example, one approach is to add your entire store of AD users to a parent zone. Then, in child zones, make role assignments to specific users. The parent zone functions as a pool of users and the child zones define the functions that users. On the other hand, you can identify the user accounts you want to assign to particular roles and actually make the role assignments, for example by assigning a role to an AD group. However, until you create profiles for users in the group, the role assignments confer potential rights only.
How to use zones
Although it is recommended that you use zones in a hierarchical structure (see the Planning and Deployment Guide for detailed instructions about creating a hierarchical zone structure for your UNIX environment) creating one or more hierarchical zones does not mean that you must create a hierarchical structure, it simply means that you may do so if it makes sense for your organization. You are still free to create a single zone, or multiple zones in a flat structure.
On the other hand, for new zones, it is recommended that you always create a hierarchical zone, not a classic zone, unless you are trying to maintain compatibility with an
environment that contains zones created by a previous version of Centrify software. For example, if you are running a previous version of the Centrify UNIX agent that does not support hierarchical zones, you would need to create classic zones. Otherwise, even if you do not intend to create a zone hierarchy, hierarchical zones are the best choice because they provide many features not available in a classic zone.
This chapter explains how to create and manage zones but keep in mind that most of the impact of using hierarchical zones occurs in user identity (see Chapter 9, Managing user profiles) and user access (see Chapter 10, Authorizing users). Those chapters explain in great detail how to manage user identities and access in a multi-layered zone structure.
Note Centrify Server Suite provides other ways of modeling the functioning of your UNIX
environment. For example, computer roles allow you to link a group of users and role assignments to a dedicated group of computers, such as those hosting a database.
Using the Access Manager Setup Wizard
The DirectManage Access Manager Setup Wizard starts automatically the first time you start the Access Manager console. In most cases, the only time you need to run the Setup Wizard is to perform this initial configuration of the Active Directory forest. You can, however, use the Setup Wizard after the initial configuration if you want to change your
Creating a new parent zone
configuration. For example, if you want to change the location of the default container object for new zones, you can re-run the Setup Wizard to make this change.
When you re-run the Setup Wizard, the steps you see depend on the specific steps you took during the initial configuration of Direct Manage Access Manager. Follow the instructions displayed to make changes to the Access Manager environment.
Creating a new parent zone
You can use the Create New Zone wizard to create as many zones as you need. You can create the zones in the default Zones container object or in other containers or
organizational units within Active Directory. To create new zones, however, you must be a domain administrator or have the permissions described in the Planning and Deployment Guide. Once you create a zone, you can delegate administrative tasks to other users and groups through the Zone Delegation Wizard. In most cases, only the user who creates a zone has the appropriate rights to delegate administrative tasks to other users.
Unless you join to the domain through Auto Zone (see “Connect to a domain using Auto Zone” on page 56), you must create at least one new zone before you begin adding computers to the Active Directory domain. For more information about configuring zone properties for an existing zone, see “Setting zone properties” on page 44.
To create a new Centrify zone: 1 Open Access Manager.
2 Select Zones and right-click, then click Create New Zone.
3 Type the zone name and, optionally, a longer description of the zone.
In most cases, you can use the default parent container and container type, and the default zone type, which creates the new zone as a hierarchical zone, then click Next.
Creating a new parent zone
For additional details about any of the zone fields, press F1 to view context-sensitive help.
4 Review the information about the zone you are creating, then click Finish.
When you click Finish, the zone is created in the specified location with a set of default values for adding new users and groups to the zone. After creating a zone, and before adding any users, you should review the default zone properties and modify them as needed to suit your environment. For more information about modifying zone properties, see “Setting zone properties” on page 44.
For this Do this
Zone name Type a name for the zone.
The zone name can start with any alphanumeric character or an underscore character (_), followed by any combination of alphabetic, numeric,
underscore (_), hyphen (-), or period (.) characters up to a maximum length of 64 characters. For example:
paris1.france-tgv.org
Container Specify the parent container for this zone. By default, the parent location is the container you specified in the Setup Wizard.
If you want to select a different location for this zone, click Browse and navigate to the container or organizational unit you want to use as the parent for this zone. If you are not using the default parent container, you can click Create to create a new container or organizational unit or select an existing container or organizational unit, then click OK.
Note In selecting a location for a zone, you can use any Active Directory parent container or organizational unit. However, you should never put any Active Directory objects, such as user or computer objects into zone containers. For more information about planning how to add Centrify objects to Active Directory, see the Planning and Deployment Guide.
Object type Select Container or Organizational Unit to specify whether the zone should be created as a container object or an organizational unit object.
If the parent container for the zone is a generic container object, the zone must be created as a container object. If the parent container is an organizational unit, the zone must be created as organizational unit. You cannot apply Group Policy Objects to generic container objects. Description Type a description of the zone.
You can use the description to provide more detailed information about how computers are grouped. For example, if you are grouping computers by location, you might want to use the location in the zone description. If you are organizing computers by department, you may want to specify the department in the description.
Use default zone type Select this option to create the new zone as a standard Centrify hierarchical zone.
You should only deselect this option if you want to create a classic zone for backwards compatibility or are using the Microsoft Services for UNIX (SFU) schema.
Creating a child zone
Creating a child zone
Most zone properties are not inherited from a parent zone. When you create a new child zone, its properties are set to the same default values as a new global zone. The reason for this is that when users are added to a parent zone, they automatically inherit the identical profile in any of the zone’s child zones. Therefore, since the main reason to add a user who is already defined in a parent zone, to a child zone, is to change the profile by overriding one of the profile fields, it makes sense to define separate user and group defaults for parent and child zones.
To create a child zone 1 Open Access Manager.
2 Expand Zones, expand the zone hierarchy as far as necessary to select the zone that will be the parent of the new zone.
3 Right-click, then click Create Child Zone.
4 Type the zone name and, optionally, a longer description of the zone, then click Next. Because you are creating a child zone, you should leave the default parent container and container type, and the default zone type. For additional details about any of the zone fields, press F1 to view context-sensitive help.
5 Review the information about the zone you are creating, then click Finish.
After creating a child zone, you can change its properties at any time. For more information about modifying zone properties, see “Setting zone properties” on page 44.
Moving a child zone
In the Console, you can make an existing zone a child of another zone by dragging and dropping or by changing the Parent zone field on the zone’s Properties > General tab. When you use the Console to make an existing zone a child of another zone, the zone is not moved automatically to the new parent container object in Active Directory. Instead, at the end of the move operation you are prompted to specify whether to move the zone to a new Active Directory container or leave it in its original location. If you choose to move the zone to a new container, you are prompted to select the destination container (typically the parent container).
If you choose to leave the child zone in its original location in Active Directory, you can move it later using ADSI Edit as described in “Changing the location of a zone in Active Directory” on page 50.
Notes
If you move zones in the Console but not in Active Directory, use extreme caution if you
Creating a child zone
its Active Directory zone container and all of its child zone containers are deleted. If the depiction of zones in the Console does not match the zone container structure, it might not be obvious that the zone you deleting in the Console is actually a parent zone.
It is important to thoroughly plan your zone structure early in the design process so you
will not need to make major structural changes later on. However, during the planning and