Architecture and Basic Operations

This section provides an overview of the Server Suite architecture and the components for Windows and non-Windows computers. It also describes the basic flow of operation when users log in or access applications, and what happens when an Active Directory domain controller goes down.

The information in this section is not required for planning a deployment. It is intended as background information that can help you understand the authentication and authorization process in some detail. If you want to proceed directly to planning the deployment, you can skip this section.

Server Suite Platform-Specific Components

Server Suite provide an integration layer between Active Directory in a Windows environment and computers running other operating systems or application environments. Because of this, Server Suite includes components for managing Active Directory-based objects in the Windows environment and agents that run on each server or workstation to be integrated into Active Directory.

Server Suite Components for Windows

On Windows, Server Suite includes management consoles and services to simplify the management and integration of Linux and UNIX computers and users into Active Directory.

The key components for Windows that you use in deployment are:

  • Access Manager console
  • Zone Provisioning Agent configuration panel and Windows service

There are several additional Windows components available for you to use, depending on the version of Server Suite software you install and the requirements of your environment. For example, Server Suite offers extensions for working with NIS maps and Active Directory group policies, as well as components to support a multi-tier architecture for auditing activity in user sessions and the Network Information Service to support agentless authentication service.

Components Installed on Managed Computers

On non-Windows computers, Server Suite software consists of the core Server Suite Agent (adclient), related libraries, and optional tools. The Server Suite Agent enables the local host computer—most commonly a Linux or UNIX computer—to join an Active Directory domain.

After the agent is deployed on a server or workstation, that computer is considered a managed computer and it can join any Active Directory domain you choose.

When a Server Suite-managed computer joins an Active Directory domain, it essentially becomes an Active Directory client and relies on Active Directory to provide authentication, authorization, policy management, and directory services. The interaction between the agent on the local computer and Active Directory is similar to the interaction between a Windows workstation and its Active Directory domain controller, including failover to a backup domain controller if the managed computer is unable to connect to its primary domain controller.

The following figure provides a simplified view of the integration between Windows and non-Windows computers through Server Suite software.

computer integration with Server Suite

To use Microsoft Active Directory to centrally manage access across different platforms, you need to do the following:

  • Prepare the Active Directory environment by installing the Access Manager console on at least one Windows computer and using the Setup Wizard to update the Active Directory forest.
  • Ensure each UNIX, Linux, or Mac OS X computer can communicate with an appropriate Active Directory domain controller through DNS.
  • Install the agent (adclient) on the UNIX, Linux, or Mac OS X computers that will be joining an Active Directory domain.
  • Run the join command and specify the Active Directory domain on each UNIX, Linux, or Mac OS X computers that needs to join an Active Directory domain.
  • Use Active Directory Users and Computers or Access Manager to authorize access to the UNIX, Linux, and Mac OS X computers for specific users and groups.

The next sections provide a more detailed discussion of the Server Suite architecture and a summary of what happens when a user logs on to a UNIX computer that has joined the Active Directory domain.

Storing Server Suite Properties in Active Directory

The Active Directory schema defines the object classes that can be stored in Active Directory, and the attributes that each object class must have, plus any additional attributes the object can have, and the object class that can be its parent. Schema definitions are also stored as objects in Active Directory. To store UNIX-specific attributes within the Active Directory schema, the schema must be able to include the properties that are associated with a UNIX user or group. For example, for a UNIX user, the schema needs to accommodate the following information fields:

  • UNIX user name
  • Password hash (optional)
  • Numeric user identifier (UID)
  • Primary group identifier (GID)
  • General information (GECOS)
  • Home directory
  • Default shell

Some of these information fields are similar to standard user class attributes in Active Directory. For example, the Active Directory Display Name (displayName) attribute typically stores a user’s full name—the same information typically stored in the GECOS field in an /etc/passwd file on a UNIX computer, so the displayName is used to define the contents of the GECOS field in a user’s UNIX profile. Depending on the Active Directory schema you have installed, some of the information fields required for logging on to UNIX computers might not have an equivalent Active Directory attribute.

