Chapter 7: Operating a Custom Solution

  • Article
On This Page

Introduction and Goals Introduction and Goals
Change Management Change Management
Configuration Management Configuration Management
Release Management Release Management
System Administration System Administration
Security Administration Security Administration
Service Monitoring and Control Service Monitoring and Control
Directory Services Administration Directory Services Administration
Service Desk Service Desk
Incident Management Incident Management
Service Level Management Service Level Management
Financial Management Financial Management
Availability Management Availability Management
Service Continuity Management Service Continuity Management
Capacity Management Capacity Management
Workforce Management Workforce Management

Introduction and Goals

This chapter addresses the operation of your custom solution that establishes interoperability between UNIX or Linux clients and the Microsoft® Windows® Active Directory® directory service after the solution has been deployed into your production environment. The solution that is now in place in your organization is one of several possible custom solutions for implementing interoperability between Windows Active Directory and UNIX or Linux clients. These solutions are described in detail in Volume 2: Chapter 4, "Developing a Custom Solution."

Up to this point, the chapters in this guide have been organized according to the guidelines in Microsoft Solutions Framework (MSF). Now that deployment is complete, this chapter is organized according to the principles specified in the complementary Microsoft Operations Framework (MOF). Whereas MSF provides guidelines for developing and delivering enterprise-ready software solutions, MOF provides guidelines for IT operations to support already deployed solutions. For more information about MSF and MOF, see "Knowledge Prerequisites" later in this introduction.

Depending on which solution your organization deployed, interoperability between UNIX hosts and an Active Directory domain is established as follows:

  • Authentication only. An End State 1 solution, as defined in this guide, enables UNIX or Linux clients to use Kerberos to authenticate to Active Directory. If your solution is an End State 1 solution, UNIX or Linux clients continue to use the existing UNIX-based authorization method.

  • Authentication and authorization. An End State 2 solution, as defined in this guide, uses both Active Directory–based Kerberos authentication and Active Directory–based LDAP authorization to support UNIX or Linux clients.

Some custom End State 1 or End State 2 solutions described in this volume use native operating system (native OS) components available by default in UNIX or Linux; others add the use of open source components and free software downloads to the native OS components. Both native OS and open source solutions described in this volume include solutions designed for Red Hat 9 Linux and for Solaris 9 UNIX.

Note   We do not recommend deploying the native OS Red Hat 9 solution in your production environment because of the security risks inherent in this solution. For more information, see the discussion in the section "Use Red Hat 9 with Native OS Components for End States 1 and 2" in Volume 2: Chapter 4, "Developing a Custom Solution."

You can find much of the information that you need to operate the new solution in existing documentation for Windows and UNIX. The purpose of this chapter is to supplement existing documentation and to focus on the following areas:

  • The impact of the new interoperability solution on your Windows and UNIX infrastructure.

  • Information that you need that is not currently available in other documentation.

The goal of this chapter is to provide the information that you need to operate the new interoperability solution cost effectively to achieve high reliability, availability, and security.

Intended Audience

The primary audience for this chapter includes IT support staff and members of the operations group. All team leads should also review the material in this chapter.

Knowledge Prerequisites

Ensure that the IT support staff and members of the operations group who are primarily responsible for managing and supporting your custom UNIX-to-Windows interoperability solution possess the knowledge requirements stated in "About This Volume" and identified in the “Project Team Skills Template” job aid.

Team leaders should also be familiar with the following Microsoft information:

  • MOF resources. Microsoft Operations Framework (MOF) provides comprehensive technical guidance for achieving mission-critical system reliability, availability, supportability, and manageability in IT environments. Operations team members unfamiliar with MOF should review the following MOF resources:

Team leads might also find the following resource useful:

Major Tasks and Deliverables

For the End State 1 and End State 2 solutions described in this volume, the operations team manages tasks in the following MOF-defined service management functions (SMFs):

  • Change Management

  • Configuration Management

  • Release Management

  • System Administration

  • Security Administration

  • Service Monitoring and Control

  • Directory Services Administration

  • Service Desk

  • Incident Management

  • Service Level Management

  • Financial Management

  • Availability Management

  • Service Continuity Management

  • Capacity Management

  • Workforce Management

This chapter provides information related to the UNIX-to-Windows interoperability solution deployed in your environment for each of these SMFs. For a complete list and detailed description of all MOF SMFs, see the MOF site listed earlier under "Knowledge Prerequisites."

Operations tasks are identified as relevant to all solutions or to one or more particular solutions. For example:

[All solutions]

– or –

[Solaris 9] [Native OS] [End State 2]

Note that the label [All solutions] refers to all End State 1 and End State 2 solutions included in this volume. It does not include End States 3, 4, or 5, which are described in later volumes.

Change Management

Change management defines how to initiate infrastructure changes, assess and document their potential impacts, approve their implementation, and schedule and review their deployment. The goal of change management is to provide a formal process for introducing required changes into the IT environment with minimal disruption to ongoing operations.

Deployment of the UNIX-to-Windows interoperability solution introduces many changes to your production environment. The solution must be managed across both UNIX and Windows platforms because UNIX and Windows are now tightly integrated with each other.

