Ограничения и рекомендации для управления пользователями

Общие рекомендации

Избегайте дублирования имен пользователей по каталогам. Если вы подключаетесь к нескольким пользовательским каталогам, мы рекомендуем вам убедиться, что имена пользователей уникальны для одного каталога. Например, мы не рекомендуем, чтобы у вас был пользовательский jsmith как в «Directory1», так и «Directory2». Причина заключается в возможности путаницы, особенно если вы меняете порядок каталогов. Изменение порядка каталогов может изменить пользователя, к которому относится данное имя пользователя.
Будьте внимательны при удалении пользователей в удаленных каталогах. Если вы подключаетесь к каталогу LDAP, каталогу Crowd или удаленному каталогу JIRA, будьте внимательны при удалении пользователей из удаленного каталога. Если вы удалите пользователя, связанного с данными в JIRA, это вызовет проблемы в JIRA. Мы рекомендуем вам выполнять все управление пользователями в JIRA, поскольку пользовательский интерфейс JIRA предотвратит удаление пользователя, если есть запросы, назначенные пользователю, сообщенные пользователем или пользователь является ведущим проекта.

Оптимальное количество пользователей и групп в вашем каталоге LDAP

Соединение с вашим каталогом LDAP обеспечивает мощную и гибкую поддержку для подключения, настройки и управления серверами каталогов LDAP. Для достижения оптимальной производительности задача фоновой синхронизации загружает требуемых пользователей и группы с сервера LDAP в базу данных приложения и периодически извлекает обновления с сервера LDAP для хранения данных на шаге. Количество времени, необходимое для копирования пользователей и групп, увеличивается с количеством пользователей, групп и членов групп. По этой причине мы рекомендовали максимальное количество пользователей и групп, как описано ниже.

Эта рекомендация влияет на подключения к каталогам LDAP:

Microsoft Active Directory
Все остальные серверы каталогов LDAP

Не меняются следующие конфигурации LDAP:

Внутренние каталоги с аутентификацией LDAP
Каталоги LDAP, настроенные для «Только аутентификация, копирование пользователя при первом входе»

Выберите одно из следующих решений, в зависимости от количества пользователей, групп и членства в каталоге LDAP.

Ваша окружающая среда	Рекомендация
До 10 000 (десять тысяч) пользователей, 1000 (одна тысяча) групп и 20 (двадцать) групп на пользователя	Выберите тип каталога «LDAP» или «Microsoft Active Directory». Вы можете использоватьопцию полной синхронизации. База данных вашего приложения будет содержать все пользователи и группы, которые находятся на вашем сервере LDAP.
Больше, чем указано выше	Используйте фильтры LDAP, чтобы уменьшить количество пользователей и групп, видимых для задачи синхронизации.

Наши результаты тестирования

Мы провели внутреннюю проверку синхронизации с сервером AD в нашей локальной сети, состоящей из 10 000 пользователей, 1000 групп и 200 000 членов.

Мы обнаружили, что начальная синхронизация заняла около 5 минут. Последующая синхронизация с 100 модификациями на сервере AD заняла пару секунд.

Помните, что при настройке производительности процесса синхронизации возникает ряд факторов, в том числе:

Размер пользовательской базы (Size of userbase). Используйте фильтры LDAP, чтобы они соответствовали вашим требованиям.
Тип сервера LDAP (Type of LDAP server). В настоящее время мы поддерживаем обнаружение изменений в AD, поэтому последующие синхронизации намного быстрее для AD, чем для других серверов LDAP.
Топология сети (Network topology). Чем дальше ваш сервер LDAP будет с вашего сервера приложений, тем более латентными (скрытыми) запросами LDAP будут.
Производительность базы данных (Database performance). Поскольку процесс синхронизации кэширует данные в базе данных, производительность вашей базы данных будет влиять на производительность синхронизации.
Размер кучи (выделяемое оперативное пространство памяти) JVM (JVM heap size). Если размер вашей кучи слишком мал для вашей базы данных, вы можете столкнуться с большой сборкой мусора во время процесса синхронизации, что, в свою очередь, может замедлить синхронизацию.

Резервный LDAP не поддерживается

Соединения LDAP не поддерживают конфигурацию двух или более серверов LDAP для избыточности (автоматический переход на другой ресурс, если один из серверов опускается).

Конкретные примечания для подключения к Active Directory

Когда приложение синхронизируется с Active Directory (AD), задача синхронизации запрашивать только изменения с сервера LDAP, а не на всю базу пользователей. Это оптимизирует процесс синхронизации и дает гораздо более высокую производительность для второго и последующих запросов.

С другой стороны, этот метод синхронизации приводит к нескольким ограничениям:

Внешне движущиеся объекты вне области видимости или переименования объектов вызывают проблемы в AD. Если вы перемещаете объекты из области действия в AD, это приведет к несогласованному кешу. Мы рекомендуем вам не использовать внешний интерфейс каталога LDAP для перемещения объектов из области поддерева, как определено на экране конфигурации каталога приложения. Если вам необходимо внести структурные изменения в свой каталог LDAP, вручную синхронизируйте кеш каталога после внесения изменений, чтобы обеспечить согласованность кеша.
Синхронизация между серверами AD не поддерживается. Microsoft Active Directory не реплицирует (копирует) атрибут uSNChanged для всех экземпляров. По этой причине мы не поддерживаем подключение к различным серверам AD для синхронизации. (Конечно, вы можете определить несколько разных каталогов, каждый из которых указывает на собственный соответствующий сервер AD.)
Синхронизация с серверами AD за балансиром нагрузки не поддерживается. Как и при синхронизации между двумя разными серверами AD, Microsoft Active Directory не реплицирует (копирует) атрибут uSNChanged для всех экземпляров. По этой причине мы не поддерживаем подключение к различным серверам AD, даже если они сбалансированы по нагрузке. Вам нужно будет выбрать один сервер (желательно тот, который является локальным) для синхронизации, вместо использования балансировки нагрузки.
Вы должны перезапустить приложение после восстановления AD из резервной копии. При восстановлении из резервной копии сервера AD, временные метки uSNChanged возвращаются к времени резервного копирования. Чтобы избежать возникшей путаницы, вам необходимо очистить кеш каталога после операции восстановления Active Directory.
Для удаления объектов AD требуется доступ администратора. Active Directory хранит удаленные объекты в специальном контейнере cn=Deleted Objects (cn = удаленные объекты). По умолчанию для доступа к этому контейнеру вам необходимо подключиться как администратор, и поэтому, чтобы задача синхронизации была осведомлена об удалении, вы должны использовать учетные данные администратора. В качестве альтернативы можно изменить разрешения для контейнера cn = Deleted Objects. Если вы хотите это сделать, обратитесь к этой статье Microsoft KB.
Пользовательский DN, используемый для подключения к AD, должен иметь возможность видеть атрибут uSNChanged. Задача синхронизации основана на атрибуте uSNChanged для обнаружения изменений и поэтому должна находиться в соответствующих группах безопасности AD, чтобы увидеть этот атрибут для всех объектов LDAP в поддереве.

Единый вход в несколько приложений не поддерживается

Когда вы подключаетесь к приложению JIRA для управления пользователями, у вас не будет единого входа в приложениях, подключенных таким образом. JIRA, действуя как менеджер каталогов, не поддерживает SSO.

Коннекторы пользовательских приложений не поддерживаются

Приложения JIRA, Confluence, FishEye, Crucible и Bamboo могут подключаться к серверу JIRA для управления пользователями. Пользовательским соединителям приложений необходимо будет использовать новый REST API.

Пользовательские каталоги не поддерживаются

Более ранние версии JIRA поддерживали поставщиков OSUser. Поэтому было возможно написать специальный провайдер для получения пользовательской информации из любого внешнего каталога пользователя. Это уже не так.

Загрузите экземпляр JIRA

Если ваш экземпляр JIRA уже находится под большой нагрузкой, использование его в качестве пользовательского сервера увеличивает эту нагрузку.

Приложения JIRA Cloud не поддерживаются

Вы не можете использовать приложения JIRA Cloud для управления автономными пользователями. Пользователям облаков и пользователям в ваших самодостаточных приложениях Atlassian необходимо управлять отдельно.

Ваша окружающая среда	Рекомендация
Если все следующее верно: Приложение JIRA не находится под большой нагрузкой. Вы хотите разделить управление пользователями и группами в нескольких приложениях, таких как один сервер программного обеспечения JIRA и один сервер Confluence или два JIRA-сервера. Вам не требуется единый вход (SSO) между вашим JIRA-приложением и Confluence или между двумя серверами JIRA. У вас нет пользовательских коннекторов приложений. Или, если у вас они есть, вы можете конвертировать их для использования нового REST API. Вы готовы закрыть все свои серверы, когда вам нужно обновить приложение JIRA.	Ваша среда соответствует оптимальным требованиям для использования приложения JIRA для управления пользователями.
Если выполняется одно или несколько из следующих утверждений: Если ваше приложение JIRA уже находится под большой нагрузкой. Вы хотите использовать управление пользователями и группами в более чем 5 приложениях. Для нескольких приложений требуется единый вход (SSO). У вас есть настраиваемые приложения, интегрированные с помощью API- интерфейса Crowd SOAP, и вы не можете их преобразовать, чтобы использовать новый REST API. Вы не можете закрыть все свои серверы, когда вам нужно обновить JIRA.	Мы рекомендуем установить Atlassian Crowd для управления пользователями и SSO.
Если вы планируете создать собственный коннектор каталогов, чтобы определить собственное хранилище для пользователей и групп ...	Посмотрите, будет ли одно из следующих решений работать для вас: Если вы создали настраиваемый поставщик для поддержки определенной схемы LDAP, проверьте поддерживаемые схемы LDAP, чтобы узнать, можно ли использовать одну из них. Если вы создали пользовательский поставщик для поддержки вложенных групп, попробуйте включить вложенные группы в поддерживаемые коннекторы каталогов. Если вы создали пользовательский провайдер для подключения к своей собственной базе данных, попробуйте вместо этого загрузить данные в базу данных приложения. Если вам нужно сохранить соединение с настраиваемым каталогом, пожалуйста, подумайте, соответствует ли Atlassian Crowd вашим требованиям. См. документацию по созданию пользовательского коннектора каталогов.