Leveraging Centrify’s DirectControl and Zone Technology to Simplify Migration
A B S T R A C T
Microsoft’s Active Directory and Group Policy technologies are the de facto standards for identity, access and policy management for Windows enterprises. In the UNIX and Linux world, multiple directory technologies exist for handling user accounts, passwords, system access and usage policy. For many IT managers, the management of all these systems is not only a daunting task but, as the number of users and systems grow, the potential for security exposure also increases. Costs also go up substantially as multiple servers and administrators are required for each directory system. Users are less productive as they are forced to remember different passwords and policies for each system they access. All these factors are driving IT managers to evaluate methods for consolidating directories and user account control.
Given that most organizations already use Active Directory for Windows networks, an ideal solution for consolidation would be to leverage Active Directory for access management beyond Windows and include UNIX and Linux, the next largest base of systems in most large enterprises.
This paper discusses how customers can migrate existing UNIX directory systems to Active Directory using the Centrify DirectControl suite and Centrify’s unique Zones technology.
Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Centrify Corporation.
Centrify may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Centrify, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
© 2005-2007 Centrify Corporation. All rights reserved.
Centrify and DirectControl are trademarks of Centrify Corporation in the United States and/or other countries. Microsoft, Active Directory, Windows, Windows NT, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Contents
1 Introduction to Directory Migration... 1
2 Technology Solutions for Consolidation and Migration ... 2
2.1 Meta-Directory Solutions ... 3
2.2 Extend the Active Directory Schema with a Single set of UNIX Attributes ... 4
2.3 Use Native Active Directory Capabilities to Store Multiple UNIX Identities ... 6
3 Options for a “Real World” Migration to Active Directory ... 6
3.1 Single-Step Migration Overview ... 7
3.2 Two-Step Migration Overview ... 8
3.2.1 Step One – System Consolidation Phase ... 8
3.2.2 Step Two – Identity Consolidation Phase... 8
3.3 Using Centrify’s DirectControl for a Two-Step Migration... 9
3.3.1 System Consolidation Phase... 9
3.3.2 Identity Consolidation Phase ... 12
4 Summary ... 16
1 Introduction to Directory Migration
Most CIOs or IT managers you speak to today will tell you that security is the number one issue they have to deal with in keeping the company’s IT systems running smoothly. Security is a broad term, and it applies to systems, people, applications, data, physical access and policies – virtually every aspect of modern computing.
One of the most important aspects of security is the control of user access to systems and data. This includes applying policies, which encompasses tasks such as requiring strong passwords, managing role-based group membership, and controlling access to data for selected individuals.
However, achieving a companywide system for controlling access and managing users is something that is still an unsolved challenge for many IT managers. Most enterprises have multiple operating system computing platforms, and each of these systems will have its own methods for authentication, authorization, accounting, and access control and for storing user account information. Having multiple systems typically translates into higher costs because separate training, skills and software solutions are required for each platform that needs to be managed.
For many organizations, the bigger problem beyond cost is the security risk of having multiple points of management and control for every user in their organization. Add to this the potential for inconsistent control policies on each system, and the end result could be an environment that has strong controls and security for some systems but few
controls for others. Another example of where this creates both exposure and complexity is the process of commissioning and decommissioning user accounts. When an employee joins the company, which systems will he or she need to access and which applications and data stores will they have access to? How will the employee’s access be managed, and how will consistent policies be applied for each system that the employee will use? More important, when that employee leaves the company, is there a system in place to ensure that all of the employee’s user accounts have been disabled?
While all of these situations present serious challenges for IT managers, there is one more issue that heads the list of current IT initiatives for many companies – regulatory
compliance. Regulations are now in place for companies to control access to customer data through the Sarbanes-Oxley Act and industry-specific regulations such as HIPAA (Health Insurance Portability and Accountability Act of 1996). Not only are companies required to control access to sensitive customer information, but systems need to be put in place to track access to systems as well.
All these requirements can present enormous complexity for managers administering multiple operating system and application platforms. Fortunately, solutions exist to address reducing the complexity and providing centralized management.
2 Technology Solutions for Consolidation and Migration
If IT managers are looking to centralize the control of user accounts, system access and system policy, there are two major choices to make: Which system will be used for centralized control and how to make the new system work with existing platforms in their organization.
In addressing the first decision point – which system should they use for centralized control – many organizations favor using Microsoft’s Active Directory and Group Policy system, which is built into Windows 2000 Server and Windows Server 2003. Active Directory is typically already deployed for managing Windows systems and users, and given that Windows represents the majority of systems in most companies, it would be logical to start with the system that is already in place. The combination of Active Directory and Group Policy is also an excellent choice since many of the key features that IT managers are looking for are included with Active Directory. Some of these features include:
Centralized user account management
User account management integrated with group and computer management Ability to maintain manager / worker relationships
Highly secure technology
Technology based on two popular open standards – Kerberos for authentication and LDAP for user information storage
Easy-to-use administration, based on the familiar Windows user interface
Full control over applying policies for user accounts and systems through the Group Policy system
Full control over password management, including password aging, password complexity, forced password changing and resetting
Easily disable an account or remove it
Integration with enhanced security features such as Smartcards, biometric devices, and certificate services
Easily manage hours of use for each user and computer
Integration with many business applications such as Microsoft’s Exchange, SQL Server, .NET and Internet Information Services (IIS)
Finally, Active Directory is part of Windows Server and is tightly integrated into Microsoft client operating systems, so little has to be done to make it operational – and, of course, it comes for free with Windows Server.
So, assuming that the choice for centralizing your user, computer, application and policy administration is to use Microsoft’s Active Directory, the next choice is how to leverage Active Directory for your non-Windows platforms in your organization. While multiple operating system platforms exist, the second most popular system in use in most businesses is the family of UNIX and Linux systems. Commercial UNIX server systems are popular for hosting business applications, database systems and web services application platforms. Linux server systems have become popular for web site hosting, network infrastructure roles, mail systems, computing farms and file serving. Both UNIX and Linux are also used on client systems for technical workstations, dedicated use workstations, design systems and occasionally business productivity desktops. Since Active Directory extends its management reach to many Windows-based application platforms such as Exchange and IIS, it would be highly desirable to extend this capability to popular UNIX-based application platforms. These platforms include Java/J2EE solutions for web services-based applications, Apache for web server
applications, and other commercial solutions such as database systems. If the IT manager could manage both their Windows systems and their UNIX / Linux systems from a central Active Directory console and extend that access management to their Windows, Linux and UNIX applications, most of their computing platform management needs would be addressed.
In order to reach this goal of having Active Directory as the central store for user, system, application and policy management for both Windows and UNIX/Linux, it is necessary to add additional software to the standard Active Directory system. There are at least three major approaches to solving this challenge.
2.1 Meta-Directory Solutions
Meta-directory solutions basically take the approach that each system should maintain its own directory rather than integrate everything into one central directory. The meta-directory product acts as a gateway between each of these systems and controls synchronization of key attributes such as passwords across all the systems. While this approach has the benefit of having little administrative impact on the existing directories, it has many drawbacks due to the complexity of getting all the solutions talking to each other correctly and getting data synchronization just right. Typically, meta-directories, such as Microsoft’s Identity Integration Server end up being used for highly complex system and application situations rather than as a solution for broad cross-platform user access, authentication and authorization. In the end, a meta-directory is better suited to synchronizing user directory information across multiple platforms and is not really a complete directory consolidation solution.
2.2 Extend the Active Directory Schema with a Single set of UNIX Attributes
UNIX and Linux systems share some of the attributes you would normally store for the user in a directory. For example, both Windows and UNIX have the concept of a username to represent the user account for use when logging into a system or setting the ownership of a file. Both systems need to store a password. Both systems have the user’s actual name stored in one format or another.
However, there are a number of differences between the basic information that Windows stores in a directory versus the information that UNIX typically needs. For example, UNIX needs a field for the user’s home directory and another field for the user’s preferred interactive session shell program. These two attributes, and others, do not exist in the default Active Directory configuration, so in order to address the storage of these extra fields, one approach is to extend the Active Directory schema with fields for each of these extra settings and to apply those extensions to each user account in each domain. Active Directory supports the concept of schema extensions. Some solutions, such as Microsoft’s Services for UNIX (SFU) product, include a method for automatically extending the schema with the typical UNIX attributes. SFU then provides a mechanism through additional services that run on the Windows domain controller to essentially “fake out” the UNIX systems into thinking they are talking to a native UNIX directory service based on Sun’s Network Information System (NIS). For more information on SFU, contact Centrify and request the white paper titled “A Comparison of Centrify’s DirectControl and Microsoft’s Services for UNIX.”
While all of this sounds great theoretically, the reality is that many IT managers shy away from these types of solutions because of the complexity of the additional services that need to be maintained on each system and the risk associated with so-called “Active Directory schema extensions.” Extending the schema of a live production system that holds all of your company’s user account information is something that most IT
managers simply won’t do. If the schema extension fails or corrupts the Active Directory store, the result could be that users would not have access to their systems and
applications. After all, Active Directory is the center of the universe for a Microsoft-based infrastructure and is, therefore, not something that you would typically experiment with once it is in production.
There is an even more important consideration that needs to be addressed as the IT manager evaluates the various solutions that are available. How do you handle multiple existing UNIX identities as you consolidate your UNIX user accounts into Active Directory? While most users have a single Windows identity that is stored in Active Directory, they rarely have a single identity that is used and controlled centrally for all of their various UNIX and Linux systems. Over the years, each of the UNIX platforms have evolved to favor one directory service or another, and Linux systems offer many different choices for storing user account information in a central location. Some systems favor Sun’s NIS or NIS+ while other platforms use LDAP-based directory services, and still others have no directory service at all and store user information locally on each UNIX
system. Extending the Active Directory schema with one set of UNIX user attributes can work if you have only one UNIX user identity, but what do you do if you have many existing user identities?
For solutions that have attributes only for storing a single set of UNIX user settings, the onus is on the customer to figure out how to rationalize their existing user accounts, systems and file access controls. Essentially, you would have to choose a single unique UNIX username and a single unique user ID (UID), and then apply those changes to every UNIX or Linux system in your network. The same issue applies to rationalizing group names and group IDs (GIDs). Here are just a few of the challenges you would face as you implement this strategy:
You would need a system in place to ensure that unique usernames and UIDs are assigned for all of your users, and these new usernames and UIDs should now be created with a corporatewide view in mind. For example, the username “joan” might have been fine on a single web server at a remote site but is probably inappropriate as a username within a large corporation where there may be hundreds of users with the name Joan. Typically, enterprise directory administrators impose standards for user names in order to not create confusion with similar names.
On a UNIX system where the user has an existing account, the ownership of all his or her files would need to be changed to the new UID. This means not only changing files in the user’s home directory (and possibly even changing the name of the home directory) but also means changing all files on the system that the user owns. Files that are created based on the user’s username (for example, their UNIX mail
file) would need to be renamed based on their new username if it has changed. Applications that have access controls enabled based on usernames or UIDs would
have to be checked and updated to ensure that the user credentials are still valid. Group memberships now need to be rationalized corporatewide. For example, if the
user is a member of the “finance” group on a small branch office UNIX system, and they had special rights associated with that group for that branch office, they would need to be placed in an appropriate new group that gives them the access they need locally but also does not accidentally grant them unapproved access to financial information at headquarters.
All of this applies to every single UNIX or Linux system that you have. If you have hundreds of systems, it might take years to roll this out in a controlled way, and the entire process would require extensive manual intervention.
In the end, the benefits of centralized user account management may be outweighed by the complexity of implementing the solution.
2.3 Use Native Active Directory Capabilities to Store Multiple UNIX Identities
There are two major differences between this type of solution and the previous class of solutions. It is possible to populate Active Directory with user information using existing Active Directory capabilities without extending the Active Directory schema. Using this technique, it is possible to store multiple sets of additional attributes for each user account. The two biggest issues with the previous method can now be addressed – avoiding schema extensions and storing multiple UNIX identities associated with a single Active Directory user account.
Centrify offers an approach that provides for storing UNIX user information with an Active Directory user account without the need for extending the schema. Centrify also allows you to store multiple UNIX identities for one Active Directory user and then map those identities back to “Zones” of UNIX systems, again without modifying the schema within Active Directory.
Centrify DirectControl was created by system management industry veterans who looked at real world customer situations and built the product to address the specific needs of real customers. The Centrify DirectControl suite is a seamlessly integrated solution that comprehensively extends Microsoft Active Directory's identity, access and policy management services to your UNIX, Linux, Java, web and database platforms. Centrify DirectControl is quick and easy to deploy, does not require costly or intrusive changes to existing systems, and uniquely integrates your multiple UNIX/Linux identities into Active Directory.
One of the most unique and valuable features in the DirectControl product is its ability to map systems, groups and users into “Zones”. A Zone is a collection of systems that share similar attributes and allows the administrator to enable access for users who have been given explicit membership in the Zone. Zones can also be used to accommodate the importation of multiple legacy directory stores into Active Directory. The Zone concept becomes very valuable for helping customers deal with situations where the organization has existing UNIX/Linux/Java systems with multiple existing directories. It also plays an important role in migrating user roles, permissions and relationships, and gives the IT manager many options for how to approach enabling the UNIX-based platforms in the centralized Active Directory infrastructure. The next sections go into more detail on how to leverage the Zones capability to enable a smooth, phased directory migration.
3 Options for a “Real World” Migration to Active Directory
Generally, “migration” is a scary concept for an IT manager. Migration often implies disruption, downtime, re-training, risk and unplanned costs. While many organizations consider or attempt migrations with the goal of improving functionality, lowering costs or simplifying management, the reality is that migrations frequently fail or are abandoned before they even start. One of the key reasons migrations fail is that the tool used for migration is not suited to a real world, “moving freight train” scenario. A typical IT
environment is a non-stop 7-by-24 operation – a “train that never stops.” How do you move freight from one train to another without “stopping the train”? This is a particularly important consideration when you embark on a user directory migration. Ideally you will not want to interrupt your users’ ability to log into their systems. Once the migration is completed, you need to make sure that users can also continue to access their data and applications. Given that the users need to be both properly authenticated (log in
successfully) and authorized (carry forward predetermined permissions for accessing data and applications) the idea of moving a user from one directory system to another
becomes a potentially daunting task.
3.1 Single-Step Migration Overview
One migration technique is what could be called the “cold turkey” or Single-Step approach. This method assumes that every migrated user will ultimately have one and only one identity for accessing all their UNIX, Linux, Java and web platforms, and this new identity is tied to their existing single Windows identity. The IT manager creates new UNIX profiles for users in the directory and then “flips a switch” and has UNIX users now log in using their new identity.
While having a single identity is a great goal, making the transition from having multiple different identities to a single identity in a single step is a hugely complex task. As pointed out in the previous section on solutions that are only capable of storing one associated UNIX identity, there are many challenges to getting this just right. For directory consolidation solutions that store only one set of UNIX credentials (such as Microsoft’s Services for UNIX), the “cold turkey” approach is the only way to complete a migration.
If your organization has historically used only one system for storing existing UNIX, Linux and Java identities, then this approach will work well. With Centrify’s DirectControl, it is very straightforward to complete a one-step migration. First you import your existing UNIX directory information directly into Active Directory, and then you map each UNIX account to the appropriate Active Directory account. Once this task has been completed, the IT manager can “flip the switch” and have DirectControl handle user logins on the UNIX systems instead of using the legacy directory system.
Further information on importing existing UNIX directories into Active Directory can be found in the DirectControl Administrator Guide.
However, many organizations have multiple existing stores for UNIX user account information and the option of having all systems move to a single identity system in a single step may be infeasible due to the complexity of remapping old account information to new. A more logical approach to migration might be a Two-Step Migration.
3.2 Two-Step Migration Overview
A Two-Step Migration provides the benefits of directory consolidation and the cost savings of reducing infrastructure and systems management, but also allows the migration to occur in phases to minimize disruption.
3.2.1 Step One – System Consolidation Phase
At a high level, step one involves moving the information from your existing UNIX directories into Active Directory, as is. This minimizes the disruption of having to remap file ownerships or confuse users with new usernames. With the UNIX directory services now provided by Active Directory, the previous directory servers can now be reallocated to other tasks or decommissioned. The IT manager can immediately recognize cost savings by having fewer servers and less administrative overhead. This step could be referred to as the “system consolidation phase” – the number of disparate systems is reduced.
3.2.2 Step Two – Identity Consolidation Phase
Step two then begins a gradual effort of consolidating the multiple imported UNIX identities into smaller clusters, or Zones, of identity. Ultimately, these Zones might be organized by geographic region, subsidiary or group role. Business needs can dictate the groupings and naming conventions for users and groups instead of having to live with a legacy of multiple systems for defining usernames.
Another benefit that can be gained in this phase is establishing a consistent model for UID mapping. The goal here is to have as few IDs as possible and ideally one unique UNIX UID that can be used companywide for each user. If users have one UID, they can move files easily from one UNIX system to another without running into potential access rights issues.
As the number of identity stores goes down, the amount of overhead needed to manage user accounts (such as adding a new account) or maintain username format policies also goes down. However, once the user has been assigned a new UID, there is work to do to reset file ownerships for each system that is impacted by the change (as described in the “Single-Step Migration Overview”). But since the users are already fully operational after the first step in this two-step migration, the IT manager can consolidate identities one machine or one group of machines at a time rather than being forced to transition all systems at once. This second phase could be best described as the “identity consolidation phase” – the number of different UNIX identities for each user is reduced.
The Centrify DirectControl suite has the unique ability to allow the IT manager to embark on either a Single-Step Migration or a Two-Step Migration. The key feature that enables this level of flexibility is the Zones feature. The next section goes into more detail on how to approach a Two-Step Migration using the DirectControl suite.
3.3 Using Centrify’s DirectControl for a Two-Step Migration
3.3.1 System Consolidation Phase
Before contemplating a migration to Active Directory, it is a good idea to complete an inventory of existing user and group settings for each unique UNIX directory store. If you are using a centralized directory such as NIS, then you need to gather this
information only once for all of the machines in that NIS domain. The same would apply for other centralized directory systems such as an LDAP-based directory. If the existing UNIX systems have no central directory but instead use /etc/passwd files for storing account information locally, then you must gather the account information from every system that has a local store. A good way to get user and group information is to use the
getent UNIX utility. For example:
getent passwd > /tmp/passwd.$(hostname) getent group > /tmp/group.$(hostname)
would place the user and group information into two files using the standard /etc/passwd and /etc/group formats – regardless of the underlying directory system. Each file would include a suffix with the hostname for the system where getent was run. It is then useful to catalog which machines use which directory system. You may want to create a matrix along the lines of:
Directory Machines Account Data # of Users
NIS domain: Europe france germany england italy
passwd.europe 406
NIS domain: asia japan china india
passwd.asia 224
NIS domain: canada west central east
passwd.canada 98
iPlanet directory: usa se ne central pacwest
passwd.usa 1103
Computer cluster with common /etc/passwd files
webfarm01 webfarm02 webfarm03
Directory Machines Account Data # of Users
Individual systems with unique /etc/passwd files
orca tuna labrador collie passwd.orca passwd.tuna passwd.labrador passwd.collie 10 9 55 201
This table will be useful later when you start adding machines to Active Directory and DirectControl Zones. It might also be useful to review the passwd files from the systems that use local stores to see if usernames and UIDs are common or consistently mapped. The same analysis should be done for the group files. If the account information is the same between any of the systems, the number of imports is reduced.
The next step would be to move the passwd and group files to the Windows machine where Centrify DirectControl console is running. This can be accomplished using FTP, SFTP or a file sharing technology such as Samba or NFS.
On the Windows system, open the DirectControl console and create a new Zone for each group of machines that have a common passwd and group store. For now, you might want to use the old NIS domain or machine names for your new Zones although the Zone can have any name. See the chapter titled “Managing zones,” in the Centrify
DirectControl Administrator’s Guide for more information on creating and managing
zones.
At this point, you should read the chapter in the Centrify DirectControl Administrator’s
Guide titled “Importing information from NIS maps or Unix file.” This importing process
should be completed for each unique set of passwd and group files. For now, each new set should be imported into its own DirectControl Zone. This will ensure that there are no username or UID conflicts during the import process. In some cases, you may need to create new Active Directory user accounts if the user did not already have a Windows account.
Once the Zones have been created and the user accounts have been successfully imported and mapped to Active Directory users, it is time to deploy Centrify DirectControl on the UNIX and Linux systems that you will be joining to the Active Directory domain. One convenient feature of DirectControl is the ability to install it ahead of time on your UNIX systems and then later “join” the domain and activate the Centrify login services when you are ready to make the switch.
When you are ready to join the UNIX system to the Active Directory domain, log in as root on the UNIX system and execute the command:
adjoin --zone zonename --user username domain
In this example, zonename is the name of the Zone that you want this machine to be a member of, username is the name of a user in the Active Directory domain that has privileges for joining a machine to the domain, and domain is the full name of the domain
that you want to join. For more information on installing DirectControl and joining a domain, please refer to the Centrify DirectControl Administrator’s Guide.
After the adjoin command is complete, your UNIX machine is now a member of the Active Directory domain, and login services are now handled by Active Directory and DirectControl. The users who use the UNIX machine can now log in using either their old UNIX username or their Active Directory Windows username. This is because both names were mapped to the user’s Active Directory account during the import process. One major feature of DirectControl is that users now have one and only one password – regardless of whether they are logging in to a Windows system or a UNIX system. Their password is their standard Active Directory password. You no longer need complex password synchronization tools between UNIX and Windows.
You will need to notify existing users that they should use their Active Directory password, not their old UNIX password. For new users in Active Directory, notification of username and password will need to be distributed using the standard methods established by your IT organization. You may want to tell users to start using their standard Windows username when they log in to their UNIX machine. At this point, you have completed the following:
Imported your all UNIX accounts into Active Directory.
Mapped those UNIX accounts to valid Active Directory user accounts. Installed Centrify DirectControl on your UNIX machines.
Joined your UNIX machines to Active Directory.
Enabled logins on your UNIX systems using the DirectControl Active Directory service.
Decommissioned your old UNIX directory service.
the choice of logging in using either their original UNIX username or their Active Directory Windows username. Users now have one password for all their systems. There is another major benefit that is an exclusive feature of DirectControl – users were not forced to make changes to their files or their applications on the UNIX system. Administrators now have the benefit of managing their Windows and UNIX users from one central console – the Centrify DirectControl Administrator Console – and now have full control over things like password policies, easy creation and decommissioning of accounts, and account password resets. IT managers now have the benefit of saving money and administrative staff time by consolidating on a single Active Directory infrastructure and reducing the number of servers.
Having imported the old UNIX directories into Active Directory, you now have the option of consolidating the user name space by leveraging logical groupings through the Centrify Zones technology.
3.3.2 Identity Consolidation Phase
The goal of the Identity Consolidation Phase is to gradually move away from only using the Centrify Zones technology as a way to accommodate legacy identities and instead to move toward a centralized user name space that leverages Zones for managing role-based access controls and delegated administration.
As an example (in our case that was highlighted above) user accounts, groups and computers were grouped into Zones based on clusters of existing identity stores. IT used the NIS domain “europe” to manage user accounts for machines located in Europe, but there was no logical grouping of systems or users based on roles that those systems or users have. One of the most powerful features of Zones is the ability to set up groups of systems that have similar functions and then tightly control the access to those systems by including only the users that need access to those systems in the Zone membership. For example, you may want to create a Zone of machines where payroll systems are hosted. You then may want to further restrict that Zone by including only machines from one geographic region. Finally, you can control which users have access to that Zone, so you choose to add only workers in the payroll offices as members of the Zone. Now, instead of having a Zone named “europe” that includes all systems in Europe and all users who used the old NIS directory in Europe, you can have a Zone called “europe-payroll” and can restrict the Zone membership to the European payroll employees and managers. Another goal in this phase is to consolidate multiple usernames and UID identities for each person. Ultimately, you want each user to have only one user name that is used for both UNIX and Windows, and only one UID that is used on all UNIX systems. As a side effect of having successfully completed the System Consolidation Phase, you actually have already achieved the first goal of having a single username that can be used across all systems, since users can use their Windows Active Directory username as the common username for all system logins in addition to being able to use their old UNIX username for a specific system. Assuming that you complete a migration to a single
username and a single UID for each user, is there still a role for Zones? Quite definitely. As highlighted in the previous paragraph, Zones can really shine as a method for
managing role-based computing. So, what steps need to be taken to complete the Identity Consolidation Phase? The following describes a possible approach.
Before beginning any consolidation effort it is a good idea to establish a system for generating unique UIDs for each user. Some organizations use the user’s employee number. Others reserve pools of IDs and assign numbers on a first-come, first-served basis.
Once you have determined a way to assign unique UIDs, it might make sense to create a master user database file that can be used for Zone imports, or even create a Zone to hold this master set of unique UIDs. This file should have one line for every user that will need access to a UNIX system, and the file should follow the /etc/passwd format. For example:
joan.smith:*:10996:10996:Joan Smith:/home/joan.smith:/bin/csh john.jones:*:10999:10999:John Jones:/home/john.jones:/bin/bash …
Since the goal is identity consolidation, it is important that the first field, the username, be the same as the user’s Active Directory username.
Next, import this list into an empty Zone such as the Default Zone if this is a new installation. This will establish the default UNIX attributes that can be used for machines that don’t need to reside in a special Zone and can also be referenced at a later time when setting up a new Zone. You should double-check to make sure the mappings are correct before committing the imported accounts from the pending state. Since you are using the same username for both UNIX and Windows, the mapping should happen automatically. Create a new Zone that will act as the container for a new role-based Zone. Now repeat this import, but this time import only the users who need to be members into the new role-based Zone. If you use the example above, you could name this new Zone “europe-finance-new”. The users who are in the import file are all members of the payroll departments in the European subsidiaries. At this point you have:
A Zone based on a well defined role.
Users with associated functional roles as members of the Zone.
Each user has a username and UID based on the master user database file. Each UNIX user is mapped to the correct Active Directory user account.
You might also want to create some groups that are specific to this role-based Zone. For example, you may want to create a group called “prmgr” and have all Payroll Managers use this as their primary group.
• Resolving conflicting UIDs and GIDs between the locally managed account database and the DirectControl-managed UNIX profile entries.
• Making any necessary adjustments to the ownership of a local user’s files and directories to match the UID and GID as defined for that user in the Zone profile.
DirectControl provides two command-line utilities, adfixid and adrmlocal, to facilitate this process. In some cases, an account simply must remain locally defined and/or cannot be changed, so DirectControl provides an Account Mapping feature to link a local account with a specific Active Directory account, which can be very useful for service accounts.
The adfixid utility compares the user and group names found in the local password databases, such as /etc/passwd and /etc/group, with those in the DirectControl UNIX profiles for this Zone. Any conflict is reported. The syntax for this command is:
adfixid [--commit] [--commit-all] [--report filename] [--usermap
filename] [--groupmap filename] [--id id_range] [--xdev] [--follow] [--undo] [--restart] [--version] –[verbose] directory
When the command is executed in the root context with the ‘--commit’ flag, it will change the ownership of the local user’s files to match the UID and GID defined for him in Active Directory. The‘--commit-all’ option makes this ownership change and also updates the local /etc/passwd and /etc/ group files to reflect the new ID values. Furthermore, you can use the ’—usermap [filename]’ and ‘—groupmap [filename]’ options to specify mapping files that explicitly describe the values to be matched. Conflicting IDs of a local user who is not found in Active Directory (and hence should be ignored) can be replaced from a range of IDs you specify using ‘--id id-range’. The
adfixid utility will also keep a record of all changes that it makes so you can roll back
changes if required, and in the future if you restore a directory from an archive you can “fix” the file ownership to match the new UNIX namespace.
Account mapping can be used as an alternative integration method for those accounts where the user has a profile defined locally that is different from the profile stored in Active Directory, and for one reason or another the local profile cannot be changed or must remain local. In these situations, which we find very common for service accounts such as oracle or root, DirectControl supports mapping the local account to a given Active Directory account so that login to the local account will require the user to type the valid password to the specified Active Directory account. This enables one or more accounts on one or more systems to share a common Active Directory account’s
password as well as to enforce the account and password policy for that Active Directory account.
It is also important to rename various files and directories so they are consistent with the user’s new identity. For example, the user’s home directory may need to be renamed from something like /home/joan to /home/joan.smith. You might also have to change
certain files, such as mail files; for example, from /var/spool/mail/joan to
/var/spool/mail/joan.smith.
Once the user’s local account information has been updated to match the Active Directory-managed account information and the user’s files have been updated with this new identity, it is no longer necessary to keep the old UNIX account information in the local account database. Centrify provides a command-line utility, adrmlocal, to enable administrators to clean up these local account databases. The adrmlocal utility lists all users and groups in both the local database and Active Directory. Conflicting IDs are also reported. It provides the options to remove duplicate local users and groups either interactively or silently. The syntax of the command is:
adrmlocal [--interactive] [--commit] [--force] [--version]
To delete users and groups in a NIS domain, adrmlocal should be run on the machine acting as the NIS master server. After the command is executed, the NIS passwd and group maps should be updated.
Generally, you would run adrmlocal after you have resolved conflicting IDs using the
adfixid utility. The adrmlocal utility helps to clean up local stores of UNIX user
identities, leaving only system accounts in the local database for local access. The adfixid and adrmlocal utilities are important tools in the Identity Consolidation Phase. Conflicting UIDs and GIDs are reported and can be resolved automatically. Using these tools, it becomes possible to use Active Directory as the sole repository of user identity information for UNIX systems, while storing only system accounts locally, which strengthens security of the system. These tools greatly reduce the tediousness of changing file ownership manually and hence also help to reduce human errors in this process.
Having completed the steps above, you are now ready to move your first machine into the new Zone. Simply open the properties for the computer in the DirectControl
Administrator Console and select the new Zone for the computer in the drop-down selection box.
It should be obvious by now that you should proceed with the remapping exercise only after you have thought through all of the changes that will need to be made on the impacted systems. You may decide to live with the extra Zones and UIDs and wait to make further changes to the systems when you upgrade or install a replacement system. This flexibility is a strength of Centrify’s solution that is not available in other solutions. For other solutions, migrating a UNIX directory to Active Directory is an enormous “all or nothing” proposition.
4 Summary
In summary, migrating your UNIX identity management system into Active Directory can be as complex or as simple as you want to make it. Careful evaluation will need to be made before taking any steps, and it is worth doing some analysis of the tradeoffs of the level of consolidation versus the number of steps required to achieve a fully consolidated identity management system.
Fortunately the Centrify DirectControl solution can work extremely well in any of the scenarios described in this white paper. You have the option to do quick imports of your UNIX user identity stores into Active Directory – even if you have multiple directory systems or individually managed systems with conflicting usernames or UIDs. DirectControl is the only solution that gives you this level of simplicity and rich functionality. You also have the option to move gradually to a single, consolidated identity system for all your UNIX and Windows users. Again, DirectControl allows you to do this in phases at your own pace with minimal disruption to your existing operations. On a final note, it is worth highlighting just a few of the major benefits that can be gained by migrating your multiple UNIX directory systems to a single Active Directory system with Centrify’s DirectControl:
You now have a single point of administration for user account management. Users now have a single username and password that they can use on all their UNIX,
Linux and Windows systems.
Consistent policies can be applied to all systems – things like password complexity and password aging.
You now have the ability to finely tune access to your systems for only those users who need access and to do this from a central console as opposed to managing access from each individual machine.
You no longer need specialists for every directory system that you are maintaining today – everything is now done from the easy-to-use Active Directory and DirectControl Administrator consoles.
You now have access to powerful tools for tracking user and system access across all your UNIX, Linux and Windows systems – which is enormously valuable as companies deal with regulatory compliance.
Commissioning and decommissioning of user accounts is now done from a single point of administration.
Costs go down as fewer systems are required to maintain user account information. This also saves money in reduced support and maintenance costs, lower facilities cost, lower power requirements and fewer people required to maintain the systems.
5 How to Contact Centrify North America
(And All Locations Outside EMEA)
Europe, Middle East, Africa
(EMEA) Centrify Corporation 444 Castro St., Suite 1100 Mountain View, CA 94041 United States Centrify EMEA Asmec Centre Merlin House Brunel Road
Theale, Berkshire, RG7 4AB United Kingdom
Sales: +1 (650) 961-1100 Sales: +44 1189 026580 Enquiries: info@centrify.com