Change management tasks important for the successful operation of your UNIX-to-Windows interoperability solution after changes are introduced include:

  • Update DNS configuration after DNS infrastructure changes to ensure DNS availability

    [All solutions]

    Kerberos is very sensitive to host name resolution failures, which means that even small changes to DNS can create problems for UNIX clients when one or more DNS servers are unavailable (whether or not the UNIX clients are included in your interoperability solution). Problems increase if the primary DNS server for which clients are configured is unavailable. Any changes to DNS infrastructure might require that you configure each computer to update the DNS configuration. DNS changes might also require that you update configuration files for Kerberos (the krb5.conf file) and LDAP (the /etc/ldap.conf file or, for native Solaris, the /var/ldap/ldap_client_file).

  • Synchronize Windows DNS servers and other DNS servers

    [All solutions]

    If UNIX clients use DNS servers running UNIX (or any other operating system other than Windows), you must synchronize these DNS servers with the Windows DNS servers (or use another strategy to integrate the two types of DNS servers) so that all computers in the solution environment can use DNS name resolution to locate each other.

    When you make changes to Windows DNS servers, adjust the UNIX DNS servers at the same time, and vice versa.

    For more information, see Appendix G: "Configuring DNS for a Heterogeneous UNIX and Windows Environment."

  • Update krb5.conf after Active Directory server changes to avoid authentication problems

    [All solutions]

    The instructions provided in this guide do not implement DNS lookups for Kerberos. Instead, Active Directory servers that handle authentication are specified in the Kerberos configuration file, krb5.conf (which is used to configure Kerberos client functionality on a UNIX client). Because of this, removing or moving Active Directory servers has a greater impact on UNIX-based computers than on Windows-based computers.

    Make sure that you update UNIX krb5.conf files to reflect changes in the Active Directory infrastructure. If you remove from your network the Active Directory server that is identified first in the krb5.conf file, you must also remove that server from the krb5.conf file or authentication will be slower. If you remove from your network all Active Directory servers that are identified in the krb5.conf file, you must replace at least one of them (or at least two for load balancing and availability purposes), or authentication will fail.

    Note   You might be able to provide for automatic Kerberos load balancing similar to that used by Windows by implementing DNS lookups. This will eliminate the need to specify Kerberos KDCs in the krb5.conf file. (It is not possible to configure DNS lookups for LDAP for the solutions described in this guide. Therefore, End State 2 solutions will continue to require that you manually provide for load balancing by specifying individual Active Directory servers in the LDAP configuration files.)

  • Update UNIX LDAP configuration if Active Directory servers are moved or removed

    [End State 2 solutions]

    For End State 2 solutions, which use Active Directory for authorization as well as for authentication, you must configure LDAP on the UNIX-based computer (the /etc/ldap.conf file or, for native Solaris, the /var/ldap/ldap_client_file) to point to specific Active Directory servers. You must update the UNIX configuration for LDAP whenever an Active Directory server is removed from service or moved and is therefore no longer available to the UNIX host.

    The items that you configure for End State 2 solutions include the server or servers to which LDAP requests are directed, the method by which the LDAP bind is accomplished, the mapping of UNIX authorization attributes to Windows attributes, and the container in which data for UNIX users and groups in Active Directory is found. For more information, see the following subsections in Chapter 4: "Developing a Custom Solution":

    • Configure the LDAP Client ([Native OS] [Solaris 9] [End State 2])

    • Configure the /etc/ldap.conf File ([Native OS] [Red Hat 9] [End State 2])

      Note   This cross-reference to the native OS Red Hat solution is included for completeness, but it is unlikely that this solution is deployed in your production environment. We do not recommend deploying the native OS Red Hat 9 solution in your production environment because of the security risks inherent in this solution.

    • Configure the /etc/ldap.conf File ([Open Source] [Solaris 9] [End State 2])

    • Configure the /etc/ldap.conf File ([Open Source] [Red Hat 9] [End State 2])

  • Make sure that NTP configuration changes replicate to all computers

    [All solutions]

    NTP configuration changes must be replicated to all computers included in the interoperability solution. If some computers are missed, clocks might drift and logon will fail when the clock skew on any computer that authenticates to Active Directory exceeds the interval (5 minutes by default) that is supported by Kerberos on Active Directory.

  • Develop automated tests

    [All solutions]

    Automated testing can greatly reduce the effort and time required to deploy new patches and to make changes to the network or Active Directory infrastructure. Where possible, develop automated test systems to exercise the functionality of the solution.

  • Test changes to the Active Directory infrastructure

    [All solutions]

    Because UNIX clients included in the interoperability solution now rely on the Active Directory infrastructure, you must test all changes to the Active Directory infrastructure (such as version upgrades, patches, and configuration changes) against both the Windows and the UNIX environments.

  • Change both UNIX and Windows NTP servers

    [All solutions]

    If UNIX clients use different Network Time Protocol (NTP) servers than those used by Windows clients, changes you make on the NTP server that supports UNIX clients must also be made on the NTP server that supports Windows clients, and vice versa.

    Note   As indicated in the section "Synchronize Time" in Volume 2: Chapter 4, "Developing a Custom Solution," this guide assumes that you have configured time on your Active Directory servers and UNIX or Linux clients as described in Appendix H: "Configuring Time Services for a Heterogeneous UNIX and Windows Environment." The best practice is to implement Network Time Protocol (NTP) to maintain synchronization instead of attempting to manually synchronize computers.

    For more information, see:

  • Manage PKI changes

    [Solaris 9] [Native OS] [End State 2]

    For the native OS End State 2 solution on Solaris, you need to ensure that the certificates used for LDAP over SSL (LDAPS) remain valid to avoid adversely affecting UNIX-based computers included in your interoperability solution. Make sure that the following occur to help avoid a failure of the LDAPS connection resulting in authentication failure:

    • UNIX clients should be configured correctly to trust the current issuing and root CAs.

    • Certificates should be renewed or replaced before they expire.

    • Certificate revocation lists should be regularly published.

    • If your root CA or issuing CA certificates expire or are replaced, you might need to update the certificates on your UNIX clients.

    Note   LDAPS is used to encrypt LDAP traffic between a client computer and a directory server.

    For more information about Certificate Services, see:

  • Keep track of supported encryption types

    [All solutions]

    New Kerberos key tables for existing UNIX clients must be generated and distributed periodically. In this process, it is important to understand that Kerberos version changes on either Windows or UNIX might mean a change in supported encryption types.

  • Test UNIX patches against both UNIX and Windows

    [All solutions]

    You must install native UNIX operating system patches for UNIX (for both native OS and open source solutions) as they become available in order to protect against bugs and security vulnerabilities related to Kerberos and LDAP. You must test native OS patches against the UNIX environment and also against Active Directory before implementing them in your production environment.

    Although it is unlikely to occur, installing patches or updates from any operating system vendor, including UNIX operating system vendors, might interfere with the solution. So whenever you install any patches or updates, you must test the solution carefully to identify any potential problems or to determine that no problem exists.

    Because operating system vendors test their native solutions with their native OS patches, you are less likely to see the introduction of a problem with a native OS patch when using a native OS solution. Implementing patches for open source solutions might require more effort than patching native OS solutions.

  • Test solution functionality after operating system upgrades

    [All solutions]

    UNIX operating system version upgrades might change the way in which Kerberos or LDAP interact with Active Directory, so thorough testing of functionality of your interoperability solution is required in preparation for and following an upgrade.

    For native OS solutions, an updated operating system version might add features that will change or improve the solution, such as adding support for additional encryption types or different LDAP bind methods. You must evaluate any new feature and determine if you want to implement it as part of the upgrade.

  • Test upgrades of open source Kerberos and LDAP tools

    [Open Source]

    New open source versions of the Kerberos and LDAP tools (described in Volume 2: Chapter 4, "Developing a Custom Solution") for the open source solutions will become available over time. Newer versions might require different build procedures and configurations. Potentially, newer versions could introduce changes that are not fully compatible with Active Directory. You must thoroughly test any new version of these tools before implementing them.

