Crowd manages a cache of LDAP directory information stored in the Crowd database, to ensure fast recurrent access to user and group data. We call this 'database-backed LDAP caching'.

This page describes the caching of user and group information in the Crowd database. For a description of the other types of caching offered by Crowd, please refer to Overview of Caching.

On this page:

Features of LDAP Caching in Crowd

For all LDAP directories with caching enabled, Crowd will keep an up-to-date cache of user and group information retrieved from the LDAP directory. Use of the cache should improve performance particularly in directories which are slow or off site.

Please refer to the notes below, especially regarding the number of users for which the caching is optimized.

Summary of the caching functionality:

• The caches are held in the Crowd database.
• When you add the directory connector to Crowd, Crowd will start a synchronization task in the background to copy all the required users, groups and membership information from LDAP to the Crowd database. This task may take a while to complete, depending on the size and complexity of your user base.
• Crowd will perform a periodic synchronization to update the database with any changes made to LDAP. The default sync interval, or polling interval, is one hour (60 minutes). You can change the polling interval on the directory connector configuration screen.
• You can manually synchronize the database-backed cache if necessary.
• Whenever an update is made to the users, groups or membership information via Crowd, Crowd will update both the database-backed cache and the LDAP directory immediately.
• For all authentication requests, Crowd performs calls to the LDAP directory itself. The Crowd database-backed cache does not store user passwords.
• Crowd performs all other queries against the database-backed cache.

The diagram below gives a conceptual overview of the caches supported by Crowd, including the LDAP database-backed caching discussed on this page. For a description of the other types of caching offered by Crowd, please refer to the overview of caching.

Supported LDAP Directories

Crowd's database-backed caching is available for all the LDAP directories that Crowd supports. See Configuring an LDAP Directory Connector for the list of supported directories.

Configuring the Cache

1. In the top navigation, click Directories. 
2. Click on the directory for which you want to configure cache. 
3. In the Details tab, select Cache Enabled. 
4. In the Connector tab, set the polling interval option
   The polling interval is the period of time, in minutes, that Crowd will wait between its requests for updates from LDAP.

• • The length of your polling interval depends on the length of time you can tolerate stale data, the amount of load you want to put on Crowd and the LDAP server, and the size of your user base. If you poll more frequently, then your data will be more up to date. The downside of polling more frequently is that you may overload your LDAP server with requests.
  • If in doubt, we recommend that you start with an interval of 60 minutes (this is the default setting) and reduce the value incrementally. You will need to experiment with your setup.

Finding the time taken to synchronize

You can find the time take to synchronize on the Details tab of your directory. 

The directory connector's 'Details' tab shows information about the last sync operation, including the length of time it took.

キャッシュを手動で同期する

Screenshot: Manually syncing the cache

You can manually synchronize the cache by clicking the Synchronize Now button on the the directory connector's Details tab. If a sync operation is already in progress, you cannot start another until the first has finished.

注意

General Notes

1. Be aware of the optimal number of users. We have optimized the database caching for directories containing approximately 10 000 (ten thousand) users. If your directory is significantly larger, the new caching may not be as beneficial. For really large user bases, we recommend that you leave the caching disabled.
2. You can reduce the number of LDAP users visible to Crowd. You can narrow the LDAP user/group filter to control the size of the userbase visible to Crowd.
3. Delegated Authentication directories are not cached. Delegated Authentication directories are not cached, because only the authentication is delegated to the directory, and authentication itself is not cached.
4. Synchronization errors are shown in the logs. If there are any errors during the synchronization process, they will appear in the logs (not the UI). If one user fails to sync for some reason, the process will write the error to the logs, skip that user and continue with the remaining users.

Additional Notes for Active Directory

When Crowd synchronizes with Active Directory, Crowd requests only the changes from the LDAP server rather than the entire user base. This optimizes the synchronization process and gives much faster performance on the second and subsequent requests.

一方、この同期方式にはいくつかの制限事項があります。

1. Externally moving objects out of scope or renaming objects causes problems in AD. If you move objects out of scope, this will result in an inconsistent cache. We recommend that you do not use the external LDAP directory interface to move objects out of the scope of the sub-tree, as defined on Crowd's Directory Connector screen. If you do need to make structural changes to your LDAP directory, manually synchronize the directory cache after you have made the changes to ensure cache consistency.
2. Syncing between AD servers is not supported. Microsoft Active Directory does not replicate the uSNChanged attribute across instances. For that reason, Crowd does not support connecting a single directory to different AD servers for syncing.
3. You must restart Crowd after restoring AD from backup. On restoring from backup of an AD server, the uSNChanged timestamps are reverted to the backup time. To avoid the resulting confusion, you will need to flush the directory cache after a Active Directory restore operation.
4. Obtaining AD object deletions requires administrator access. Active Directory stores deleted objects in a special container called cn=Deleted Objects. By default, to access this container you need to connect as an administrator and so, for Crowd to be aware of deletions, you must use administrator credentials. Alternatively, it's possible to change the permissions on the cn=Deleted Objects container. If you wish to do so, please see this Microsoft KB Article.

弊社のテスト結果

10 000 ユーザー、1000 グループおよび200 000 メンバーシップで構成される弊社のローカルネットワーク上で AD サーバーとの同期について社内でテストを実施しました。

最初の同期には約 5 分かかりました。その後の、AD サーバー上の 100 個の変更との同期は、数秒で完了しました。

同期処理のパフォーマンスの調整を試みる場合、以下のような多数の要因が関与することを銘記してください。

• ユーザーベースの規模。 LDAP フィルターを使用して、これをお客様の要件に適合する最小規模に維持します。
• LDAP サーバーのタイプ。 現在、AD の変更検出をサポートしているため、後続の AD との同期は、他の LDAP サーバーとの同期よりもかなり高速です。
• ネットワークトポロジー。 LDAP サーバーと、ご使用のアプリケーションサーバー間の距離が離れるほど、潜在的な LDAP クエリが増加します。
• データベース パフォーマンス。 同期処理では、データベース内のデータをキャッシュするため、データベースのパフォーマンスが同期パフォーマンスに影響を与えます。
• JVM ヒープサイズ。 ユーザーベースに対してヒープサイズが小さすぎると、同期処理中にガーベッジコレクションが重くなる場合があり、それによって同期速度が遅くなる可能性があります。