If you are using the default Active Directory schema, Server Suite stores UNIX-specific attributes in an Active Directory class under its own parent container for zones. Server Suite then organizes the information about individual UNIX computers, users, and groups by zone.

If your organization has already deployed a Microsoft-supported set of UNIX schema extensions, such as those defined in the Windows Services for UNIX (SFU) schema extension, you can store UNIX attributes in the fields defined by that schema as an alternative to using the zones container.

If you have deployed the RFC 2307-compliant Active Directory schema, you can store UNIX attributes in the fields defined by that schema and organized into RFC 2307-compliant zones.

After you have installed Server Suite components on a Windows computer, the first time you open the Access Manager administrative console, a Setup Wizard updates the Active Directory forest to include the Server Suite properties for UNIX attributes. You can then use Access Manager, the Active Directory Users and Computers MMC snap-in, ADEdit commands, or PowerShell scripts to view and modify the UNIX properties for any user, group, or computer.

For RFC 2307-compliant zones, the group name and UNIX name are stored in the same CN attribute. Therefore, if you change a group’s name with its Active Directory Users and Computers’ property page, the UNIX name is changed in Access Manager as well.

Using Access Manager

Access Manager is the primary user interface for managing all of the Server Suite-specific information stored in Active Directory. With Access Manager, you can:

  • Manage access to all of your UNIX, Linux, and Mac OS X computers.
  • Set and modify user and group properties for all of your UNIX, Linux, and Mac OS X users and groups.
  • Create and manage zones and zone properties to simplify the process of giving users access to specific computers and migrating UNIX user accounts to Active Directory.
  • Add Active Directory users and groups to zones.
  • Import user and group information from local password and groups files or from NIS and NIS+ servers and domains.
  • Import and maintain network information from NIS maps such as netgroup, auto.master, and automount or create custom NIS maps.
  • Define and assign rights and roles that authorize or restrict access to specific computers and operations on managed computers.

You can also add other snap-ins to Access Manager or add Access Manager to another Microsoft management console snap-in. For example, you can add the Active Directory Sites and Services and Active Directory Domains and Trusts snap-ins to Access Manager to consolidate management activity.

Allowing and Blocking Domains for Access Manager

You can configure Access Manager so that it can connect to trusted domains by setting the following registry key with a list of trusted domains and/or forests. The type of key is REG_MULTI_SZ:

HKLM\SOFTWARE\Centrify\CIMS\AllowedTrusts

Configuring a list of domains this way can be particularly useful and faster when you have a large amount of domains. Enter each domain as a separate line in the Registry Editor window.

For example, to specify a single domain:

acme.com

For example, to specify multiple domains:

acme.com
foo.com

To block access to domains, you use the IgnoreTrusts key: HKLM\SOFTWARE\Centrify\CIMS\IgnoreTrusts.

Core Agent Components and Services

The Server Suite Agent makes a UNIX, Linux, or Mac OS X computer look and behave like a Windows computer to Active Directory. Once installed, the agent performs the following key tasks:

  • Joins UNIX, Linux, or Mac OS X computers to an Active Directory domain.
  • Communicates with Active Directory to authenticate users logging on to the UNIX, Linux, or Mac OS X computer, and caches credentials for offline access.
  • Enforces Active Directory authentication and password policies.
  • Extends Active Directory group policies to manage the configuration of UNIX users and computers.
  • Provides a Kerberos environment so that existing Kerberos applications work transparently with Active Directory.

Individual agents are platform-specific, but provide an integrated a set of services to extend Active Directory authentication, authorization, and directory service to managed computers. The following figure provides a closer look at the services provided through the Server Suite Agent:

agent architecture

As this figure suggests, the agent typically includes the following core components:

  • The core component of the agent is the adclient process that handles all of the direct communication with Active Directory. The agent contacts Active Directory when there are requests for authentication, authorization, directory assistance, or policy updates, and then passes valid credentials or other requested information along to the programs or applications that need this information.
  • The Centrify Pluggable Authentication Module, pam_centrifydc, enables any PAM-enabled program, such as ftpd, telnetd, login, and sshd, to authenticate using Active Directory.