Configuration Management

Configuration management refers to the process of identifying, controlling, and tracking IT infrastructure components and changes to those components. Components include all versions of hardware, software, documentation, processes, and procedures. The goal of configuration management is to ensure that only authorized components are used in the IT environment and that all changes are recorded and tracked throughout the component’s life cycle.

Configuration management tasks important for the successful operation of your UNIX-to-Windows interoperability solution include the following:

  • Monitor configuration changes

  • Monitor logs

Monitor Configuration Changes

Monitor UNIX-based computers and Active Directory servers included in your interoperability solution for configuration changes that might affect the functionality of the solution. Important configuration changes that you need to monitor include those in the following list:

  • Report unauthorized Kerberos or LDAP configuration changes

    [All solutions]

    You can use the open-source or commercial Tripwire tool, or a similar tool, to look for and report changes of state indicating unauthorized access or changes in Kerberos or LDAP data on a given computer. Monitor the interoperability-related files and tables listed in the following table for unauthorized access and unauthorized changes.

    Table 7.1. Files to Monitor for Unauthorized Access or Changes

    Type

    Kerberos or LDAP File or Table

    Configuration files

    Kerberos configuration file:

    • /etc/krb5/krb5.conf (all Solaris solutions)

    • /etc/krb5.conf (all Red Hat solutions)

    PAM configuration file:

    • /etc/pam.conf (all Solaris solutions)

    • /etc/pam.d/system-auth (all Red Hat solutions)

    LDAP configuration file:

    • /etc/ldap.conf (all Red Hat End State 2 solutions and open source Solaris End State 2 solution)

    • /var/ldap/ldap_client_file and /var/ldap/ldap_client_cred (native OS Solaris End State 2 solutions only)

    NSS configuration file:

    • /etc/nsswitch.conf (all End State 2 solutions)

    Key tables

    Kerberos key table file:

    • /etc/krb5.keytab (all Red Hat solutions)

    • /etc/krb5/krb5.keytab (all Solaris solutions)

    Kerberos key table file for the proxy user:

    • /etc/proxy.keytab (all open source End State 2 solutions)

    Operational files

    Credentials cache for LDAP proxy user:

    • /var/tmp/proxycreds (all open source End State 2 solutions)

    Certificate files for SSL/TLS for LDAP

    • key3.db, cert7.db, secmod.db, and secmodule.db (native OS Solaris End State 2 solutions only)

  • Observe time synchronization

    [All solutions]

    Monitor for time synchronization failures—clock skew. If clock skew occurs, which can indicate an NTP failure, you must correct the NTP inconsistencies or manually reset the clocks on the affected computers.

  • Certificate expiration

    [Solaris 9] [Open Source] [End State 2]

    The certificates used for the open source Solaris solution to provide for a SSL/TLS encrypted channel for LDAP proxy authentication have a fixed lifetime. You must monitor the certificate validity and renew the certificates before they expire. If a certificate expires, the solution will cease to function. The lifetime of the certificate varies and is based on the certificate server configuration at the time that the certificate is generated.

Monitor Logs

Monitor both UNIX and Windows events.

  • Monitor log messages

    [All solutions]

    Use scripts, tools, and enterprise management systems to monitor and report on:

    • UNIX system logs (syslogs) , which store and reroute log messages from UNIX system services and applications.

    • Windows event log , which records events in the system, security, and application logs. The Event Log service is located in the Windows Event Viewer.

  • Troubleshoot logged events

    [All solutions]

    For information about events to look for that might indicate problems, see the following appendices:

    • Appendix C: "Kerberos and LDAP Error Messages"

    • Appendix D: "Kerberos and LDAP Troubleshooting Tips"

    • Appendix E: "Relevant Windows and UNIX Tools"

Release Management

Release management is responsible for releasing changes that have been developed and tested into an organization's production environment. The goal of the Release Management SMF is to introduce a new or updated solution, or updated components of a deployed solution, with the least amount of disruption to users.

Any time you upgrade or substantially change components of your UNIX-to-Windows interoperability solution, it is important that you test the functionality of the UNIX and Windows environments and their integration with each other before you release the updated solution into your production environment.

Release management tasks important for the successful release of a new or updated interoperability solution include those described in the following sources:

  • Volume 2: Chapter 5, "Stabilizing a Custom Solution" provides guidelines for testing the custom End States 1 and 2 solutions developed in Volume 2: Chapter 4, "Developing a Custom Solution" and for performing a pilot deployment.

  • The "Change Management" section earlier in this chapter.

  • The "Configuration Management" section earlier in this chapter.

