Planning to Use Server Suite Zones

One of the most important aspects of managing computers with Server Suite software is the ability to organize computers, users, and groups into zones. This section discusses the primary reasons for using zones and provides an overview of how to analyze and migrate an existing user population into zones, including an introduction to assigning roles that enable users to access computer resources. These topics will then be described in greater detail in the next sections to help you create an initial zone structure and migrate users and groups for a target set of computers.

Why Use Zones?

A zone is similar to an Active Directory organizational unit (OU) or NIS domain. Zones allow you to organize the computers in your organization in meaningful ways to simplify the transition to Active Directory and the migration of user and group information from existing identity stores. The primary benefits to using zones are:

Identity management through user and group profile definitions
Access and authorization control through rights and role definitions
Delegated computer management for zone-based administrative tasks

Zones also enable you to centrally manage configuration policies for computers and users through group policies, but for most organizations the key considerations for designing a zone structure involve:

Identity management because zones enable you to migrate from a complex UID space, where a user can have multiple UIDs or different profile attributes on different computers or a single UID might identify different people depending on the computer being used. With zones, you can associate multiple UNIX profiles with a user and identify the correct profile attributes for any user on any given computer.
Access and authorization management because zones enable you to grant specific rights to users in specific roles on specific computers. By assigning roles, you can control who has access to which computers.
Delegated computer management because zones enable you to assign specific administrative tasks to specific users or groups on a zone-by-zone basis, allowing you to establish an appropriate separation of duties. With zones, administrators can be given the authority to manage a given set of computers and users without granting them permission to perform actions on computers in other zones or access to other Active Directory objects.

In most organizations, the first goal in designing the zone structure is to migrate users and computers from an existing identity store, such as NIS, NIS+, local files, or LDAP, to Active Directory and to do so with the least possible disruption to user activity, business services, and the existing infrastructure. Over time, you can also use zones to organize computers along departmental, geographical, or functional lines using whatever strategy works best for your organization.

Although Server Suite supports a workstation mode that does not require you to create and manage zones—a single Auto Zone is defined instead—most organizations find using zones to be an essential part of their migration to Active Directory. The next sections provide more information about why zones are an important part of the planning process. For more information about using Auto Zone, see Deploying to a single Auto Zone.

Identity Management Using Zones

For most organizations, it is impractical to attempt to rationalize user accounts across the enterprise to achieve a single global UID for each user. For example, most organizations have multiple identity stores already in use on their current UNIX platforms. These identity stores may include LDAP directories, NIS or NIS+ domains, and local /etc/passwd and /etc/group configuration files. With these multiple identity stores, it is common for a single user to have a different user name, UID, group memberships, or other attributes defined for different computers.

Zones allow you to import the information from these legacy identity stores without consolidating the multiple profiles that each user may have. For example, a single user might have an account in a UNIX LDAP directory, another defined in a NIS domain, and one or more local /etc/passwd files. Zones enable the profiles from these different identity stores to map to a single Active Directory user account without changing the user profile defined in each of the legacy directories. By keeping the profiles intact, the user’s file ownership and log in permissions are not affected by the migration to Active Directory, making the transition from a legacy system to Active Directory more transparent to end users and less of a management burden for the deployment team.

Role-based Access Control and Zones

As a practical matter, you may choose to use Server Suite zones to ease migration to Active Directory by creating a separate zone for each legacy identity store. However, you can also use zones to group computers by department, by function, or by any other criteria you choose. Using zones in this way gives you a great deal of flexibility in controlling who has access to the UNIX, Linux, and Mac OS X computers in your environment and makes it easier to set up account information for new users based on job function or other criteria.

Through role assignments, zones provide a scope of resources particular users can access, allowing you to define who can do what on which computers. For example, all of the computers in the finance department could be grouped into a single zone called “finance” and the members of that zone could be restricted to finance employees and senior managers, each with specific rights, such as log on to a database, update certain files, or generate reports. This gives you better control over access to systems based on well-defined roles. You can also limit access to certain types of applications, such as database management utilities or web services. For example, you can define specific actions specific users are allowed to perform by assigning them different roles in different zones.

Using Zones to Delegate Administrative Duties

Zones can also be useful for grouping computers that form a natural administrative set or that should be managed by different administrative teams. For example, you may want to group computers that are managed by a local support organization in one zone and computers that are managed by a corporate IT group in another zone.

Using zones, you can then control what different groups of users can do within the zones they have permission to access. For example, you can set up regional zones to provide a separation of duties, authorizing users in San Francisco to manage computers and user profiles in their local office while a team in Barcelona has authority to join computers and manage group profiles for offices located in Spain.

