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

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

このページでは、Jira のユーザー管理に適用する最適な設定と制限事項について説明します。

On this page:

一般的な推奨事項

  • ディレクトリ間で重複するユーザー名を使用しないようにします。複数のユーザーディレクトリに接続している場合、1つのディレクトリに対してユーザー名が一意であることを確認するようにしてください。たとえば、ユーザー名 jsmith を "ディレクトリ1" と "ディレクトリ2" の両方に使用することはお勧めしません。これは、特にディレクトリの順序を入れ替える際に混乱を招く恐れがあるためです。ディレクトリの順序の変更により、指定したユーザー名で参照するユーザーが変わる可能性があります。
  • リモート ディレクトリでユーザーを削除するときは注意してください。LDAP ディレクトリ、Crowd ディレクトリ、リモート Jira ディレクトリに接続している場合、リモート ディレクトリからユーザーを削除するときは注意してください。Jira のデータに関連付けられているユーザーを削除する場合、Jira 内で問題が発生することがあります。ユーザーに関連付けられた、またはユーザーによって報告された課題やプロジェクト リーダーのユーザーが存在する場合、Jira の UI はユーザーの削除を防止するため、Jira 内ですべてのユーザを管理することをお勧めします。
アトラシアン製品全体で 500 人以上のユーザーを管理していますか?
Crowd を使用することで、スケーラブルかつ効果的な方法でユーザーを簡単に管理できます。
 ユーザーの一元管理」を参照してください。


LDAP への接続に関する推奨事項

LDAP ユーザー ディレクトリに接続する場合、以下の制限事項と推奨事項を検討してください。

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

ご使用の LDAP ディレクトリへ接続することで、 LDAP ディレクトリサーバーへの接続、設定、および管理に関して強力で柔軟なサポートが得られます。最適なパフォーマンスを実現するために、バックグラウンドの同期タスクは必要なユーザーとグループを LDAP サーバーからアプリケーションのデータベースにロードし、LDAP サーバーから定期的に更新情報を取り出してデータの同期を維持します。ユーザーとグループのコピーに必要な時間は、ユーザー、グループ、およびグループのメンバーシップの数に伴って増加します。このため、以下の説明では、ユーザーとグループの最大数を推奨しています。

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

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

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

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

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

お客様の環境

推奨事項

最大 10 000 ユーザー、1000 グループ、およびユーザーあたり 20 グループ

LDAP」または「Microsoft Active Directory」のディレクトリ タイプを選択します。完全同期オプションを利用することができます。アプリケーションのデータベースはご利用の LDAP サーバのユーザとグループをすべて格納しています。

上記を超える場合

LDAP フィルターを使用して同期タスクに表示されるユーザーおよびグループの数を減らします。

弊社のテスト結果

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

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

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

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

冗長 LDAP には非対応

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

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

アプリケーションを Active Directory (AD) に同期している場合、同期タスクではユーザーベース全体ではなく LDAP サーバーからの変更のみがリクエストされます。これによって同期プロセスが最適化され、2番目以降のリクエストでパフィーマンスが大幅に向上します。

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

  1. オブジェクトを範囲外に移動したり、名前の変更を行ったりすると、AD で問題が発生します。AD の範囲外にオブジェクトをいどう すると、キャッシュの整合性が失われます。アプリケーションのディレクトリ設定画面で定義されているように、オブジェクトをサブツリーの範囲外に移動するために外部 LDAP インターフェイスを使用しないことをお勧めします。LDAP ディレクトリ構造を変更する必要がある場合は、変更を行った途にディレクトリキャッシュを手動で同期し、キャッシュの整合性を確保してください。
  2. AD サーバー間での同期はサポートされていません。Microsoft Active Directory では、インスタンス間で uSNChanged 属性が複製されません。そのため、同期のための異なる AD サーバーの接続はサポートしていません (もちろん、それぞれが異なる AD サーバーを参照する複数の異なるディレクトリを定義することは可能です)。
  3. バックアップから AD を復元した後、アプリケーションの再起動が日著うです。バックアップから AD サーバーを復元すると、uSNChanged タイムスタンプはバックアップ時刻に戻ります。混乱を避けるために、Active Directory の復元操作の後はディレクトリキャッシュを消去します。
  4. AD オブジェクトの削除を取得するには、管理者アクセスが必要です。Active Directory では、cn=Deleted Objects という特別なコンテナに削除済みオブジェクトが格納されます。既定では、このコンテナにアクセスするには管理者として接続している必要があります。したがって同期タスクで削除を認識するには、管理者の認証情報を使用する必要があります。または、cn=Deleted Objects コンテナでの権限を変更することも可能です。その場合、この Microsoft KB 記事を参照してください。
  5. AD との接続に使用されるユーザー DN はuSNChanged 属性を参照できる必要があります。 同期タスクは変更を検知するのに uSNChanged 属性を使用しているため、サブツリーのすべての LDAP について、この属性を参照するために適切な AD セキュリティ グループに属する必要があります。

別の Jira サーバーに接続する場合の注意事項

ユーザー管理のために JIRA サーバーに接続する場合は、次の制限事項と推奨事項を検討してください。

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

ユーザー管理のために JIRA アプリケーションに接続する場合、この方法で接続されているアプリケーションにはシングルサインオンできません。JIRA がディレクトリマネージャとして機能する場合、SSO はサポートされません。

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

ユーザー管理のため、JIRA アプリケーション、Confluence、FishEye、Crucible、Bamboo を JIRA サーバーに接続できます。カスタムアプリケーションコネクタで新しい REST API を使用する必要があります。

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

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

JIRA インスタンスの負荷

JIRA インスタンスにすでに高い負荷がかかっている場合、ユーザーサーバーを使用すると負荷がさらに高まります。

JIRA Cloud アプリケーションはサポートされません

Jira Cloud アプリを使用してスタンドアロン ユーザーを管理することはできません。Cloud ユーザーの管理とセルフホスト型のアトラシアン アプリのユーザーの管理は、個別に行う必要があります。

推奨事項

お客様の環境

推奨事項

次のすべてに当てはまる場合:

  • JIRA アプリケーションに高い負荷がかかっていない。
  • 1台の JIRA Software サーバー、1台の Confluence サーバー、2台の JIRA サーバーなど、少数のアプリケーションでユーザーおよびグループ管理を共有する。
  • JIRA アプリケーションと Confluence 間、または2つの JIRA サーバー間でシングル サインオン(SSO)は必要ありません。
  • カスタム アプリケーション コネクタはありません。または、カスタム アプリケーション コネクタ がない場合、新しい REST API を使用するように変換します。
  • JIRA アプリケーションをアップグレードする必要がある場合は、すべてのサーバーをシャットダウンしても問題ない。

ご利用の環境はユーザー管理に JIRA アプリケーションを使用するための最適要件を満たしています。

次の項目の1つ以上に当てはまる場合:

  • JIRA アプリケーションにすでに高い負荷がかかっている。
  • 5個を超えるアプリケーションでユーザーおよびグループ管理を共有する。
  • 複数のアプリケーションでシングルサインオン (SSO) が必要である。
  • Crowd SOAP API を介してカスタムアプリケーションを統合しており、新しい REST API を使用するように変換することができない。
  • JIRA アプリケーションをアップグレードする必要がある場合、すべてのサーバーをシャットダウンすることは避けたい。

ユーザー管理および SSO のために Atlassian Crowd をインストールすることをお勧めします。

ユーザーおよびグループの独自のストレージを定義するために、カスタムディレクトリコネクタの作成を検討している場合...

次のソリューションが役立つかどうかを検討してください。

  • 特定の LDAP スキーマをサポートするカスタムプロバイダを作成した場合、サポートされている LDAP スキーマのいずれかを代わりに使用できるかどうかを確認してください。
  • 入れ子グループをサポートするカスタムプロバイダを作成した場合、代わりにサポートされているディレクトリコネクタで入れ子グループを有効化することを検討してください。
  • 独自のデータベースをサポートするカスタムプロバイダを作成した場合、代わりにアプリケーションのデータベースにデータを取り込むことを検討してください。
  • カスタム ディレクトリ接続を維持する必要がある場合、Atlassian Crowd が要件を満たしているか検討してください。「カスタム ディレクトリ コネクタの作成」のドキュメントを参照してください。

関連トピック

LDAP ディレクトリへの接続
ユーザー管理のための Crowd または別の Jira サーバーへの接続
ユーザーディレクトリの設定

最終更新日: 2019 年 1 月 14 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.