System Administration

System administration is responsible for providing day-to-day administrative services in support of the organization's computing infrastructure. System administrators manage and provide operational support for the production environment, including network accounts (users, groups, or distribution lists) and network resources (servers, printers, or storage devices).

The System Administration SMF tasks important for the successful operation of your UNIX-to-Windows interoperability solution include the following:

  • Maintain clock synchronization

    [All solutions]

    Ensuring the correct functionality of NTP is critical to your interoperability solution. For information about administering NTP in the context of this solution, see the following topics in this chapter:

    • Change Management

    • Configuration Management

    • Service Monitoring and Control

    In addition, refer to the information about NTP and clock synchronization in the following chapters and appendix in this guide:

    • Volume 2: Chapter 4, "Developing a Custom Solution"

    • Volume 2: Chapter 5, "Stabilizing a Custom Solution"

    • Appendix H: "Configuring Time Services for a Heterogeneous UNIX and Windows Environment"

  • Ensure that DNS is stable

    [All solutions]

    Ensuring the correct functionality of DNS is critical to your interoperability solution. For information about administering DNS in the context of this solution, see the following topics in this chapter:

    • Change Management

    • Configuration Management

    • Service Monitoring and Control

    In addition, refer to the information about DNS in the following documents in this guide:

    • Volume 2: Chapter 4, "Developing a Custom Solution"

    • Volume 2: Chapter 5, "Stabilizing a Custom Solution."

    • Appendix G: "Configuring DNS for a Heterogeneous UNIX and Windows Environment"

  • Secure Kerberos key tables , configuration files , and passwords

    [All solutions]

    For information about securing Kerberos key tables, sensitive configuration files, and passwords in configuration files, see the following topic in this chapter:

    • Security Administration

  • Manage user provisioning to avoid authorization conflicts

    [End State 2]

    Integrating the user provisioning of UNIX user accounts in Active Directory with your pre-deployment user provisioning or identity management system is often the key to successful administration of the interoperability solution. Whether user provisioning is a large or small task depends on your existing network environment.

    During (and potentially after) the initial deployment of the interoperability solution, when you administer user provisioning you must take into consideration any databases other than Active Directory that store authentication and authorization data. UIDs and GIDs that you add for new users should be in sync for a given user and not duplicated for different users. For example:

    • If the user "JeffH" is created in two data stores, give him the same UID in both.

    • If the user "JeffH" is created only in Active Directory and "LoriP" is created only in a non-Active Directory data store, do not give "JeffH" and "LoriP" the same UID.

    In the future, users from alternative data stores might be migrated into Active Directory and any conflicts with authorization data that exist will complicate migration.

Security Administration

Security administration applies security policies and best practices to maintain a secure operating environment. Security administrators work to prevent such security breaches as data loss, data disclosure, loss of system availability, or corruption of data.

The Security Administration SMF tasks important for the successful operation of your UNIX-to-Windows interoperability solution include the following:

  • Generate a new key table to secure computer account passwords in the Kerberos key table file

    [All solutions]

    A password equivalent for the computer account for each UNIX-based computer is stored in the Kerberos key table file on each UNIX-based computer. You should change these passwords at regular intervals to keep them secure, as described in the following table.

    Table 7.2. Generating a New Key Table to Change Computer Account Password

    Task

    Description

    Create the key table

    Use either of the following methods:

    • Use the Windows ktpass command to generate a new key table, and then securely copy it to the UNIX-based computer by using an encrypted channel or a physically secure method (such as a floppy disk). In a production environment, it is critical to transfer this file in a secure manner because the key stored in the key table file must be kept confidential.

    • Use the Certified Security Solutions (CSS) Active Directory Kerberos administration tool (called ADKadmin or css_adkadmin) to generate a new key table on the UNIX-based computer. It is important to understand that the instructions given in Volume 2: Chapter 4, “Developing a Custom Solution” of this guide for using css_adkadmin are for creating the computer account and generating a key table. Subsequent key table generation is done by using the ktadd command in css_adkadmin.

    IMPORTANT   Unlike many Kerberos implementations, Active Directory does not support creation of a key table using the existing computer account password (extracting the password from the database and writing it to a new key table). Generation of a new key table therefore always changes the password for the computer account.

    Set key table permissions (ktpass only)

    If you use ktpass to generate new Kerberos key table files, when the new key tables are distributed to the UNIX-based computers, you must set permissions on the new key table files to limit access as appropriate.

    Key tables generated with the css_adkadmin tool are automatically created with correct permissions and do not need to be changed.

  • Audit permissions on secure files

    [All solutions]

    Set up periodic auditing to monitor permissions on secure files, such as Kerberos key table files, credentials caches, and files that contain passwords. Some files should be readable only by the root user. Other files must have more open permissions for functionality. Auditing should check that files have the correct owner and permissions.

  • Limit root access

    [All solutions]

    If much of the administration of your pre-deployment UNIX environment was done using the root user account, the root account should no longer be used as widely in the interoperable environment. If you do not limit the use of the root account, administrators might now have access to accounts and resources that have enterprise-wide access instead of just local computer or limited access.

    Limiting the use of the root account is also important for auditing and compliance issues. Actions taken by administrators should be done by using user-specific accounts, with a tool such as sudo, instead of with a generic shared account, such as root.

  • Secure LDAP proxy account passwords in the Kerberos key table file

    [Open Source] [End State 2]

    A password equivalent for the LDAP proxy user account used to open an encrypted channel for LDAP authorization data is stored in a special Kerberos key table file on each UNIX-based computer. You should change these passwords at regular intervals.

Service Monitoring and Control