For AIX and Mac OS X, the implementation is slightly different. For example, the agent for AIX can use PAM interfaces if you have configured the computer to use PAM modules or the interfaces in the Loadable Authentication Module (LAM) to handle behavior that on other platforms is done through PAM or NSS. Similarly, the agent for Mac OS X uses native interfaces where appropriate to provide services from Active Directory to the local computer.

  • The Centrify NSS module is added to nsswitch.conf so that system look-up requests use the agent to look up and validate information using Active Directory through LDAP.
  • The ADEdit Tcl application and procedure library and individual UNIX command line programs enable you to perform common administrative tasks, such as join and leave the Active Directory domain or change user passwords for Active Directory accounts interactively or within scripts to automate tasks.
  • The Server Suite-managed Kerberosenvironment generates a Kerberos configuration file (etc/krb5.conf) and a default key table (krb5.keytab) file to enable your Kerberos-enabled applications to authenticate through Active Directory. These files are maintained by the agent and are updated to reflect any changes in the Active Directory forest configuration.
  • The Server Suite local cache stores user credentials and other information for offline access and network efficiency.

In addition to these core components, the agent can also be extended with the additional software packages, including modified versions of programs such as Kerberos command line tools, OpenSSH, OpenLDAP, and PuTTY utilities. Server Suite-enabled versions of these programs allow you to use Active Directory accounts and Kerberos credentials for authentication, authorization, and policy enforcement services. Server Suite also provides authentication modules that enable you to configure single sign-on for web and database applications, and specialized extensions such as the adnisd Network Information Service, which enables you to publish information stored in Active Directory to NIS clients.

Key Operations Handled by the Adclient Process

The most important element in the agent is the adclient process. The adclient process runs as a single trusted service. This process is automatically added as a boot service and is started whenever you reboot a managed computer. The adclient process handles all of the direct communication with Active Directory and manages all of the operations provided through the other services.

The adclient process performs the following key tasks on managed computers:

  • Locates the appropriate domain controllers for the local computer based on the Active Directory forest and site topology published by the Windows DNS server. If a domain controller becomes unavailable, the adclient process automatically locates the next available domain controller to ensure uninterrupted service.
  • Provides Active Directory with credentials for the local computer account to verify the computer is a valid member of the domain.
  • Delivers and stores user credentials so that users can be authenticated by Active Directory and, once authenticated successfully, can sign on even if the computer is disconnected from the network for mobile access or if Active Directory is unavailable.
  • Caches query responses and other information, including positive and negative search results, to reduce network traffic and the number of connections to Active Directory and to ensure users can work uninterrupted and start new application sessions using their existing login credentials. All communication with Active Directory is encrypted to ensure security, and you can manage the cache through configuration parameters or group policy.
  • Creates and maintains the Kerberos configuration and service ticket files to allow existing Kerberos-enabled applications to work with Active Directory without any manual configuration.
  • Synchronizes the local computer’s time with the clock maintained by Active Directory to ensure the timestamp on Kerberos tickets issued by the KDC are within a valid range.
  • Resets the password for the local computer account in Active Directory at a regular interval to maintain security for the account’s credentials.
  • Provides all the authentication, authorization, and directory look-up services retrieved from Active Directory to the other Server Suite Agent services, such as the PAM service or the Apache authentication module.

How PAM Applications Work with Server Suite

Pluggable Authentication Modules (PAM) are a common mechanism for configuring authentication and authorization used by many UNIX programs and applications. If a program or application uses PAM for authentication and authorization, the rules for authenticating the user are configured in either the PAM configuration file, /etc/pam.conf or in application-specific files in the /etc/pam.d directory.

The Server Suite Agent for *NIX includes its own Pluggable Authentication Module (pam_centrifydc) that enables any application that uses PAM, such as ftpd, telnetd, login, and Apache, to authenticate users through Active Directory. When you join a domain, the pam_centrifydc module is automatically placed first in the PAM stack in systemauth, so that it takes precedence over other authentication modules.

