For anyone else that may be interested, additional tickets related to the LDAP stack in JIRA have been opened.

"Support load-balanced LDAP/AD servers with JIRA"
http://jira.atlassian.com/browse/JRA-24133

"Avoid replicating entire LDAP/AD identity directories into JIRA local database" (addresses performance issues)
http://jira.atlassian.com/browse/JRA-24162

Please vote and add any additional comments!

I don't understand the problem with multiple AD servers. We load balance them behind a network device and don't have a problem with any uSNChanged attribute.

What Product / version are you using?
This discussion relates to JIRA v4.3 or later (or Confluence 3.5 or later).

Is JIRA having this problem because it caches the Active Directory?

It is having this problem because it uses the "uSNChanged" attribute to optimise the synchronisation of the cache.

Confluence doesn't cache the entire AD, does it?

Confluence v3.5+ will cache all users and groups that are not filtered out.
See JRA-24128 for example filters.
Also note that the "delegated LDAP" directory does not eagerly download users.

I don't understand the problem with multiple AD servers. We load balance them behind a network device and don't have a problem with any uSNChanged attribute. Is JIRA having this problem because it caches the Active Directory?

Confluence doesn't cache the entire AD, does it?

BTW: Doesn't Crowd support your requirements? Crowd has a working cache layer - so you can take you AD instances down without Jira noticing. Considering the size of your organization, that would fit the budget, no?

JIRA has the same cache.
Neither Crowd nor JIRA caches the user's password though (for security reasons).
So if you take down AD while JIRA is running, then already logged in users will not notice, but other users will not be able to log in.

(Actually - you will also fail to do write operations - but I will assume most people would have read-only access to LDAP/AD)

#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.

Good point - I hadn't thought about that.
I think you should raise this as its own Improvement request - "allow load-balancing for AD".
The other thing we would need to consider is the interaction of the LDAP connection pool with any load-balancing.

Hi Chris,

If you set up JIRA -> LB -> AD, then whenever the AD server changes, JIRA will perform a full sync. Depending on the size of your userbase, this may or may not be a big deal. If your LB only switches the destination AD server when the current one goes down, then you'll only be paying a 1-full-sync-per-quarter penalty. And, if your IT team take AD down on a weekend, it's likely no-one will notice.

Synchronisation performance is primarily affected by the number of memberships in your directory, so if you reduce the number of groups read into JIRA, then you'll find the initial sync much faster. Because JIRA uses uSNChanged for delta polling, subsequent syncs will be extremely fast.

Additionally, as Mark mentioned, the LDAP users + local groups directory in JIRA will be enhanced in a 4.3.x release, most likely 4.3.2. This will allow you to achieve the scenario you defined in your previous comment.

Cheers,
Dave.

@Chris: Considering that it took almost 8 years to get this one fixed, i'd suggest you bring plenty of time for the resolution of any other tickets you care to open

BTW: Doesn't Crowd support your requirements? Crowd has a working cache layer - so you can take you AD instances down without Jira noticing. Considering the size of your organization, that would fit the budget, no?

I'll get some new tickets opened.

@ Mark
By load-balancing, the issue I was referring to is related to this section of the documentation:
http://confluence.atlassian.com/display/JIRA/User+Management+Limitations+and+Recommendations
About half-way down:

"#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."

Many companies have a single DNS entry (mydomain.mycompany.com) that points to a load balancer that directs traffic to one of many directory servers. (Or, as you suggested, some might use DNS round robin .) However, neither the use of DNS round robin nor use of an actual load balancer is supported by JIRA – both approaches to load balancing direct traffic to different servers, which would violate limitation #2 above.
As I read it, JIRA only supports me having to pick one of our directory servers and direct JIRA traffic only to that single server. Then, when our directory servers are brought down one at a time for maintenance once per quarter, JIRA will be inoperable while the directory server I picked is down.

It seems there is no good solution, not even a workaround, for this problem.

As I said, I'll get some new tickets opened...
Thanks!

@ Chris F

Now that this issue has been "fixed", where should further discussions or requests to "FURTHER improve the LDAP stack in JIRA" be reported?

As suggested by Gregory, you should raise each request as a new issue.
Add links and/or comments so others can follow.

The idea of effectively replicating my company's entire identity directory into the JIRA database is poor. It doesn't scale well.

One solution to this is "Copying Users on First Login" in the "Internal with LDAP Authentication" Directory.
This is already developed in the Crowd Embedded library, and will ship in a future release of JIRA.
See
http://confluence.atlassian.com/display/DOC/Connecting+to+an+Internal+Directory+with+LDAP+Authentication

I also raised JRA-24128 for the "filter by group membership" idea.

Plus, no support for load-balanced/highly-available AD servers? What gives?

If you want load-balancing then you should set up a load-balancer outside of your Issue Tracker - eg see http://eldapo.blogspot.com/2007/02/using-round-robin-dns-to-load-balance.html
If you want failover, then follow JRA-23245.

Chris F., please go create several new tickets (one for each feature you're looking for) and post the links here. We'll go vote for them.