Service monitoring and control operations personnel monitor the functionality of IT services and initiate remedial actions to minimize the impact of service incidents and system events. The Service Monitoring and Control SMF has both reactive aspects (dealing with incidents as they occur) and proactive aspects (handling potential service outages before they arise).

Service monitoring and control tasks important for the successful operation of your UNIX-to-Windows interoperability solution include the following:

  • Monitor UNIX-based computers and Active Directory servers

    Check for errors, warnings, and changes in the following services that might affect the interoperability solution:

    • Monitor Active Directory and DNS services , including the following issues:

      [All solutions]

      Availability of DNS and Active Directory servers

      Availability of the Kerberos Key Distribution Center (KDC) service running on Active Directory servers

      DNS resolution problems

    • Monitor time services , including the following issues:

      [All solutions] The occurrence of clock skew.

      [End State 2 open source solutions] Cron job to acquire credentials for the LDAP proxy user (for End State 2 open source solutions). Cron is the UNIX service that is used to run commands at scheduled times.

    • [End State 2 native OS solutions on Solaris] Secure Sockets Layer (SSL), including problems caused by certificate expiration.

    • [End State 2] Name service cache daemon (NSCD). On UNIX-based computers, the NSCD service caches LDAP data retrieved from Active Directory to reduce lookups for duplicate data.

    You can build custom monitoring scripts to monitor the services in this list.

  • Monitor log messages

    [All solutions]

    Use scripts, tools, and enterprise management systems to monitor and report on:

    • UNIX system logs (syslogs). Store and reroute log messages from UNIX operating system services and UNIX applications.

    • Windows event log. Records events in the system, security, and application logs for computers running Windows. The Event Log service is located in the Windows Event Viewer.

    For information about events to look for that might indicate problems, see the following appendices:

    • Appendix C: "Kerberos and LDAP Error Messages"

    • Appendix D: "Kerberos and LDAP Troubleshooting Tips"

    • Appendix E: "Relevant Windows and UNIX Tools"

  • Implement performance monitoring

    [All solutions]

    A recommended practice is to introduce a performance management system to optimize the performance of the solution. Performance monitoring establishes a feedback system by integrating inputs, outputs, metrics, and functions for your interoperability solution. Use quality management principles, tools, and techniques to develop a performance management system.

    For example, your metric selection process might have identified as a metric the percentage of logon attempts that fail. This metric might be used with a process control chart and ultimately a system dashboard to monitor the performance of your system.

    If internal resources are not available with experience in this field, consider contacting outside services such as Certified Security Solutions and their Security Kaizen services. For more information about Security Kaizen, see the Certified Security Solutions page for Services at https://www.css-security.com/services.html.

Directory Services Administration

Directory services administration operations personnel perform the day-to-day operations, maintenance, and support of Active Directory. In the UNIX-to-Windows interoperability solutions described in this guide, Active Directory enables Windows and UNIX clients to locate users, files, services, and servers on the network. Directory services administration includes managing user and group accounts as well as network resources such as servers that host directory-enabled applications. The goal of the Directory Services Administration SMF is to ensure that authenticated users can gain access to information on the network that they are authorized to access.

Directory services administration tasks important for the successful operation of your UNIX-to-Windows interoperability solution include the following:

  • Manage UNIX authorization data in UNIX-based data store

    [End State 1]

    For End State 1 solutions, you must manage your existing, or an alternative, data store for UNIX user authorization data. Although Active Directory will be used for UNIX user authentication data, authorization data for each UNIX user must also be maintained elsewhere.

  • Manage UNIX authorization data in Active Directory

    [End State 2]

    Note   The custom solutions described in Volume 2: Chapter 4, "Developing a Custom Solution" assume that you use Microsoft Windows Services for UNIX 3.5, which is not compliant with RFC 2307, to extend the Active Directory schema to include UNIX attributes. These attributes are used for authorization in the End State 2 solutions. Windows Server 2003 Release 2 (R2) includes support for RFC 2307 by default and thus supports LDAP attributes used to store UNIX or Linux user and group account information. However, the custom solutions developed in this guide were not developed or tested with Windows Server 2003 R2.

    For End State 2 solutions, Active Directory is used to store authorization data. You must assign UNIX authorization attributes to the Active Directory accounts of UNIX users. When a user attempts to log on to a UNIX-based computer, the operating system must retrieve both authentication data and authorization data for the user. The authorization data defines the environment in which the user will operate and the tools and files to which the user will have access. The new UNIX attributes added to Active Directory for the solution will likely not be familiar to Windows administrators and probably are not part of existing Windows user-provisioning tools.

    The authorization data needed for UNIX logon includes these UNIX attributes for the user:

    • UID. The user ID or unique ID number associated with the user. This number is assigned to files or directories to which the user has specific permissions (as opposed to permissions assigned through membership in a group). This is similar to the access control mechanisms used in Active Directory and controlled with the user's logon name.

    • Primary GID. The ID number of the primary group associated with a user. Group IDs are assigned to files and directories to provide access control for groups of users.

    • Home Directory. The full path and directory name of the user's home directory.

    • Shell. The program environment in which the user will operate upon initial logon. Examples of this include csh (C Shell), sh (Bourne Shell), and bash (Bourne Again Shell). Some UNIX or Linux operating systems support all shells, but others support only some shells.

    For more information about schema extension for an End State 2 solution, see "Extend the Schema" in Volume 2: Chapter 4, "Developing a Custom Solution," and see the detailed description in that chapter of the specific solution that is deployed in your environment.

  • Add users to secondary groups

    [End State 2]

    End State 2 solutions migrate group management to Active Directory. Like Active Directory, UNIX separates group membership into a primary group and multiple secondary groups for a user. A user must be associated with a primary group. The addition of one or more secondary groups is optional.

    If you use Windows Services for UNIX, installing it adds a UNIX Attributes tab to the Active Directory Users and Computers snap-in to manage UNIX user attributes. However, you must use the Active Directory Service Interfaces (ADSI) Edit tool, Adsiedit.exe, or a similar tool, to add users to secondary groups because the UNIX Attributes tab does not set the attributes for UNIX group management. ADSI Edit is installed with Windows Support Tools for Windows Server 2003. If you do not have Windows Support Tools installed, see “To install Windows Support Tools” on the Microsoft Web site at https://go.microsoft.com/fwlink/?LinkId=62270.

    In a large production environment, it is generally not practical to try to manage UNIX group membership through a tool such as ADSI Edit because its use requires a high level of administrative knowledge. In such cases, modifying an existing custom or third-party administration tool so that it supports UNIX attribute management or creating a new tool is probably required.

  • Adapt user data management policies

    [End State 2]

    The UNIX operations team should already have user data management policies in place for a large environment. You must modify this information to meet the requirements of your policies for managing Active Directory users and groups, and you must incorporate your new policies into your Active Directory operations guides.

    If the current UNIX authorization solution uses multiple data stores, such as the /etc/passwd files on each UNIX-based computer, the policy for user management might be limited (or nonexistent) or might not translate well to Active Directory because the use of multiple data stores allows for different user data assignments for the same user.

    Management policies need to cover:

    • UIDs and primary GIDs. A UNIX user in Active Directory can have only one UID and primary GID to access all UNIX-based computers.

    • Home directories. The home directory defined for a UNIX user in Active Directory must be a valid path on all UNIX-based computers that the user attempts to access. In most enterprises, home directories are stored centrally on a file server and shared out via NFS and, typically, automount is used to mount the home directories on each UNIX-based computer in a consistent way. That is, when user1 logs on to the UNIX-based computer unixhost1, user1's home directory path is set automatically to /home/user1 by automount. Likewise, on any other UNIX-based computer that user1 logs on to, /home/user1 is the home directory path and name.

      If local home directories are used or if home directories are centralized but not consistently mounted, user1 might have a home directory of /home/user1 on one computer but the home directory might be /home/userA on a different computer. However, user1 can have only one home directory path in Active Directory. Therefore, your policies must ensure that consistent local home directories are created on all computers that a user might access.

    • Shell. The shell defined for each UNIX user in Active Directory must be a valid shell on all UNIX-based computers on which the UNIX user will log on. Some UNIX or Linux operating systems support all shells, but others support only some shells.

    • Group membership. A UNIX user in Active Directory has a single set of group memberships—secondary GIDs. If multiple data stores were previously used, it is possible that the same GIDs represented different groups with different permissions on different computers. Consolidating this might provide incorrect access to some users.