The pam_centrifydc module is configured to work with adclient to provide a number of services, such as checking for password expiration, filtering for users and groups, and creating the local home directory and default user profile files for new users. The services provided through the pam_centrifydc module can be customized locally on a computer, modified through Active Directory group policy, or configured through a combination of local and Active Directory settings.

Working in conjunction with the adclient process, the pam_centrifydc module provides the following services for PAM-enabled programs and applications:

  • Requests the PAM-enabled application to prompt for a password when appropriate and verifies whether the application-provided user name and password are valid in Active Directory.
  • Checks whether the user’s password has expired in Active Directory. If the password has expired, the pam_centrifydc module prompts the user to change the password, and forwards the new password to the adclient process, which communicates the change to Active Directory.
  • Queries the adclient process to determine whether any access control policies are applied. For example, the pam_centrifydc module uses the information in the centrifydc.conf file to determine whether a local user attempting to log on is mapped to an Active Directory account, whether specific users or groups have been granted or denied permission to log on to the local computer, or whether Active Directory authentication should be ignored for a specific user or group.
  • Creates the local home directory and default user profile files for new users. The pam_centrifydc module uses skeleton files to set up the user environment when new Active Directory users log on to a managed computer for the first time.

Most of these tasks are performed during a user login session as a series of requests and replies from the pam_centrifydc module to Active Directory through the adclient process for those programs and applications that are configured to use PAM. Because PAM is the most common authentication service used by UNIX programs and applications, the pam_centrifydc module is the most commonly used for a typical log-on session. For a more detailed description of a typical log-on process, see What happens during the typical log-on process.

The order in which identity stores are listed in the nsswitch.conf file does not influence authentication. Authentication and authorization services are provided by Active Directory through the Server Suite Agent for *NIX and its PAM component, and by default, Active Directory is always tried before any other sources. The order in which sources are checked is controlled through the PAM configuration settings, for example, the lines defined in the pam.conf file. In general, you should not modify the PAM configuration because making changes to these settings can compromise security or produce unexpected and undesirable results.

How NSS Configuration Works with Server Suite

The Name Service Switch (NSS) provides a mechanism for identifying sources of network information a computer should use, such as local password and group files, NIS maps, NIS+ tables, LDAP, and DNS, and the order in which these sources should be consulted when looking up users, groups, host names, and other information.

When you join a domain, the NSS configuration file, nsswitch.conf, is automatically updated to use the Server Suite Agent’s NSS module first. Using the adclient process and the service library, the Server Suite NSS module accesses network information that’s stored in Active Directory through LDAP.

When a UNIX program or application needs to look up information, it checks the nsswitch.conf file and is directed to use the nss_centrifydc module. The nss_centrifydc module directs the request to Active Directory through the adclient process. The adclient process provides the information retrieved from Active Directory, then caches the information locally to ensure faster performance, reduce network traffic, and allow for disconnected operation.

The order in which identity stores are listed in the nsswitch.conf file does not influence authentication. Authentication and authorization services are provided by Active Directory through the Server Suite Agent and its PAM service, so Active Directory is always tried before any other sources, regardless of what you have specified in the nsswitch.conf file. Instead, the nsswitch.conf file determines the sources to use in responding to NSS queries such as getpwnam. In general, you should not modify this file because modifying the file can compromise security and complicate auditing activity. In addition, you should not specify ldap as a source in any nsswitch.conf file where you have installed the Server Suite Agent. Specifying ldap in the nsswitch.conf file can cause the system to crash.

How the Server Suite Agent Manages Kerberos Files

Kerberos is a network authentication protocol for client/server applications that uses encrypted tickets passed through a central Key Distribution Center to verify the identity of a user or service requesting access. Because Kerberos is an industry standard and a secure network authentication mechanism, you may already have UNIX programs and services that are configured to use it. To allow those existing Kerberized applications to work with Active Directory without manual configuration, the adclient process automatically creates and maintains the Kerberos configuration file, krb5.conf, and the krb5.keytab service ticket file to point Kerberos-enabled services and applications to the Key Distribution Center (KDC) in Active Directory when you join a domain.

The configuration file is initially created using information collected by probing DNS and Active Directory with the default domain set to the domain that the computer has joined. Whenever a logon or ticket validation is performed with a domain that is not in the configuration file, the configuration file is updated so that it includes the new domain. Although the adclient process can automatically update the file as needed, it does not destroy existing configuration entries that you may have added by hand. Because of this, Server Suite Agents work seamlessly with existing Kerberos-enabled applications.

The Authentication Service supports users defined in a Kerberos realm as long as the Kerberos domains or realms are resolvable by DNS. Kerberos realm names are case sensitive, so be careful to check that the realm spelling and capitalization is correct. (Ref: CS-21846a )

What Happens During the Typical Log-on Process

The core Server Suite Agent for *NIX components work together to identify and authenticate the user any time a user logs on to a computer using any UNIX command that requires the user to enter credentials. The following steps summarize the interaction to help you understand the process for a typical log on request. The process is similar, though not identical, for UNIX commands that need to get information about the current user or group.

The following steps focus on the operation of the agent rather than the interaction between the agent and Active Directory. In addition, these steps are intended to provide a general understanding of the operations performed through the agent and do not provide a detailed analysis of a typical log on session.

When a user starts the UNIX computer, the following takes place:

  1. A login process starts and prompts the user to supply a user name.
  2. The user responds by entering a valid local or Active Directory user name.
  3. The login process, which is a PAM-enabled program, then reads the PAM configuration file, /etc/pam.conf, and determines that it should use the Server Suite PAM service, pam_centrifydc, for identification.
  4. The login process passes the login request and the user name to the Server Suite PAM service for processing.

  5. The pam_centrifydc service checks the pam.allow.override parameter in the agent configuration file to see if the user name entered is an account that should be authenticated locally.

    • If the user should be authenticated locally, the pam_centrifydc service passes the login request to the next PAM module specified in the PAM configuration file, for example, to the local configuration file /etc/passwd.
    • If the user is not listed as an override account, the pam_centrifydc service continues with the login request and checks to see if the adclient process is running, then passes the login request and user name to adclient.

  6. The adclient process connects to Active Directory and queries the Active Directory domain controller to determine whether the user name included in the request is a user who has access to computers in the current computer’s zone.

    • If the adclient process is unable to connect to Active Directory, it queries the local cache to determine whether the user name has been successfully authenticated before.
    • If the user account does not have access to computers in the current zone or can’t be found in Active Directory or the local cache, the adclient process checks the Server Suite Agent configuration file to see if the user name is mapped to a different Active Directory user account with the adclient.mapuser.username parameter.
    • If the user name is mapped to another Active Directory account in the configuration file, the adclient process queries the Active Directory domain controller or local cache to determine whether the mapped user name has access to computers in the current computer’s zone.
  7. If the user has a UNIX profile for the current zone, the adclient process receives the zone-specific information for the user, such as the user’s UID, the user’s local UNIX name, the user’s global Active Directory user name, the groups of which the user is a member, the user’s home directory, and the user’s default shell.
  8. The adclient process checks for NSS override settings (nss.group.override and nss.user.override) to determine whether there are any changes to the user profile or additional restrictions that should override the profile retrieved or prevent the user from logging on.

  9. The adclient process queries through the nss_centrifydc service to determine whether there’s another user currently logged in with same UID.

    • If there is a potential conflict between local user account and the UNIX profile for an Active Directory account, the adclient process notifies the pam_centrifydc service of the potential conflict.
    • The pam_centrifydc service checks the Server Suite Agent configuration file to determine to issue a warning, ignore the conflict, or prevent the user from logging on.
    • If the login continues, the pam_centrifydc service asks the login process for a password.
  10. The login process prompts the user to provide a password and returns the password entered to the pam_centrifydc service.
  11. The pam_centrifydc service checks the pam.allow.users and pam.deny.users parameters in the agent configuration file to see if any user filtering has been specified to allow or deny access to specific user accounts. If any user filtering has been specified, the current user is either allowed to continue with the login process or denied access.
  12. The pam_centrifydc service checks the pam.allow.groups and pam.deny.groups parameters in the agent configuration file to see if any group filtering has been specified to allow or deny access to members of specific groups. If any group filtering has been specified, the current user is either allowed to continue with the login process or denied access based on group membership.
  13. If the current user account is not prevented from logging on by user or group filtering, the pam_centrifydc service queries the adclient process to see if the user is authorized to log on.
  14. The adclient process queries the Active Directory domain controller through Kerberos to determine whether the user is authorized to log on to the current computer at the current time.
  15. The adclient process receives the results of its authorization request from Active Directory and passes the reply to the pam_centrifydc service.

  16. The pam_centrifydc service does one of the following depending on the content of the authorization reply:

    • If the user is not authorized to use the current computer or to log in at the current time, the pam_centrifydc service denies the user’s request to log on through the UNIX login process.
    • If the user’s password has expired, the pam_centrifydc service sends a request through the UNIX login process asking the user to change the password. After the user supplies the password, the login process completes successfully.
    • If the user’s password is about to expire, the pam_centrifydc service notifies the user of impending expiration through the login process.
    • If the user is authorized to log on and has a current password, the login process completes successfully. If this is the first time the user has logged on to the computer through the agent, the pam_centrifydc service creates a new home directory on the computer in the location specified in the agent configuration file by the parameter pam.homeskel.dir.

The following figure provides a simplified view of a typical log-on process when using the Server Suite Agent for *NIX.

agent log on process for Unix and Linux

How Failover and Disconnected Access Work

The Server Suite Agent caches data from Active Directory so that users can log on and perform tasks even if the network or Active Directory server is unavailable, whether because of unexpected connectivity problems, scheduled maintenance, or offline operation of a portable computer. There are several configuration parameters that manage how the agent determines its connectivity to Active Directory, the domain controllers it should attempt to connect to, and the operation of the agent if it is unable to connect to any domain controller.

In most cases, you can set the values for the configuration parameters that control failover and disconnected operation by enabling Server Suite group policies for a site, domain, or organizational unit. Alternatively, you can set these parameters by editing the /etc/centrifydc/centrifydc.conf configuration file on individual computers.

For an overview of how the agent determines the connection status and locates a domain controller to use, see the following topics:

  • Establishing a connection to DNS
  • Connecting to the closest domain controller
  • Restricting the domain controllers contacted
  • Switching to disconnected mode
  • Responding to DNS configuration changes
  • Connecting to trusted forests and domains

Establishing a Connection to DNS

With each request to Active Directory, the Server Suite Agent first determines its connection status based on upon the availability of a Domain Name Service domain controller. If a DNS request for a host name takes longer than the number of seconds specified by the adclient.dns.response.maxtime parameter, the agent assumes DNS is down and switches to disconnected mode.

While running in the disconnected mode, the agent does not attempt any more synchronous network communications. Instead, it runs a background thread every 30 seconds to determine when DNS becomes available. The default value for the adclient.dns.response.maxtime is 10 seconds, but this value can be changed by group policy or by editing the /etc/centrifydc/centrifydc.conf file.

If the network is disconnected for a short period of time, but during that time no data is needed from Active Directory, the agent does not switch into disconnected mode. The status only changes if a connection attempt to DNS or to Active Directory through LDAP fails.

Connecting to the Closest Domain Controller

If the initial DNS request for a host name is successful, the Server Suite Agent attempts to connect to the appropriate domain controller and global catalog for its joined domain using the site information found in DNS.

Site information is configured using Active Directory Sites and Services and is defined by subnet. Using the site information, the agent queries DNS for a list of the domain controllers in its site and attempts to connect to the nearest domain controller. It will continue trying to connect to each of the domain controllers in its site based on proximity until it finds a server available. If the agent is unable to connect to any of the domain controllers in its site or if no site information is available, the agent tries to connect to any remaining domain controllers listed in DNS.

Because connection status is determined by an attempt to bind to the Active Directory domain controller using an LDAP call, the adclient.ldap.socket.timeout parameter determines the maximum number of seconds the Server Suite Agent will wait for a socket connection timeout while binding to the LDAP server. The default value is 5 seconds.

Restricting the Domain Controllers Contacted

If you have a large Active Directory infrastructure or some unreliable subnets, you might want to restrict the domain controllers the agent should attempt to connect to if its primary domain controller becomes unavailable. You can limit the list of domain controllers the agent should attempt to connect to by setting the following property in the centrifydc.conf file:

dns.dc.domain_name: hostname [hostname] ...

where the domain_name is the Active Directory domain name and the hostname is a fully-qualified host name that can be resolved using DNS or the /etc/hosts file.

You can also limit the list of global catalog domain controllers the agent should attempt to connect to by setting the following property in the centrifydc.conf file:

dns.dc.forest_name: hostname [hostname] ...

where the forest_name is the forest root domain and the hostname is a fully-qualified host name that can be resolved using DNS or the /etc/hosts file.

Alternatively, you can use the adclient.server.try.max parameter or Maximum Server Connection Attempts group policy to limit the number of domain controllers the agent will attempt to connect to before switching to disconnected mode, eliminating the need to explicitly list the domain controllers using the dns.dc.domain_name and dns.gc.forest_name parameters. For example, to have the agent try a maximum of three domain controllers, you can set the following property in the centrifydc.conf file:

adclient.server.try.max: 3

Because global catalog and domain controller connections are handled independently, Server Suite Agent for *NIX can still provide authentication services if the global catalog domain controller is disconnected, as long as another domain controller is available.

Switching to Disconnected Mode

After a connection to a domain controller is established, each subsequent request for information from Active Directory checks the connection status. If a request is made to Active Directory and a response is not received within the number of seconds specified by the adclient.ldap.timeout parameter, that request is retried once. For the second request, the agent will wait up to twice as long for a response. If the second request is not answered within that amount of time, the connection to that specific domain controller is considered disconnected. Once a connection to a specific domain controller is in disconnected mode, a background thread will attempt to reconnect to that domain approximately every 30 seconds. By default, the agent waits 7 seconds for a response to the first request. If the request isn’t answered, it retries the request and waits up to another 14 seconds for a response before switching to disconnected mode.

The adclient.ldap.timeout parameter specifies the maximum number of seconds to wait for Active Directory fetch, update, and delete requests to improve the response time when an initial connection attempt fails. A separate parameter, adclient.ldap.timeout.search, specifies the maximum time to wait for search requests. If the search timeout value is not specified, the default is double the adclient.ldap.timeout value. By default, therefore, the agent waits a maximum of 14 seconds for search requests.

The values for these parameters can be adjusted for high load or latency networks by configuring group policies or by editing the /etc/centrifydc/centrifydc.conf file.

Responding to DNS Configuration Changes

The DNS information collected when the agent starts and connects to a domain controller is not cached, and idle connections to Active Directory are dropped after 5 minutes by default. If you make changes in the DNS configuration, those changes are detected the next time the agent needs to reconnect, either because an idle connection has been dropped, or the currently connected domain controller suddenly becoming unavailable.

Connecting to Trusted Forests and Domains

If the Server Suite Agent establishes a successful connection to the joined domain, it also generates or updates the /etc/krb5.conf file using the domain trust information from the global catalog, and attempts to connect to the trusted domains or to external forests to find all of the domains that are trusted.

Depending on the trust relationships you have defined, network topology, or firewall requirements, querying external trusted forests can have a significant, negative impact on network performance. You can control whether trusted domains and external forests are queried to establish transitive trusts and cross-forest authentication with the adclient.ldap.trust.enabled parameter. Setting the adclient.ldap.trust.enabled parameter to true indicates that you want the Server Suite Agent to query trusted domains and forests. Setting this parameter to false disables this feature so that the agent does not connect to any external forests or trusted domains.

If you set the adclient.ldap.trust.enabled parameter to true, you can control the maximum number of seconds to wait when searching for trust information in external forests and other trusted domains with the adclient.ldap.trust.timeout parameter. By default, the agent waits 10 seconds. The search operation is not retried if the request times out, but the request is regenerated approximately once an hour.

If your trusted domains and forests are widely distributed, have slow or unreliable network connections, or are protected by firewalls, you might want to increase the value for this parameter to allow time for the Server Suite Agent to collect information from external domains and forests.