LDAP 経由で大規模ディレクトリと統合するためのベストプラクティス
What constitutes a large directory?
A large directory has more than 10000 users that will be present in Atlassian applications.
When should I use a Delegated Directory
This mode is also known as "Internal with LDAP authentication" in some versions of Atlassian applications. A delegated directory does not periodically synchronise users from your LDAP Server. When a user logs in for the first time, they are created in the directory (by obtaining information from the LDAP Server). During subsequent logins, user's details are synchronised from the LDAP server.
This means that a user doesn't exist in an application until they have logged in for the first time.
Delegated directories are useful when you don't know exactly which users and groups will be logging into an application, or you have an extremely large directory (more than 10000 users possibly logging in). They can also be configured to be independent of the directory - allowing you to modify memberships and groups locally.
Pros:
- Excellent performance, no large syncs to bog down the server
- Useful when the scope of users is difficult to define
Cons:
- Users do not exist in an application, until they log in
When should I use a Connector
A connector will connect to the LDAP server, and synchronise users and groups periodically. Depending on your requirements, an application can be configured to propagate local changes back to the directory; or to be read-only. Alternatively, a connector also offers a mode which is read only; but with local groups. This is ideal when you do not have the ability to write changes to the directory. The downside to this mode is that those groups will only exist within the Atlassian applications.
Performance in large directories can be a concern. Long running syncs can impact the application and the directory server's performance. For considerations in larger deployments, see the "Consideration for Large Deployments" section.
Pros:
- Excellent performance on small and medium directories
- Read only with local groups provides a good alternative for strictly controlled environments
- Synchronisation means users are known to an application before they log in
- Load balancing and replication can be used to eliminate a single point of failure
Cons:
- A connector can cause poor performance in very large directories
- Multiple connectors pointing to the same server can impact that LDAP server's performance
Comparison of the Delegated Directory and Connector types
Note that neither connector type is categorically better than the other. Each connector type has benefits and concerns that should be taken into account when planning your user management configuration.
| 項目 | Delegated Directory | Connector |
|---|---|---|
| Users must log in to an application to be visible |  |  |
| Modify user accounts independently of the directory |  |
|
Modify users' memberships independently of the directory | |  When using "Read Only with Local Groups" |
| Modify groups independently of the directory | | |
| Synchronise Users Periodically | | |
| Supports using locally defined groups | | When using "Read Only with Local Groups" |
| Authenticate Users against LDAP | | |
When should I use JIRA for centralised user management
JIRA is best used for centralised user management when the majority of your users work in JIRA, but not so much in other applications. Applications that aren't used as much can safely use JIRA for user management without the risk of overloading JIRA, and causing disruption to JIRA itself.
Using JIRA for user management does not provide the ability to utilise Single Sign On (SSO) between Atlassian Applications.
Pros:
- Easy to expand into other applications if JIRA is your first or primary application
- Excellent for small groups or rarely-used applications
- Good alternative to running an LDAP directory
- Configuring applications to use JIRA is straightforward
Cons:
- In larger deployments, JIRA may become overloaded due to extra traffic
- JIRA does not provide Single Sign On for Atlassian Applications
- Using JIRA for centralised user management introduces a single point of failure - if JIRA goes down, then other applications will be left without authentication.
参考資料
When should I use Crowd for centralised user management
Crowd is best used for user management in larger organisations where there are multiple applications, all with consistent usage. Crowd also provides Single Sign On between Atlassian Applications.
Each application that connects to Crowd will get only a list of users and groups - the implementation of directories is invisible to that application. This makes configuring new applications quite simple, as they just connect to Crowd and get the list of configured users and groups.
Pros:
- Single Sign On between Atlassian Applications
- Good alternative to running an LDAP directory
- Centralised user provisioning to all your applications
- Complex mappings of users, groups and directories are possible
- Configuring applications to use Crowd is straightforward
Cons:
- Additional licensing is required
- Additional server infrastructure is required
- Using Crowd for centralised user management introduces a single point of failure - if Crowd goes down, then other applications will be left without authentication
Considerations for Large Deployments
There are several primary considerations:
- Redundancy, and points of failure
- Complexity of configuration
- Performance of the LDAP Server
Points of Failure
When using Crowd or JIRA, that application will become a single point of failure. If that application must be restarted, then other applications will not be able to process logins. Using multiple direct connections avoids this risk, however the point of failure will then become the LDAP server. This can be reduced by making use of replication and load balancing, to ensure that a the LDAP server does not get overloaded in large environments.
Complexity of configuration
When using multiple direct connections to LDAP, each application must have the configuration defined manually. If more complex configuration is required, then the time to administer each application may increase. There may also be discrepancies in that configuration that may cause additional problems.
When should I turn on External User Management
External User Management disables your application's ability to make changes to users, groups and group memberships. If you have configured a read only directory in your application, you should enable External User Management to prevent changes to users, groups and memberships in the local application. You can also use this to prevent unauthorised (or undesired) changes by application administrators to users, groups and memberships.
Your application will still connect to external directories but you must make changes to users and groups in the external directory, rather than in your application.
This option is known as "Read-only External User Management" in Bamboo.
When should I disable or delete the Internal Directory?
Atlassian recommends never making changes to the internal directory. When an application is set up for the first time, a local administrative account is created - separate from any LDAP or external user management that is set up. In the event that external user management is inaccessible, this user account allows administrative access to the instance.
If the license used by the local administrative account is required for use by another user; consider disabling the admin user rather than deleting it (or deleting the internal directory).