Integrating the user provisioning of UNIX user accounts in Active Directory accounts with your pre-deployment user provisioning or identity management system is often the key to successful administration of the interoperability solution. Whether user provisioning is a large or small task depends on your existing network environment.

Service Desk

The role of service desk personnel is to provide effective problem-solving for employees so that employees can continue to work with minimal interruption or resume working as quickly as possible after an interruption occurs.

The Service Desk SMF tasks important for the successful operation of your UNIX-to-Windows interoperability solution include the following:

  • Designate a dedicated transition team

    [All solutions]

    Some organizations find it useful to have a dedicated transition team of service desk personnel to whom all issues surrounding the solution are routed immediately. Based on their experience supporting the new solution, this team can tailor service desk processes to the newly heterogeneous environment and then pass the responsibility for supporting the solution back to regular service desk personnel.

  • Put in place an escalation process

    [All solutions]

    For critical systems, ensure that significant incidents can be escalated to someone who can solve the problem even during weekends and holidays.

    Make sure that any needed support or consulting contracts are in place so that, if needed, incidents can be escalated to vendors or to outside support agencies or consultants who can support your UNIX-to-Windows interoperability solution.

  • Review tests , pilot deployment , and production deployment

    [All solutions]

    Review the tests performed during the Stabilizing Phase described in Volume 2: Chapter 4, "Developing a Custom Solution."

    Review problems encountered by members of the Test and Release Management teams during the Stabilizing Phase and during the Deploying Phase.

  • Take training and maintain training information

    [All solutions]

    Training materials for operations personnel were created by members of the User Experience team in the Developing Phase and updated in the Stabilizing Phase. Team members who have not yet had this training should be offered this training now.

    Training materials contain information for service desk personnel about supporting UNIX users who switch to the new UNIX-to-Windows interoperability solution. Training topics include:

    • Can't log on. Guidelines for how to respond to calls from UNIX users whose accounts are now Active Directory–enabled if they experience problems when logging on.

    • UNIX terms. Training in UNIX terminology for Windows service desk personnel who are currently unfamiliar with UNIX.

    • UNIX command line. Training in understanding and using UNIX commands and command-line interfaces for Windows service desk personnel who are currently unfamiliar with UNIX.

    • Password change procedures. Training in UNIX user password change procedures if these are different from the existing Windows (for Windows service desk personnel) or UNIX (for UNIX service desk personnel) user password change procedures.

      If an enterprise password change tool is not used, UNIX users can use the UNIX Kerberos password change tool, kpasswd, for manual password changes. In most environments, the kpasswd tool is a better choice for Kerberos password changes against Active Directory than the familiar UNIX passwd tool because configuring the passwd tool to support Kerberized password change might cause it to not work as expected for all types of password changes (local and Active Directory). For instance, in some cases the passwd tool might not comply with Active Directory password policies or might prompt repeatedly for the new password. We recommend that you use the UNIX Kerberos kpasswd tool for Kerberos password changes, and use the UNIX passwd tool for local password changes.

    • Windows terms. Training in Windows terminology for UNIX service desk personnel who are currently unfamiliar with Windows.

    • Active Directory. Training in Active Directory administration and graphical user interfaces for UNIX service desk personnel who are currently unfamiliar with Windows.

    • Active Directory UNIX attributes. Training in UNIX attributes and the Windows Services for UNIX attributes snap-in to Active Directory Users and Computers for Windows administrators.

    If you encounter issues not covered in the training materials, update the training materials accordingly.

  • Require a password change after any password reset

    [All solutions]

    When you reset a password for an end user, it is good security practice to require the user to perform another password reset. This can be done through a custom or third-party password management tool, or manually as follows:

    • Solaris 9 users

      If a Solaris user is not currently logged on, configure the account to require a password change the next time the user logs on.

      If a Solaris user is already logged on, ask the user to change the password again with the kpasswd command and, if needed, provide instructions about how to use kpasswd.

    • Red Hat 9 users

      If a Red Hat user is not currently logged on, you cannot configure the account to require a password change the next time the user logs on.

      For a Red Hat user, the only option is to ask users to change their passwords while logged on or the next time they log on by using the kpasswd tool.