Zones provide a convenient way for you to assign individual administrative responsibilities to specific users or groups based on a set criteria, such as department, geographic location, or functional role.

Deploying to a Single Auto Zone

In most cases, if you are deploying on Linux or UNIX computers and have an existing user population to migrate to Active Directory, you would create a hierarchical zone structure of multiple zones. However, multiple zones are not required for all situations. You can greatly reduce the time required and complexity of your deployment if a single zone suits your organization’s needs. For example, if you are deploying on Mac OS X or Windows computers or if you have a mix of computer platforms but do not have an existing user population to migrate, you might benefit from deploying agents using the Auto Zone option.

With Auto Zone, you have a single zone for an entire forest. All of the users and groups you have defined in Active Directory for the forest automatically become valid users and groups on the computers that join the Auto Zone. If the forest has a two-way trust relationship with another forest, all Active Directory users defined in that trusted forest are also automatically valid on computers that join the Auto Zone.

If you simply want to use the Active Directory users and groups you have already defined on the nonWindows computers you manage, you can skip the planning and creation of zones and simply add computers to the Auto Zone when you join the domain. The UNIX profile attributes that are required to access computers in the Auto Zone are then automatically derived from user attributes in Active Directory or from settings defined in group policies or configuration parameters.

You cannot use Auto Zone to give automatic access to users and groups in a forest or domain with a one-way trust relationship with another forest or domain.

You can use Auto Zone without enabling any group policies or changing any of the default configuration settings. You can also join a domain through the Auto Zone without installing Access Manager. However, you can use group policies or configuration parameters to specify a subset of Active Directory users or groups as valid Auto Zone users. The settings are then enforced on computers in the Auto Zone.

Using Auto Zone can make sense in small or larger organizations if you are not migrating existing users and groups or maintaining legacy UNIX profile attributes. However, if you use Auto Zone, you cannot use zone-specific features. For computers in the Auto Zone, you cannot configure rights and roles, assign roles to users and groups, or provide different profile attributes on different computers.

For information about joining a domain using Auto Zone, see the man page for adjoin or the Administrator’s Guide for Linux and UNIX. For information about using group policies or configuration parameters, see the Group Policy Guide or Configuration and Tuning Reference Guide.

Classic and Hierarchical Zones

If you plan to deploy using zones—which is the most common deployment model—you have to option to create classic or hierarchical zones. Classic zones provide a simple model for organizing computers and backwards compatibility for organizations with older versions of the Server Suite Agent. Hierarchical zones enable you to establish parent-child zone relationships, allowing profile attributes, rights, and roles to be inherited down the zone hierarchy. Classic zones are peers to each other and do not inherit profile attributes, rights, or roles from each other.

One of the first decisions you need to make in planning your zone structure is whether you will use classic zones, hierarchical zones, or some combination of both.

Should You Use Classic Zones?

Classic zones provide a simple structure for delineating users and groups based on a criteria you choose, such as by region or department. They are most appropriate if you have a well-defined and well-managed UNIX namespace with very few users who require special handling because of multiple profiles or conflicting profile attributes.

Classic zones are simple to manage as long as you only need a few. For example, imagine you have three regional zones with no users in common that are managed independently by their own zone administrators with only one enterprise system administrator who must have a profile in each zone. In that scenario, classic zones provide a simple solution because only one user account, the enterprise system administrator, must have a profile in each zone.

However, classic zones are very limited in complex environments where users need profiles in multiple zones or where there are multiple independently-managed UNIX namespaces to migrate to Active Directory. That is because classic zones do not share data across zone boundaries. The data must be created and managed in each zone independently. By contrast, hierarchical zones support inheritance, enabling you to create parent and child zones that share information as needed. Because classic zones do not support inheritance, you cannot use variables to define profile attributes or any other hierarchical zone features.

For most organizations, classic zones are primarily used to enable a new zone that works with pre-5.0 versions of the Server Suite Agent. If you have an older version of Server Suite software installed and already have some zones deployed in your environment, you can continue to use those zones as-is. After upgrading, you then have the option to create any new zones as classic zones to operate within the legacy zone environment or as hierarchical zones.

If you already have zones deployed, you can convert them to hierarchical zones after you deploy the new version of Server Suite software, if you choose to do so. However, there’s no requirement for you to convert existing zones to hierarchical zones.

When Should You Use Hierarchical Zones?

For most organizations, Server Suite recommends that you use hierarchical zones for all new zones that you create. Hierarchical zones provide greater flexibility to inherit profile information, rights and role definitions, and user and group role assignments.

Because hierarchical zones allow you to share or override information at any point in the hierarchy, they also allow you to design a simpler zone structure than classic zones and support an easier deployment model. Typically, a simpler zone structure is easier to manage, but hierarchical zones also allow you to implement a very sophisticated zone structure to address complex access control rules, if you so choose.

How Many Zones Do You Need?

The goal in planning to use zones is to have a fairly small number of zones that organize the computers and users in your organization most effectively. As an example, consider an organization where some UNIX computers are used to host financial applications. Those computers are centrally managed by the IT organization, which follows well-established conventions for issuing user login names, user IDs, and home directories. The same organization has a software development group that includes numerous UNIX workstations that are not centrally managed by the IT organization and computers and accounts are added when needed and managed independently.

Because enterprise-wide conventions are not enforced for the UNIX computers in the software development group, it’s possible that the local login names and user IDs may conflict with the names and IDs used on the computers running the financial applications. In addition, users in the software development group may use a different convention for their home directories or prefer different login shells.

Without zones, the IT organization would need to eliminate any duplicate user IDs and verify each login name was unique across all of the computers. By placing the computers running the financial applications in one zone and the computers in the development lab in another zone, the IT organization can avoid the overhead of checking and changing existing account information and can set default zone settings, such as different default home directories or login shells, that are most appropriate to the users in each zone.

There are many different approaches you can take to defining the scope of a zone, including organizing by platform, department, manager, application, geographical location, or how a computer is used. The factors that are most likely to affect your initial zone design, however, will involve migrating user and group profiles, identifying the appropriate access control policies and role assignments, and delegating administrative tasks to the appropriate users and groups. For many organizations, the most important issue during the initial deployment is a successful migration of existing users. Using hierarchical zones with the ability to override attributes simplifies this task, helping to reduce the total number of zones you need to deploy.

A Closer Look at Using Zones in a Hierarchical Model

In older versions of Server Suite software, zones were always parallel with each other and did not share or inherit data except through manual processes. Starting with Infrastructure Services 2012, however, you have the option to use hierarchical zones that support the inheritance of user and group data and provide a great deal of flexibility for defining the rights and roles for who can access which computers and what those users can do on the computers to which they have access.

How Inheritance Provides Additional Benefits

As discussed in Why use zones?, the primary benefits to using zones are:

Identity management through user and group profile definitions
Access and authorization control through rights and role definitions
Delegated computer management for zone-based administrative tasks

Hierarchical zones provide additional flexibility for each of these benefits. For example, because hierarchical zones allow inheritance, hierarchical zones enable you define partial profiles and use variables that can be substituted at run-time when a user accesses a specific computer in a particular zone. Hierarchical zones also enable you to define access control rules and delegate administrative tasks at any point in the zone hierarchy.

This flexibility makes planning for hierarchical zones a key component of a successful deployment.

How Many Levels Should You Use in the Zone Hierarchy?

There are no predefined limits to the number of zones that can be used in a zone hierarchy or the number of levels deep zones can be nested in the hierarchy you define. For practical purposes, however, it is recommended using a hierarchy similar to the following:

One or more top-level parent zones that include basic profile information for all users and groups that access the UNIX, Linux, and Mac OS X computers.
One to three levels of intermediate child zones based on natural access control or administrative boundaries.

At each level in the hierarchy, profile information and access controls are inherited from the zone above and either applied or overridden by the child zone settings. At the lowest level of the hierarchy, you can override profile attributes or role assignments on any individual computers using machine override settings, if needed.

In addition, hierarchical zones support computer-based access rules, called computer roles, that enable you to selectively map a set of users with a particular role assignment access to a particular set of computers.

Identity Management and Inherited Profile Information

User and group profiles specify attributes such as the UID, primary group, home directory, and shell that are required for logging on to UNIX computers. You can specify all or part of the profile anywhere in the zone hierarchy, but users must have a complete profile to access computers they have permission to access. If the user or group profile is incomplete, it is invalid and ignored.

Working with Partial Profiles in the Zone Hierarchy

The profile information in the zone hierarchy is resolved from top to bottom for each user. For example, assume the user Pat Jackson has the login name patj and UID 12000 defined in the parent zone arcade_global and those profile settings are inherited without change, along with a default shell, home directory and other properties that are defined in the child zone arcade_web_dev. In a second child zone, arcade_aix, the UID for patj is set to 7088 to override the inherited UID. Changes to the profile properties can be made in any zone and inherited down the tree down to overrides set for specific individual computers, if needed.

Working with Variables in the Zone Hierarchy

Partial profiles enable you define a subset of profile attributes for users and groups that can be completed by lower level zones in the zone hierarchy. You can also define variables for resolving profile attributes. The variables are then substituted at run-time by adclient. For example, adclient can resolve the variable %{home}/%{user} to a platform-specific home directory for each user without having the attribute manually defined. You can set the variables at any level in the zone hierarchy, and they are inherited and resolved, or can be overridden, at a lower level in the tree.

