Also known as "Internal Directory with LDAP Authentication". As the name implies, you can think of this type of directory as an Internal Directory, but when it comes to authenticating users, Jira will reach out to LDAP for the verification of the user's inputted credentials. Like an Internal Directory, an administrator can add/remove/update users locally via the Jira UI.

The directory type also offers some options to assist the admin:

• If the user does not exist, the directory can automatically create the user upon successful authentication
• Additional option to update this single user's information (email, display name, etc.) upon successful authentication
• Additional option to pull in the user's LDAP group memberships upon successful authentication (and automatically create any groups that do not yet exist in Jira)

The important thing to note is that all of these options are based on user authentication and on a per-user basis only. This means that users will not exist in Jira until an admin manually creates them, or if they are auto-created upon successful authentication (with the option to do so configured).

It also means that any users that are removed/disabled from the LDAP side will never be automatically removed/disabled in Jira, since the user cannot log in at that point to trigger changes to that account.

The main advantage of a Connector is that it proactively reaches out to LDAP to update user/group/membership information on a configurable time interval. This means that changes on the LDAP side, including adding/removing users, changing user details, changing group memberships, will be regularly updated in the Jira database without requiring users to log in or an admin having to manually update users.

In addition to the interval-based syncs, the directory will also update a user's details and groups on a per-user basis when that user logs in.

Only has Read permission to LDAP. Does not have the option nor ability to Write (i.e. make changes) back up to LDAP.

In addition to Read-Only options, this directory type has the option to use "Read/Write", which allows it to push user changes made in Jira back upstream to LDAP (assuming the bind user is permitted to make such changes in the LDAP server in the first place).

Does not proactively reach out to synchronize LDAP users, groups, or group memberships. LDAP information is pulled in upon authentication of a given user, on a per-user basis (and if the options to do so have been selected).

• You have a very large LDAP directory but only a small subset of users/groups are relevant to Jira. However, you are not able to configure your LDAP filters such that only this subset of users/groups are within the search scope. A DELEGATED directory can help in this case, to avoid potential performance impact since a CONNECTOR might spend too much time syncing a large dataset.

• Most customers will benefit from using a Connector as its proactive syncing means LDAP changes are automatically reflected in Jira.
• You would like to be able to make user/group changes in Jira, and automatically push those changes upstream to LDAP (this is an option; not required).

• You require LDAP changes to be kept up-to-date in Jira, even for users that have not logged in for a long time.
• You require users who have not ever logged in to appear in Jira.
• You require users who have been removed/disabled in LDAP to automatically be removed/disabled in Jira without admin intervention

• You have a huge LDAP directory and do not have a meaningful way to filter down users/groups relevant to Jira using a Base DN or LDAP filter. Using a CONNECTOR would mean long sync times and pulling in way too many irrelevant users. The action of syncing a directory costs Jira resources (in terms of CPU/memory/database connections) and therefore if Jira has to sync a huge dataset, there is a potential for negative performance impact.