Incident Management

Incident management ensures that incidents are detected and that service requests are tracked. Operations personnel responsible for incident management prioritize incidents and route them to the correct support resources. New incidents are checked against known errors and problems so that any previously identified workarounds can be located quickly.

The Incident Management SMF tasks important for the ongoing successful operation of your UNIX-to-Windows interoperability solution include the following:

  • Create interoperability guidelines for incident management staff

    [All solutions]

    Incident management guidelines for operations personnel who support separate UNIX and Windows environments are different, and each environment is typically supported by different teams. When an interoperability solution is deployed, you must create new guidelines specific to your UNIX-to-Windows operability solution when the solution is deployed in your network environment.

    These guidelines should document:

    • What information must be collected from UNIX users with Active Directory–enabled accounts who report problems.

    • How to track these service requests.

    • How to prioritize and route these service requests.

    • Which errors and problems are known to exist for your UNIX-to-Windows interoperability solution, and whether workarounds for those issues are available.

    • What the escalation path is for significant incidents (see "Service Desk").

  • Review and revise existing UNIX incident management guidelines

    [All solutions]

    Review existing procedures for managing UNIX incidents (before the interoperability solution was deployed) and adapt these procedures as needed to suit the now heterogeneous environment.

  • Review testing , troubleshooting , and tool information contained in the following sources:

    [All solutions]

    • Volume 2: Chapter 5, "Stabilizing a Custom Solution"

    • Appendix C: "Kerberos and LDAP Error Messages"

    • Appendix D: "Kerberos and LDAP Troubleshooting Tips"

    • Appendix E: "Relevant Windows and UNIX Tools"

Service Level Management

The Service Level Management SMF defines the service levels that IT Operations will provide to support customers within the organization and defines metrics to evaluate the cost-effectiveness, quality, and reliability of IT services. Service level management includes defining the criteria by which your organization benefits from IT services.

Service level management tasks important for the successful operation of your UNIX-to-Windows interoperability solution include the following:

  • Adapt your existing Active Directory service level management policy

    [All solutions]

    Typically, most organizations have already defined their service level requirements for the Active Directory infrastructure, and you should continue to follow that model. However, it might be necessary to expand the policy to support existing service level agreements (SLAs) specific to UNIX applications if these applications will be incorporated into the solution.

    Examine existing SLAs carefully to determine their impact on the interoperability solution and the components—including Active Directory—that the solution relies on.

Financial Management

Financial management, in the context of MOF, refers to budgeting for IT services. The Financial Management SMF evaluates any new IT solution from a cost-benefit perspective to determine its value to the organization.

Financial management tasks important for the successful operation of your UNIX-to-Windows interoperability solution include the following:

  • Determine contract costs

    [Open Source solutions]

    Determine required levels of contracted support and consulting services (if any).

    Native OS solutions use only components that are distributed as part of the operating system by the operating system vendor. Open source solutions use the native operating system as a foundation but add Kerberos and LDAP components and tools, which are available as open source software and free downloads from third-party companies. Open source solutions, especially on Red Hat, provide many additional features that the native OS solutions lack but, because they are not supported by the operating system vendors, add a level of complexity to develop and support.

    Open source solutions for End State 1 use free software from a third-party vendor but do not require you to build or compile that software. Open source solutions for End State 2 require that you compile and build software for LDAP authorization and for supporting components. Therefore, you might not need a sophisticated development environment and team to evaluate or deploy a native OS solution or an open source End State 1 solution. However, for an End State 2 open source solution, your organization must either have in-house administrators with the skills to build this technology or must contract with a third party for assistance.

    Ongoing support costs for open source solutions might be greater, especially if existing contracts are in place for operating-system vendor support. The open source solutions, especially for End State 2, will require either maintaining a sophisticated in-house support team or contracting with a third party to provide vendor-level support.

  • Determine licensing costs

    [Commercial solutions only]

    Determine whether additional licenses are required. This requirement applies only to commercial solutions, such as the Centrify DirectControl or Quest VAS solutions.

Availability Management

Availability management is responsible for managing the routine risks to availability that can be reasonably expected to occur on a day-to-day basis. Many organizations that participate in the global economy require that their IT services remain available 24 hours a day for 365 days a year in order to meet customer expectations. The Availability Management SMF is responsible for ensuring either that incidents that affect service availability do not occur or that timely and effective action is taken if they do.