You should note that variables can only be used to define profile attributes in hierarchical zones. You cannot import them or use them in classic zones.

Complete Profiles Do Not Grant Access

Creating user profiles in a zone does not give users access to any computers in the zone. The zone hierarchy simply creates a set of profiles with the potential to be granted access to computers. In previous versions of Server Suite software, enabling a UNIX profile for a user in a zone granted that user access to the computers in that zone by default. With hierarchical zones, the profile information only establishes the required properties for the user’s identity, but does not grant access to any computers in any zones.

Access to computers is controlled through the definition of rights and roles.

Access Controls and the Assignment of Rights and Roles

A user must have a complete UNIX profile to log on to any computer in a zone. However, a complete profile alone does not allow a user to access any computers. The user must also have at least one role assignment that grants access somewhere in the zone hierarchy before any type of access is granted. Role assignments can be made anywhere in the zone hierarchy and inherited at a lower level in the tree.

Understanding Roles and Rights

Rights represent specific operations users are allowed to perform. A role is a collection of rights that can be defined in a parent or child zone and inherited. For example, a role defined in a parent zone can be used in a child zone, in a computer role, or at the computer level.

There are only a few predefined rights, called system rights. The system rights for Linux, UNIX, and Mac OS X are:

Password login and non password (SSO) login are allowed: Specifies that a user is allowed to log on interactively using a password or without a password using a single sign-on token.
Non password (SSO) login is allowed: Specifies that a user is allowed to log on using a single sign-on token.
Account disabled in AD can be used by sudo, cron, etc.: Specifies that an account that is disabled is allowed to access the computer. This right enables service accounts that run without a password to perform operations.
Login with non-Restricted Shell: Controls whether a user gets a full shell or is forced into a restricted shell. Users must be assigned at least one role with this right to have access to a standard shell environment. A restricted shell only allows a user to execute explicitly defined commands.

The system rights for Windows computers are:

Console login is allowed: Specifies that users are allowed to log on locally using their Active Directory account credentials.
Remote login is allowed: Specifies that users are allowed to log on remotely using their Active Directory account credentials.

In addition to the platform-specific system rights, there is a common system right that allows users to bypass auditing or role restrictions to log on when there are problems on a computer. The Rescue rights option allows you to specify the users who can log on if problems with the authorization cache or the auditing service on a computer are preventing all other users from logging on.

You grant users permission to access computers by assigning them to a role that includes one or more access rights. By default, zones only contain the following predefined roles to grant basic access rights:

UNIX Login role allows users assigned this role to log on and access UNIX computers in the zone.
Windows Login role allows users assigned this role to log on and access Windows computers in the zone.

There are additional predefined roles that grant specific rights, such as the right to log on if auditing is required but not available. The predefined roles exist in each zone, but their role names are qualified by the zone name so that the same role name in a parent zone and a child zone are considered different roles. For deployment, the predefined roles enable you to migrate existing users without developing custom role definitions. After deployment, you can define additional rights, roles, and role assignments to refine how users and groups access computers in different zones.

Working with a Candidate Set of Profiles

Ultimately, the purpose of the zone structure is to determine who has access, and what kind of access, to a computer. The candidate set of profiles that have the potential to access a computer is resolved by traversing the zone hierarchy from top to bottom. Because profile data is defined separately from the role assignments that control access, you can define an inclusive set of user profiles in a parent zone to create a candidate set that can then be applied to multiple child zones. In each child zone or at the individual computer level, you can use role assignment to control access for specific users from the inclusive candidate set.

Delegation in Hierarchical Zones

Hierarchical zones enable you to create a separation of duties for zone administration without recreating user and group profiles in multiple child zones. You can create full or partial profiles in the parent zone and inherit them into the child zone. Within each child zone, zone administrators can modify the profiles, as needed, and assign roles to control access to the computers they manage.

Designing a Zone Structure for Your Environment

Because the flexibility of hierarchical zones is a key element in designing the zone structure for your deployment, the next sections describe how to set up and use parent and child zones through sample deployment scenarios. The scenarios illustrate a basic deployment model, which will then be used to discuss how to migrate existing users and groups to Active Directory.

Your own zone structure and deployment model can be more complex than the one described in this guide. However, the deployment model described in the next sections is intended to ensure that you have a successful initial deployment. Over time, it is likely that you will change and adapt the zone structure to requirements that are specific to your organization. There are also multiple ways to accomplish the tasks described in the next sections of this guide. You can use other strategies and techniques for deployment if appropriate for your organization.