ユーザー管理の制限と推奨事項

LDAP ディレクトリのユーザーとグループの最適数

The connection to your LDAP directory provides powerful and flexible support for connecting to, configuring and managing LDAP directory servers. To achieve optimal performance, a background synchronisation task loads the required users and groups from the LDAP server into the application's database, and periodically fetches updates from the LDAP server to keep the data in step. The amount of time needed to copy the users and groups rises with the number of users, groups, and group memberships. For that reason, we recommended a maximum number of users and groups as described below.

この推奨事項は以下の LDAP ディレクトリへの接続に影響します。

• Microsoft Active Directory
• その他のすべての LDAP ディレクトリサーバー

次の LDAP 設定は影響を受けません。

• LDAP 認証を使用した内部ディレクトリ
• 「認証専用、最初のログイン時にユーザーをコピー」に設定された LDAP ディレクトリ

LDAP ディレクトリのユーザー、グループおよびメンバーシップの数に応じて次のソリューションのいずれかを選択してください。

弊社のテスト結果

We performed internal testing of synchronisation with an AD server on our local network consisting of 10 000 users, 1000 groups and 200 000 memberships.

We found that the initial synchronisation took about 5 minutes. Subsequent synchronisations with 100 modifications on the AD server took a couple of seconds to complete.

Please keep in mind that a number of factors come into play when trying to tune the performance of the synchronisation process, including:

• ユーザーベースの規模。 LDAP フィルターを使用して、これをお客様の要件に適合する最小規模に維持します。
• Type of LDAP server. We currently support change detection in AD, so subsequent synchronisations are much faster for AD than for other LDAP servers.
• ネットワークトポロジー。 LDAP サーバーと、ご使用のアプリケーションサーバー間の距離が離れるほど、潜在的な LDAP クエリが増加します。
• Database performance. As the synchronisation process caches data in the database, the performance of your database will affect the performance of the synchronisation.
• JVM heap size. If your heap size is too small for your userbase, you may experience heavy garbage collection during the synchronisation process which could in turn slow down the synchronisation.

冗長 LDAP には非対応

LDAP 接続では、冗長性のための複数の LDAPサーバーの構成 (一方のサーバーが停止した場合の自動フェイルオーバー) はサポートされていません。

Active Directory に接続するための具体的な注意事項

When the application synchronises with Active Directory (AD), the synchronisation task requests only the changes from the LDAP server rather than the entire user base. This optimises the synchronisation process and gives much faster performance on the second and subsequent requests.

On the other hand, this synchronisation method results in a few limitations:

1. Externally moving objects out of scope or renaming objects causes problems in AD. If you move objects out of scope in AD, 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 the application's directory configuration screen. If you do need to make structural changes to your LDAP directory, manually synchronise the directory cache after you have made the changes to ensure cache consistency.
2. Synchronising between AD servers is not supported. Microsoft Active Directory does not replicate the uSNChanged attribute across instances. For that reason, we do not support connecting to different AD servers for synchronisation. (You can of course define multiple different directories, each pointing to its own respective AD server.)
3. Synchronising with AD servers behind a load balancer is not supported. As with synchronising between two different AD servers, Microsoft Active Directory does not replicate the uSNChanged attribute across instances. For that reason, we do not support connecting to different AD servers even when they are load balanced. You will need to select one server (preferably one that is local) to synchronise with instead of using the load balancer.
4. バックアップから AD を復元した後、アプリケーションの再起動が日著うです。バックアップから AD サーバーを復元すると、uSNChanged タイムスタンプはバックアップ時刻に戻ります。混乱を避けるために、Active Directory の復元操作の後はディレクトリキャッシュを消去します。
5. 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 the synchronisation task to be aware of deletions, you must use administrator credentials. Alternatively, it is possible to change the permissions on the cn=Deleted Objects container. If you wish to do so, please see this Microsoft KB Article.
6. The User DN used to connect to AD must be able to see the uSNChanged attribute. The synchronisation task relies on the uSNChanged attribute to detect changes, and so must be in the appropriate AD security groups to see this attribute for all LDAP objects in the subtree.

複数のアプリケーションへのシングルサインオンはサポートされません

When you connect to JIRA for user management, you will not have single sign-on across the applications connected in this way. JIRA, when acting as a directory manager, does not support SSO.

カスタムアプリケーションコネクタはサポートされません

JIRA, Confluence, FishEye, Crucible and Bamboo can connect to a JIRA server for user management. Custom application connectors will need to use the new REST API.

カスタムディレクトリはサポートされません

JIRA の過去のバージョンでは OSUser Providers をサポートしていました。そのため、外部のユーザー ディレクトリからユーザー情報を取得するために特殊なプロバイダを記述することが可能でした。現在はサポートしていません。

Optimal Number of Users and Applications

Please consider the following limitations when connecting to a JIRA server for user management:

• Maximum 500 users.
• Maximum 5 connected applications.

推奨事項