У нас есть сторонний инструмент, который мы используем для создания объектов AD (пользователей и групп). Этот инструмент использует ADSI для создания объектов, и мы не указываем и не можем указать DC, в который он будет записывать. Таким образом, он может записать в DC1 сегодня и DC2 завтра. Хотя все вокруг повторяется, так что не беспокойтесь.
Проблема в том, что наш процесс создания групп выглядит следующим образом:
- Создание группы вопросов для стороннего инструмента.
- В случае успеха, ищите объект группы в AD с помощью вызовов LDAP (это приложение Java), чтобы получить SID. (Сторонний инструмент не возвращает это)
Проблема в том, что вызовы Java LDAP действительно указывают DC при выполнении поиска. Допустим, Java настроена на чтение из DC1. Если сторонний инструмент выполняет запись в DC2, то при поиске Java для DC1 не удается найти группу.
Задержка репликации AD мала, поэтому, если мы добавим 15-секундную задержку между созданием и поиском, то это сработает, но немного уродливо.
Кроме того, я попытался запросить все контроллеры домена из Java. Это работает для приведенного выше примера, но у него все та же основная проблема, когда мы обновляем атрибут для пользователя или группы и сразу пытаемся прочитать его обратно. Задержка, кажется, единственный рабочий подход, но, похоже, должен быть лучший подход, чем этот.