Availability management tasks important for ensuring the availability of your UNIX-to-Windows interoperability solution include the following:

  • Ensure availability of Active Directory and DNS servers

    [All solutions]

    This includes:

    • Be prepared to bring Active Directory or DNS servers back online quickly if one or more become unavailable.

    • Make sure that an appropriate number of Active Directory and DNS servers are installed so that, if one or more become unavailable, others are still available to service Windows and UNIX clients.

      Windows provides for logon with cached credentials for Windows clients if no Active Directory server can be reached. Although the commercial solutions described in this guide, Centrify DirectControl and Quest VAS, do support logon with cached credentials for UNIX clients, the do-it-yourself solutions described here do not. If no Active Directory servers are available, UNIX users with Active Directory–enabled accounts will not be able to log on to their UNIX-based computers. In some instances, even local users (including root) might not be able to log on.

    • Whenever a particular Active Directory server is unavailable for an extended period of time, be prepared to push out new configuration files to the UNIX clients that reference the new Active Directory server. Typically, this process is similar to the one developed for the initial deployment of the solution. For more information, see Volume 2: Chapter 5, "Stabilizing a Custom Solution."

    • Whenever a particular DNS server is unavailable for an extended period, whether DNS on Active Directory or another DNS data store is used, be prepared to update the DNS configuration in the UNIX client computers to reflect this change. UNIX-based computers are especially sensitive to host name resolution failures. The loss of a primary DNS server will affect not only the solution on this computer but the functionality of the computers overall.

      Because UNIX clients are configured to direct authentication and authorization requests to a specific Active Directory server instead of to the first available server through referrals (as is the case for Windows clients), UNIX clients have a greater availability requirement.

Service Continuity Management

The Service Continuity Management SMF is closely related to the Availability Management SMF because the goal of each is to eliminate risks to the availability of IT services. However, whereas the prime focus of availability management is handling the routine risks to availability that can be reasonably expected to occur on a day-to-day basis, service continuity management handles rare, expensive, or unanticipated risks.

Ensuring the continuity of IT services is accomplished through a balance of risk-reduction measures, such as resilient systems, and recovery options, including backup procedures and disaster recovery planning. Successful implementation of contingency management measures can be achieved only with visible senior management commitment and the support of all members in the organization.

The primary service continuity management task related to ensuring the availability of your UNIX-to-Windows interoperability solution in the event of a major risk to its continued operation is the following:

  • Integrate your UNIX-to-Windows interoperability solution into your overall plan

    [All solutions]

    Update your current service continuity management plan and procedures to include risk management for your UNIX-to-Windows interoperability solution.

    If no plan or procedures currently exist, consider developing them now.

Capacity Management

Capacity management refers to planning, justifying, and managing appropriate levels of network resources needed by an organization. The goal of the Capacity Management SMF is to optimize capacity and improve system and network performance.

In the context of your UNIX-to-Windows interoperability solution, capacity management includes ensuring that Active Directory servers are not overloaded as a result of handling UNIX traffic in addition to Windows traffic.

Capacity management tasks important for the successful operation of your UNIX-to-Windows interoperability solution include the following:

  • Use existing Windows capacity management guidelines when adding UNIX clients

    [All solutions]

    The additional load caused by adding Active Directory–enabled UNIX clients to your Active Directory infrastructure is similar to the additional load caused by adding additional Windows clients. This is because both Windows and UNIX clients in an interoperability solution use Active Directory–based Kerberos authentication and Active Directory–based LDAP authorization.

    However, the additional load caused by adding Active Directory–enabled UNIX clients might be somewhat greater than when adding Windows clients because UNIX-based computers tend to have multiple users. One UNIX-based computer with multiple simultaneous users or constant use (24 hours a day, seven days a week) places a higher load on Active Directory servers than UNIX-based or Windows-based computers that are typically used only by one person.

  • Manage SSL performance issues (if any)

    [Open Source] [End State 2] [Solaris]

    UNIX-to-Windows interoperability solutions that use public key technology for Secure Sockets Layer (SSL) for LDAP proxy authentication and authorization data retrieval might experience impaired performance. Using SSL is more processor-intensive than not using SSL. Using certificate public key–based SSL authentication is typically more processor-intensive than using Kerberos SSL authentication. In your environment, you might need to address this performance issue.

    Whether you need to take action to improve performance is highly dependent on the level of use that UNIX-based computers included in the solution receive and the type of activities involved. For instance, applications, tools, or commands that retrieve LDAP data from Active Directory frequently or in large volume create a heavier load than similar software that retrieves data infrequently. An action as simple as running a directory listing of a large directory or directory tree in long form (that is, running the ls command with the -l switch) retrieves a large volume of data from Active Directory. This is especially true if the NSCD service is not used on the UNIX-based computer or if the data requested is not data that was previously cached.

    Possible solutions include:

    • Adding additional processors to your Active Directory servers.

    • Adequately load balancing the clients that communicate with Active Directory.

    • Adding additional Active Directory servers.

    • Adding hardware cryptographic accelerators that speed up SSL operations to some or all Active Directory servers.

For more information about capacity management for the custom solutions in this volume, see "Capacity and Stress Tests" in Volume 2: Chapter 5, "Stabilizing a Custom Solution." Detailed guidelines for monitoring and testing Active Directory, server, and network performance are beyond the scope of this guide. For more information, see "Planning Domain Controller Capacity" at https://go.microsoft.com/fwlink/?LinkId=18115.

Workforce Management

Workforce management is concerned with recruiting, developing, and retaining staff who can meet the IT operations needs of your organization.

The Workforce Management SMF tasks important for the successful operation of your UNIX-to-Windows interoperability solution include the following:

  • Cross-train Windows and UNIX operations staff

    [All solutions]

    To support your UNIX-to-Windows interoperability solution effectively, it is important that you provide training about Windows (especially Active Directory Kerberos and LDAP) to UNIX administrators and that you provide training about UNIX (especially authentication and authorization topics as well as UNIX command-line interfaces) to Windows administrators.

  • Maintain or contract for UNIX expertise

    [All solutions]

    Although Active Directory servers now provide authentication and authorization services to your UNIX clients, it is important to retain operations personnel with UNIX enterprise-level expertise who understand UNIX authentication and authorization systems. You will need to have this expertise available at all times as long as your network includes UNIX-based computers.

    Alternatively, you can work with third-party consulting or services organizations to keep these skills available to your organization.

Download

Get the Windows Security and Directory Services for UNIX Guide

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions