Managing and Evolving Operations After Deployment

In previous sections, you prepared for deployment, migrated existing users, configured automated provisioning for new users and groups, and added one or more custom roles for privilege management. Most of these activities are related to the initial deployment and extending deployment to additional sets of target computers and interactive users.

This section discusses management activity, evolving operational security, and adding services to extend authentication and authorization after deployment. Often, at this stage, the deployment project team begins to transition activity to an operations team or support staff.

Understanding How Server Suite Software Affects Operations

Through Active Directory, Server Suite software provides a consolidated solution to authentication, authorization, and policy management for Linux, UNIX, and Mac OS X computers. Because of this consolidation, however, you may need to make changes or additions to the IT tasks or operational procedures you currently have in place. Therefore, when you deploy Server Suite software in a production environment, you should consider how it impacts the management tasks typically performed by operations staff members.

The routine tasks that may be affected by adding Server Suite software to the environment fall into the following categories:

Change management
System administration
Security administration
Service desk operations
Capacity management

Understanding Change Management Activities

Change management typically involves testing and installing updates to the operating system or installed applications. For example, most organizations follow a controlled process for reviewing and implementing changes to the operating system because of patches or new releases.

If you are preparing to update the operating system, the support staff should also plan to test that user log-ons and role assignments continue to function correctly after update. If a system patch or update affects the operation of Server Suite software, you should contact Customer Support to determine whether the patch is supported.

Staff members should also periodically review new and maintenance releases of Server Suite software to get the latest features, fixes to known issues, and enhancements requested by Server Suite customers. After downloading the software, you can review the release notes included in each package to determine what’s changed and the suitability of the update for your organization.

Understanding System Administration Activities

Most system administration tasks involve managing users and groups. After deploying Server Suite software, this information is centralized in Active Directory for both Windows and non-Windows computers. Therefore, any administrative action for a user account affects that user on both Windows and UNIX computers. For example, if you disable a user account in Active Directory, the user will be unable to log on to any Windows or UNIXbased computer in the forest.

Typically, there is a period of time where staff members must use one set of steps for provisioning users and groups on the computers not yet joined to the domain and another set of steps for provisioning users and groups on computers that have successfully joined the domain. After you complete the migration to Active Directory, you can leverage the processes and tools you use for provisioning Windows users and groups for ongoing administration of UNIX users. For example, you can use Active Directory Users and Computers, in-house custom scripts, Access Manager, ADEdit, or another management tool to perform administrative tasks.

After deployment, you should prepare any site-specific or platform-specific instructions the operations staff should follow if you are making changes to the processes or tools they are familiar with.

Understanding Security Administration Activities

Security administration involves ensuring that operators are granted the appropriate rights for administering the computers and attributes that are required as part of their job but are prevented from accessing or changing computer settings outside their areas of responsibility.

Delegated Administration

Server Suite enables administrators to explicitly delegate management tasks to the appropriate users and groups on a zone-by-zone basis.

Password Policy Enforcement

Server Suite enables you to use existing Active Directory password policy rules, such as the minimum password length, complexity requirements, expiration, and allowed number of logon failures to allow before locking an account for both Windows and UNIX users.

Privileged Account Management

Server Suite enables you define rights, roles, and role assignments to control what users can do and who can execute privileged commands. You can also map privileged local accounts to Active Directory accounts to ensure better password security for those accounts. For example, the local root user account has full access to all data and can manipulate all settings on a UNIX computer. Mapping the local root user to an Active Directory user account enforces the Active Directory password policies on the account and makes it more difficult for an unauthorized user to obtain escalated privileges on the UNIX computer.

Understanding Service Desk Operations

Active Directory and Server Suite simplify help desk and service desk operations by:

Enabling centralized administration for tasks such as adding new users or granting access to new computers.
Consolidating user passwords and reducing the need for password resets.
Simplifying troubleshooting for log on failures for UNIX users.

You should provide help desk staff with troubleshooting instructions to help them diagnose and resolve failed authentication or authorization tickets.

Understanding Capacity Management Activities

During the deployment of Server Suite Agents, you should monitor and analyze network traffic and domain controller replication to determine how well your environment handles the extra load of UNIX users and computers in Active Directory. In general, Server Suite software is configured to use minimal system resources and network bandwidth. In practice, however, you should monitor and evaluate the volume of traffic to determine its impact on performance across the network and the performance experienced by users logging on to UNIX workstations and servers.

If the network traffic or resource usage exceeds your expectations, you may want to modify the default configuration to better suit your network topology. For example, Server Suite provides numerous group policies and configuration parameters that you can modify to optimize network activity or control how much data is stored locally on individual computers.

Determining Whether You Need More Resources

In most cases, deploying Server Suite software does not noticeably affect the performance of the network or domain controllers. However, if you have a widely distributed network or replication delays, you should analyze your network’s capacity to handle the additional load of UNIX users and computers to determine whether you need to make changes to ensure optimal performance and availability. For example, the following factors may require you to allocate additional resources:

If the UNIX computers are in a different physical location than the domain controllers that they access, you may want to install a domain controller on a computer that is physically closer to the UNIX computers to reduce long-distance network traffic and the chance of replication delays.
If you need to ensure availability in the event of a network or server failure, you should ensure that you have an adequate number of domain controllers to support the UNIX computers when they need to fail-over to a backup domain controller.
If you add a large number of UNIX users to the Active Directory domain, apply your standard method for balancing domain controllers per number of users.
If you add a large number of UNIX computers to the Active Directory domain, apply your standard method for balancing domain controllers per numbers of computers.
If you move a large number of UNIX users and groups from a local directory (/etc/passwd and /etc/group) to Active Directory, you may need additional network bandwidth because authentication and authorization requests are now done over the network.

For more information about modifying configuration parameters, see the Configuration and Tuning Reference Guide.

Understanding How Caching Facilitates Lookups

Server Suite Agents store credentials in a local cache to reduce the network traffic required to look up information in the directory. For example, if a user executes the directory listing command in a UNIX command shell (such as with the ls -l command), the command looks up and displays a listing of files along with their attributes, such as the owner of each file.

However, a file’s owner is stored as a number—the user’s UID—on UNIX-based computers, but because the ls command displays the owner as a name and not a number, the ls command must look up the actual user name associated with the file owner’s UID. Because UNIX UIDs and user names are stored in Active Directory, this lookup request must be serviced by Active Directory. If a large number of files are displayed when the ls command is run, this creates a substantial amount of lookup traffic between the UNIX computer and the Active Directory domain controller.

Server Suite reduces this traffic by caching the lookups so that the information does not have to be retrieved from the Active Directory each time a lookup is required. Commands such as ls check the local cache first for the relevant information instead of retrieving the information from Active Directory every time.

Troubleshooting Logon Failures

If a user attempts to log on to a computer that is in a Server Suite zone and the logon fails, the problem is typically caused by one of the following:

Users attempting to log on to a computer they are not authorized to use.
Users have an incomplete profile in the zone where the computer they are attempting to use is located.
Users have not been assigned an appropriate role that allows logon access.
Users have typed their non-Active Directory password or typed the wrong password more times than allowed.
Local or group policy settings are applied to the computer to prevent access.

To investigate these potential problem areas:

Check whether the local UNIX computer can connect to the Active Directory domain controller.
- Log on to the computer using a locally authenticated user, such as the local root user.
- Run the ping command with the name of an appropriate domain controller in the forest.
  
  For example, if the local computer is joined to the snowline.org forest, the command might look similar to this:
  
  su -
  Password:
  ping shasta.snowline.org
  
  If the command receives a reply from the domain controller, the DNS service is functioning and the local computer is able to locate the domain controller on the network. If the ping command does not generate a reply, you should check your DNS configuration and check whether the local computer or the domain controller is disconnected from the network.
Check Active Directory information by running the adinfo command. The output from this command should appear similar to the following:

Local host name: magnolia
Joined to domain: snowline.org
Joined as: magnolia.snowline.org
Current DC: shasta.snowline.org
Preferred site: Default-First-Site-Name
Zone: snowline.org/Acme/Zones/cascade
Last password set: 2017-12-21 11:37:22 PST
CentrifyDC mode: connected

If the mode is disconnected, check whether adclient is running and network connectivity. On a slow network adclient may drop the connection to Active Directory if there is a long delay in response time.

If the output displays an <unavailable> error, you should try running the adleave command to leave Active Directory, re-run the adjoin command, then re-run the adinfo command. For example:

adleave --force
adjoin --user skip --zone cascade snowline.org
Password:
adinfo

If a problem still exists, check the DNS host name of the local computer and the domain controller, the user name joining the domain, and the domain name you are using.
Check the clock synchronization between the local UNIX computer and the Active Directory domain controller.

If the clocks are not synchronized, reset the system clock on the UNIX computer using the date command.
Check for denied users and groups in the /etc/centrifydc/centrifydc.conf file or the Login Controls group policy. For example, open the centrifydc.conf file in a text editor, such as vi:

vi /etc/centrifydc/centrifydc.conf
- Search for the pam.deny.users line and make sure that the user who is trying to log on is not listed.
- Search for the pam.deny.groups line and make sure that the user who is trying to log on is not a member of any group that is listed on this line.
Check the contents of the system log files or the centrifydc.log file after the user attempts to log on. You can use information in this file to help determine whether the issue is with the configuration of the software or with the user’s account.
Check for conflicts between local user accounts and the user profiles in Active Directory by running the getent command. For example:

getent passwd

This command displays a list of local and Active Directory users with access to the computer. If the user’s name is not listed but other Active Directory users are listed, the problem may be in the user’s Active Directory account settings or UNIX profile.

If no Active Directory users are listed in the output of the command, check whether adclient is running and whether the Active Directory domain controller is available.
Check the user’s Active Directory account settings using Access Manager or Active Directory Users and Computers. For example:
- Check whether the user has a UNIX profile for the local computer’s zone.
- If the user has a UNIX profile in the zone, check whether the profile is currently enabled.
- If the user has an enabled UNIX profile, check the user’s group membership to determine whether it is a local group defined in a different domain than the computer account.
- Check whether the user’s account has been disabled or locked.
- Check whether any user-based group policies have been applied to the user account that may prevent access to the UNIX computer.
Enable logging of adclient activity using the addebug command. For example:

/usr/share/centrifydc/bin/addebug on

This command enables extensive logging of each operation performed by the adclient process in the /var/log/centrifydc.log file. You can use the information in this file to further diagnose the cause of any problems or to enable Server Suite’s support staff to assist with resolving any issues.

Evaluating Additional Services And Integrations

After you have deployed Server Suite Agents to implement an Active Directory-based security and directory services, you may want to explore other ways to take advantage of Active Directory’s infrastructure. In evaluating ways to extend your security and directory services, you must first understand:

How the UNIX servers and workstation that are joining the domain are used
Which applications are accessed locally and which applications are accessed by remote users
How the servers and workstations are managed, and whether administrators are local users or remote users
Whether there are specific additional IT services you want to enable
Whether there are specific controls you want to apply

As a starting point, you should consider whether computers joining the domain are workstations that primarily support local logon sessions or servers that require few, if any, local logon sessions. In many cases, UNIX computers have few interactive users but are frequently used as application servers that host database or web applications. For those computers, you should determine whether Active Directory authentication and authorization is primarily for administrators who manage the server or for users who log in to access the application.

Some of the ways you can extend and evolve the deployment of Server Suite software include:

Adding authentication service for applications
Adding custom reports for auditing UNIX properties
Adding group policies
Adding support for NIS clients
Using programs optimized for Kerberos authentication
Integrating with products from other vendors

Adding Authentication Service for Applications

Because Active Directory and Server Suite use Kerberos and LDAP standards, many Kerberos-enabled or PAM-enabled applications can use Active Directory for authentication and authorization service with little or no configuration. One way you can evolve your deployment is to add support for single sign-on to additional applications.

Supporting Single Sign-on for Kerberos-enabled Applications

The primary way that Server Suite supports single sign-on is through Kerberos. Kerberos provides a ticket-based authentication mechanism that is the default method for authentication in Active Directory. When a user logs on to a computer that uses Active Directory authentication, a Kerberos ticket is issued to the user and that ticket allows the user to access data, applications, other computers, and other sessions without having to present credentials again. This silent authentication that takes place in the background as users browse network shares or run applications is the key to enabling a single sign-on experience.

Many applications are Kerberos-enabled by default or can be configured to support the use of Kerberos tickets. By default, when a computer joins an Active Directory domain, Kerberos requests are forwarded and serviced by the Kerberos Key Distribution Server on the Active Directory domain controller. Therefore, in most cases, existing Kerberos-enabled applications can authenticate and authorize access without any modification.

If you use an application that is not configured to use Kerberos authentication by default, however, you may need to modify configuration options or use specific command line options to support single sign-on.

In addition, users must be assigned to a role with the Non-password (SSO) login is allowed system right. This right is enabled in the predefined UNIX Login role. If you create custom roles and want to allow single sign-on, you should select this system right when defining the role.

Supporting Single Sign-on for PAM-aware Applications

Pluggable Authentication Modules (PAM) provide a flexible mechanism for authenticating users regardless of the underlying authentication system. Most programs and applications that rely on user authentication use PAM.

The agent uses its own PAM module, pam_centrifydc.so, to direct PAM requests to Active Directory. Therefore, in most cases, existing PAM-enabled applications can authenticate and authorize access without any modification and support single sign-on without any special configuration.

One known exception, however, is that most database applications support PAM authentication, but do not enable it by default. To support single sign-on for database applications, you should modify the database configuration to enable PAM authentication.

Supporting Active Directory Authentication for Apache and Java Applications

Most Web and J2EE platforms provide their own native authentication and authorization services for Web developers to use. With Server Suite, you can choose to extend the native interfaces to enable web applications to provide single sign-on capability or redirect authentication requests to Active Directory instead of a native authenticator.

Supporting Database Server Applications

Most database servers provide their own native authentication and authorization services. With Server Suite, you can choose to extend the native interfaces to enable supported database servers to provide single sign-on capability or redirect authentication requests to Active Directory instead of a native authentication service.

Adding Custom Reports for Auditing Unix Properties

Server Suite includes several default reports that you can use to monitor and audit access to the computers in your environment. The default reports provide detailed information about your UNIX users, groups, computers, zones, and licenses, and enable you to verify which users have access to specific computers, zones, or applications. Default reports also provide easy access to the information that you require for auditing, business planning, and regulatory compliance. After you generate a report, you can save the report in the following formats:

Microsoft Excel (.xls)
Microsoft Word (.doc)
Adobe Acrobat (.pdf)
XML document (.xml)

For example, after generating a report with information about the users in each zone, you can save it as a Microsoft Excel spreadsheet (.xls), and import the information into an Excel Workbook to create a Charge Back report on account usage for each department.

One of the most common ways to evolve the Server Suite deployment is to create custom reports that are specifically tailored to your organization and auditing requirements. The Access Manager console includes a Report Wizard that allows you select the specific Active Directory objects and properties and the relationships on which you want to base the report.

For information about creating and generating custom reports, see the Administrator’s Guide for Linux and UNIX.

Adding Group Policies

For many companies, centralized policy management and configuration control is just as important as centralized identity management. With Server Suite, you can apply group policy settings from Active Directory to the non-Windows computers and UNIX users.

Evaluating Existing Policy Settings

If you have applied any domain-wide policies in the Active Directory forest, you should review what the policy settings are and where they are enforced for Windows-based computers. You should then evaluate which policy settings, if any, are applicable for computers running UNIX, Linux, or Mac OS X operating systems. For example, most organizations establish a policy for password complexity. You can view your current password policy settings by clicking Domain Security Policy under Administrative Tools to open the Default Domain Security Settings, then select Password Policy.

If you enable any password policy settings for the domain, they automatically apply to UNIX users and managed computers because Active Directory uses these settings when authenticating users. If you enable or change any of the default domain policy settings, you should consider how they affect UNIX users and computers. For information about the standard Windows group policies that apply for UNIX, see the Group Policy Guide.

Adding Server Suite-specific Group Policies to a GPO

You can add Server Suite-specific configuration settings to any Group Policy Object applied to any site, domain, or organizational unit in the Active Directory forest. You can then manage the specific policies enabled and settings applied centrally through the Group Policy Object Editor on Windows.

Each GPO can consist of configuration information that applies to computers, configuration information that applies to users, or sections of policy that apply specifically either to users or to computers. You link a GPO to an Active Directory organizational unit, domain, or site. Windows then applies the policy settings based on an established hierarchical order.

The Server Suite-specific group policy settings available for users and groups are defined separate administrative templates (.adm or .xml files) that can be added to any GPO. If you enable any of the policy settings, they are written to a virtual registry on the UNIX computer. The Server Suite Agent then runs a set of local mapping programs that read the virtual registry and modify local configuration files to implement the setting defined by the group policy. You can also create your own custom administrative template and mapper programs to implement custom group policies.

For more detailed information about creating and managing Server Suite-specific group policies, see the Group Policy Guide and Active Directory documentation.

Adding Support for NIS Clients

You can extend Server Suite software to provide NIS service from a Server Suite-managed computer, acting as a NIS server, to NIS client requests using Active Directory as the central data store for NIS maps.

There are many scenarios in which adding the Server Suite Network Information Service (adnisd) to your infrastructure can enable you to integrate Server Suite and Active Directory with other enterprise solutions. For example, the adnisd Network Information Service and Server Suite zones can be used to centrally manage and map multiple UNIX identities to a Windows user account for access resources stored on EMC Celerra Network Servers or Network Appliance Filers. Active Directory remains the central identity store and zones remain the primary way of mapping UNIX profiles to a user account, but the Server Suite Network Information Service enables you to deliver the appropriate information to servers and devices across the network.

Using the Server Suite Network Information Service in conjunction with the Server Suite Agent is a scenario like this provides the following advantages:

Redundancy. As an NIS client, the Celerra Network Server can find NIS servers by broadcasting on the local subnet. If a subnet hosts more than one Server Suite-managed computer acting as a NIS server, the Celerra or NetApp server can fail over from one NIS server to another NIS server on that subnet, thus enabling multiple NIS paths to the same data held within Active Directory.
Multi-domain support. The Server Suite NIS service can provide user mapping data to NIS clients who may have an account anywhere within an Active Directory forest, including remote or child domains. Through the Active Directory Global Catalog, Server Suite Agents can find user mapping information for users anywhere across the forest.

Extending your deployment with the Server Suite Network Information Service also enables you to centrally manage network information and publish custom information to NIS clients throughout the network without modifying the underlying Active Directory schema.

Using Programs Optimized for Kerberos Authentication

As a management platform, Server Suite provides its own versions of commonly-used open source programs. For example, the following packages have been optimized to work with Server Suite software and Active Directory:

Standard MIT Kerberos utilities, such as kinit and kdestroy, are installed with the agent to support Kerberos keytab management for accounts in Active Directory.
Kerberos-enabled client programs such as OpenSSH, support Kerberos authentication and single sign-on for secure connections between Server Suite-managed computers.
An enhanced version of PuTTY supports Kerberos authentication for secure, remote access from Windows computers to Server Suite-managed computers.

Integrating with Products from Other Vendors

Server Suite software also integrates with products from many other vendors, such as Splunk, IBM DB2, SAP Netweaver and Secure Network Communication (SNC), and Quest ActiveRoles Server. In addition to Active Directory, you can use Server Suite software to extend other Microsoft services such as Services for Network File System (NFS), Microsoft Identity Integration Server (MIIS), and Microsoft Active Directory Federation Services (ADFS).

For more information about add-on packages, integration with other systems, or configuring Server Suite software to work with other products, see the Resource Center on the Delinea website.

Getting Assistance from Support

It is recommended that you take the following steps if you need assistance with an issue or have questions about the operation of Server Suite components:

Check the Support Portal on the Delinea website to search the Knowledge Base to see if your problem is a known issue or something for which there is a recommended solution.
- Open http://www.centrify.com/support/login.asp in a Web browser.
- Log in using your customer account information and password.
- Click Find Answer and type one or more key words to describe the issue, then click Find to view potential answers to your question. For example, to search for known issues, type known issues and click Find to see articles related to the known issues in different releases.
  
  If your issue is not covered in an existing Knowledge Base article or the Server Suite documentation set, you should open a case with Delinea Support.
Click Log a Case to open a new case using the Delinea Support Portal.

Alternatively, you can contact Delinea Support by email or telephone, if you prefer. Worldwide contact information is available in the “How to open a case and collect information for Delinea Support” Knowledge Base article (KB-0301).
Provide as much information as possible about your case, including the operating environment where you encountered the issue, and the version of the Delinea product you are working with, then click Submit to open the case.

Before or after opening a support case, you may need to collect additional information about your environment. To help ensure your issue gets resolved quickly and efficiently, you should take the following steps to gather as much information as possible:

Verify the Server Suite Agent is running on the computer where you have encountered a problem. For example, run the following command:

ps –ef | grep adclient

If the adclient process is not running, check whether the watchdog process, cdcwatch, is running:

ps –ef | grep cdcwatch

The cdcwatch process is used to restart adclient if it stops unexpectedly.
Enable logging for the Server Suite Agent. For example:

/usr/share/centrifydc/bin/addebug on
Create a log file for the Mac OS X Directory Service. For example:

killall –USR1 DirectoryService
Run the adinfo command to generate a report that describes the domain and current environment. For example:

adinfo --diag --output filename
Duplicate the steps that led to the problem you want to report. For example, if an Active Directory user can’t log in to a Server Suite managed computer, attempt to log the user in and confirm that the attempt fails. Be sure to make note of key information such as the user name or group name being, so that Delinea Support can identify problem accounts more quickly.
Verify that log file /var/log/centrifydc.log or /var/adm/syslog/centrifydc.log exists and contains data.
Generate information about Active Directory domain connectivity and configuration files by running the following command:

adinfo --support

This command writes output to the file /var/centrify/tmp/adinfo_support.txt.
If there is a core dump during or related to the problem, save the core file and inform Delinea Support that it exists. Delinea Support may ask for the file to be uploaded for their review.

If the core dump is caused by an agent process or command, such as adclient or adinfo, open the /etc/centrifydc/centrifydc.conf file and change the adclient.dumpcore parameter from never to always and restart the agent:

/etc/init.d/centrifydc restart
If there is a cache-related issue, Delinea Support may want the contents of the /var/centrifydc directory. You should be able to create an archive of the directory, if needed.
If there is a DNS, LDAP, or other network issue, Delinea Support may require a network trace. You can use Ethereal to create the network trace from Windows or UNIX. You can also use Netmon on Windows computers.
Create an archive (for example, a .tar or .zip file) that contains all of the log files and diagnostic reports you have generated, and add the archive to your case or send it directly to Delinea Support.
Consult with Delinea Support to determine whether to turn off debug logging. If no more information is needed, run the following command:

/usr/share/centrifydc/bin/addebug off