Product Documentation

Central Store Types

May 09, 2015

Single Sign-on uses a repository known as the central store to store and retrieve information about your users and your environment. Single Sign-on relies on the data in the central store to perform all default and configured Single Sign-on functions. You can create a central store automatically as part of the Single Sign-on installation process or manually by using the central store setup utilities.

The central store contains user data and administrative data:
  • User data in the central store includes user secondary credentials, security questions and answers, service-related data (for example, provisioned data, question-based authentication data, key recovery enrollment, and so on), and user Windows registry data associated with Single Sign-on.
  • Administrative data in the central store includes application definitions, password policies, security questions, and other settings made through the console for Single Sign-on features and components.

The central store basically enables the plug-in software running on a user computer or computer running Citrix XenApp to communicate with the central store and services, and to provide user credentials to applications to which the user is granted access.

The plug-in software maintains a local store on the user computer. The local store contains only the user’s secondary credentials, key recovery information, and security questions and answers (if applicable). It synchronizes with the central store to allow users to roam throughout the enterprise and always have access to saved user credentials.

The central store can be one of the following types:
  • Active Directory

    The central store uses the Active Directory environment and objects to store and update Single Sign-on data.

  • NTFS network share

    The central store uses a Windows network file share to store the Single Sign-on data.

If necessary, you can migrate users from one central store type to another.

Choosing an Active Directory Central Store

Choosing to use Active Directory as your central store enables you to leverage the convenience of your existing Active Directory user authentication and object administration. For example, you can apply user-specific settings to any level in a domain—domain, organizational unit, group, or user.

Two new classes and two attributes are added to the Active Directory schema when you create an Active Directory central store:

Class Description
citrix-SSOConfig Describes the object containing data for the plug-in software settings, synchronization state, and the application definitions and the first-time plug-in software use behavior.This class includes the following attributes: citrix-SSOConfigData - contains the actual data and citrix-SSOConfigType - specifies the data type
citrix-SSOSecret Describes the secret data object used to authenticate a Single Sign-on user. This class includes the following attribute: citrix-SSOSecretData - contains encrypted credential data for an application and Account Self-Service password reset data
Note: See the CitrixMPMSchema.xml file in the \Tools folder on the installation media for more information about these classes and attributes.
In general, choose Active Directory as your central store if you:
  • Can successfully extend your Active Directory schema without affecting your enterprise
  • Already implement best practices for Active Directory backup and restore as recommended by Microsoft (although this is not a requirement)
  • Prefer the high availability that is built in to Active Directory to be extended to the central store data

Advantages of an Active Directory Central Store

The following are advantages of using an Active Directory central store:

  • Active Directory includes built-in failover and redundancy, so additional measures for disaster recovery are not needed
  • Active Directory replication helps to distribute central store administrative and user data across your enterprise
  • No additional hardware is needed when using an Active Directory central store

Active Directory Central Store Considerations

Consider the following before using an Active Directory central store:

  • You must extend your schema when using an Active Directory central store, which requires careful planning and implementation. Extending the schema affects the entire forest.
  • You might want to extend the schema and create your Active Directory central store during non-peak usage hours. Your Active Directory replication cycle latency affects how quickly these changes are copied to all domain controllers in the forest.
  • Inter-site replication of central store data across large enterprises using WANs requires you to configure replication correctly to reduce latency. (However, intra-site replication typically introduces less latency.)

Choosing an NTFS Network Share

Choosing to use an NTFS network share as your central store enables you to leverage the convenience of your existing Active Directory user authentication and tree structure without having to extend the Active Directory schema. For example, you can apply user-specific settings to any level in a domain—domain, organizational unit, group, or user.

Important: Use a hidden share for the central store in this case.

Single Sign-on creates a shared folder named CITRIXSYNC$ with two subfolders named People and CentralStoreRoot.

The People folder contains a subfolder for each user and includes the appropriate read and write permission properties for the user. The CentralStoreRoot folder contains administrative data.

Advantages of an NTFS Network Share

The following are advantages of using an NTFS network share:

  • You can emulate the look and feel of an Active Directory central store without having to extend your Active Directory schema. Yet you can take advantage of your existing Active Directory hierarchy or groups.
    Note: Associating user configurations to groups is supported only in Active Directory domains that use Active Directory authentication.
  • User data is always up-to-date, because it is stored in a central location and avoids any data replication latency associated with Active Directory.
  • You can load balance your shares among multiple computers that can each host an NTFS network share for higher availability.
  • NTFS network share helps reduce the authentication task workload from your Active Directory environment.
  • Single Sign-on enables you to migrate your NTFS shared folder central store to an Active Directory central store if you decide later to implement an Active Directory central store.

NTFS Network Share Considerations

Consider the following before using an NTFS network share:
  • You might need additional hardware to host the central store.
  • You need to back up central store files and folders (including their related permissions) regularly. Ensure that you also maintain and implement disaster recovery plans where you replicate files and folders for site recovery.
  • Your enterprise network topology might require users (and the Single Sign-on Plug-in software) to transfer user data across one or more WAN links. In this case, consider implementing the Distributed File System technology included as part of Microsoft Windows Server 2003 and 2008. The Microsoft Web site http://support.microsoft.com describes the Distributed File System technology in detail.

Using Account Association with Multiple Central Stores and User Account Credentials in a Multiple Domain Enterprise

Administrators can create multiple central stores in enterprises that contain multiple domains. In fact, you can use more than one type of central store in these environments. For example, you can associate user configurations with an NTFS network share central store in one domain and an Active Directory central store in another domain.

Because companies might maintain multiple Windows domains, users might also have more than one Windows account. Single Sign-on includes a feature known as Account Association to allow a user to log on to any application from one or more Windows accounts. Because Single Sign-on typically binds user credentials to a single account, the credential information is not synchronized automatically among multiple accounts that a user owns.

However, administrators can configure Account Association to synchronize user credentials by using the Credential Synchronization Module. Users with Account Association configured have access to all applications from any of their accounts in their Single Sign-on environment. When user credentials are changed, added, or removed from one account, the credentials are synchronized automatically with each of the user’s associated accounts.

Without Account Association, users with multiple Windows accounts are forced to manually change their logon information separately from each Windows account.

To allow users to synchronize credentials by using Account Association, give them access to AccAssoc.exe as a published application.

Advantages of Using Account Association

  • Account Association can help increase productivity and reduce support calls by synchronizing user credentials to help reduce logon maintenance or failures.
  • Accounts can be synchronized across different central store types. That is, a user account configured to use Active Directory as the central store can synchronize with an associated user account that is configured to use an NTFS network share.
  • Accounts can also be synchronized across different user configuration associations. For example, a user configuration can be associated with an Active Directory hierarchy (OU or user) in one domain and associated with an Active Directory group in another domain.
  • Accounts can also be synchronized across different user configuration associations in the same domain and within the same central store.
  • Trust relationships between domain controllers are not necessary to use Account Association.
Consider the following before configuring Account Association:
  • Account Association is not compatible with smart cards when smart cards are used as the primary authentication mechanism to log on to Windows.
    Note: The user configuration in each domain might have different password policies that might block access to a resource, but Account Association synchronizes user credentials only, not user configuration policies. Consider how you compose password policies in your enterprise.
  • Each associated domain account must use Single Sign-on.
  • Application definition names must be the same in each user configuration for the Account Association feature to synchronize credentials.
  • User credentials are shared only for applications specified in application definitions created by the Single Sign-on administrator.
  • As part of the Single Sign-on Service, the Credential Synchronization Module is a Web service available through a secure HTTP connection, so this module must be accessible from all computers in your enterprise using Account Association.