После согласованного обновления требуется повторный вход в SSO, а прежние пароли приложений нужно выпустить заново. Новые токены привязаны к версии безопасности учётной записи и GUID каталога: изменение версии или замена личности по тому же адресу делает прежний токен недействительным. Старые Redis-токены token- больше не принимаются даже при совпадении адреса и живой веб-сессии: они не содержат доказуемой привязки к личности. Обычный пароль и новые токены PostgreSQL authtoken- продолжают работать с действующими ограничениями доступа. Эти изменения не переносят почту и не гарантируют завершение уже открытых соединений.

После явного назначения нового ящика сначала сохраняется привязка, а вход остаётся закрытым со статусом «Подготавливается хранилище». Обработчик AD создаёт новое пустое хранилище почты и рабочих данных и сверяет GUID, привязку и ограничения ещё раз перед включением. Существующий каталог с тем же адресом, даже пустой, автоматически не принимается. Удаление пользователя из базы не освобождает адрес прежнего каталожного ящика для новой личности. При ошибке проверьте журнал каталога; повторная попытка выполняется с задержкой около 1–2 минут, а недоступный AD сначала требует восстановления соединения. Не удаляйте каталоги вручную и не снимайте блокировку для обхода проверки. Эта защита не выполняет перенос или пересоздание старого ящика.

«Можно назначить почту» — запись импортирована, ящика и известных блокирующих состояний нет. «Ящик назначен» означает наличие привязки, но само по себе не гарантирует вход. «Отключён в AD», «Отсутствует в каталоге» и «Исключён из синхронизации» требуют проверки объекта или настроек каталога. «Конфликт идентичности» требует проверки GUID и принадлежности ящика. «Обнаружено изменение адреса» сообщает о смене mail в AD, а не о согласии администратора или завершённом переносе. Сохранённое решение обозначается отдельно: «Запрошено переименование». У записей с блокирующими состояниями назначение недоступно. Счётчики «На этой странице» относятся к текущей странице и поиску, а не ко всей AD; уведомления об адресах учитываются отдельно и могут иметь другую пагинацию.

В карточке назначенного каталожного пользователя можно менять локальные почтовые параметры: квоту, разрешённые протоколы, антиспам и пересылку. Имя, принадлежность к каталогу и каталожные группы остаются под управлением AD; локальный сброс пароля для AD недоступен. Флажок «Локально разрешить доступ» хранит решение администратора Blackhole и не снимает блокировку каталога. Вход разрешён только при допустимом состоянии AD и локальном разрешении, с учётом протокола и проверки пароля. Повторное включение объекта в AD не отменяет отдельный локальный запрет.

Каждый новый парольный вход каталожного пользователя проверяется через AD либо настроенный для каталога RADIUS. Прежний успешный вход не используется как кешированное подтверждение пароля. После смены пароля учитывайте время репликации между контроллерами AD. Уже открытые сеансы и выданные токены не выполняют новый LDAP Bind: для обнаружения смены пароля используется отдельная проверка при синхронизации. Политика TOTP определяется настройкой группы, а не её названием: она действует и для синхронизированной группы с произвольным именем. Ошибка чтения политики закрывает вход с временной ошибкой, а не отключает второй фактор.

При синхронизации AD / Samba Blackhole читает pwdLastSet — отметку последней смены пароля, но не сам пароль. Первая достоверная фиксация pwdLastSet для назначенного ящика один раз отзывает ранее выданный доступ: потребуется повторный вход и перевыпуск паролей приложений, даже если пароль в AD недавно не менялся. При следующих синхронизациях отзыв повторяется только при изменении pwdLastSet; повторное чтение того же значения не вызывает нового отзыва. Настоящее нулевое значение тоже учитывается. В журнале первая фиксация отмечается как ldap.password.baseline_revoked, последующее изменение — ldap.password.changed. Письма, контакты и календари не изменяются.

Это периодическая проверка, а не мгновенное уведомление из AD. Плановый успешный обход выполняется через шесть часов; явная синхронизация позволяет проверить изменения раньше. Если pwdLastSet отсутствует, недоступен или некорректен, обход считается неполным: значение не подменяется нулём и исходная отметка не выдумывается. Уже подтверждённые отключения учётных записей и конфликты нового objectGUID всё равно блокируют доступ; неполные данные не восстанавливают его. Недоступность AD сама по себе не добавляет запрет для всех ранее выданных токенов. Открытые соединения зависят от проверок версии доступа в соответствующем протоколе: это не мгновенный разрыв всех SMTP-соединений или уже выполняющихся DAV-запросов.

Управление каталогом и назначение ящиков в текущем интерфейсе доступны глобальному администратору. Куратор ИБ может просматривать каталог и состояния, но не назначать почту. Импорт, назначение ящика, членство в синхронизированной группе и настройка 2FA не выдают административных прав автоматически. Локальные полномочия и их область проверяются отдельно; список «Разрешения» показывает существующие записи и сам по себе не является редактором прав.

Объект AD определяется по objectGUID, а не по имени или адресу. Новый объект с прежним адресом не получает старый ящик. После изменения mail в AD вверху списка учётных записей появляется уведомление с именем сотрудника, адресом Blackhole на момент изменения и обнаруженным значением AD. Оно относится и к явно назначенным ящикам, и к старым автоматическим привязкам; сохранённая запись не подтверждает актуальное существование ящика или доступность входа. Администратор сервера явно выбирает «Оставить текущий адрес» или «Переименовать существующий ящик» и сохраняет решение. Первый вариант принимает изменение к сведению и сохраняет текущий адрес. Второй сохраняет запрос на перенос существующего ящика; само сохранение не меняет адрес, не создаёт новый пустой ящик и не подтверждает перенос данных. Автоматический перенос пока не реализован. Куратор ИБ может только читать уведомления. Для решения нужны успешная полная синхронизация и подтверждённая привязка к той же личности; исчезновение объекта или смена привязки требуют отдельной проверки. При изменении версии перечитайте адреса и выберите действие заново. Решение не снимает отдельный локальный запрет, отключение в AD или другие блокировки. Нельзя устранять конфликт ручной заменой email в базе.

Группа AD определяется контроллером и objectGUID, а не названием. Одноимённые группы из разных каталогов не объединяются. Переименование сохраняет идентичность группы; удалённая и заново созданная группа не наследует локальные права прежней. Синхронизация одного каталога не удаляет подтверждённые членства другого каталога и локальные группы. Если переход со старых групп может снять 2FA или другую явную политику, старые членства сохраняются, доступ к затронутому ящику закрывается и в аудите появляется ldap.groups.policy_review_required. Не удаляйте ограничения только ради успешной синхронизации: сначала сверьте происхождение групп и перенесите утверждённую политику на нужную группу.

После применения блокировки каталога новые входы запрещены. В односерверном почтовом профиле монитор проверяет GUID, версию безопасности и разрешения примерно каждые пять секунд и закрывает открытые IMAP/POP3-сессии затронутой записи. Ошибка базы или команды может задержать проверку; pending_accounts во внутреннем статусе mail-control должен вернуться к нулю. Имена с буквальными * или ? требуют отдельного точного механизма завершения: монитор не использует маску, которая могла бы отключить чужие сессии. При SMTP submission на 465/587 право отправки проверяется на получателе и после передачи письма, поэтому старый успешный AUTH не разрешает новые письма заблокированной записи. Приём межсерверной почты на 25 не изменяется.

Для проверки на отдельной согласованной учётной записи откройте почту, отключите запись в AD, запустите синхронизацию и дождитесь её результата. Проверьте новый вход и уже открытый IMAP/POP3-клиент отдельно. Включите запись, повторите синхронизацию и новый вход: отдельный локальный запрет должен остаться. Плановая успешная синхронизация сейчас повторяется через шесть часов; LDAP_SYNC_INTERVAL задаёт лишь частоту проверки очереди, а не период полного обхода. Не ждите планового обхода при срочном отзыве доступа. Неполная выгрузка каталога не вызывает массовое отключение отсутствующих записей. SMTP-проверка пока не привязана к версии первоначального AUTH: после повторного включения или повторного использования адреса старое SMTP-соединение ещё не отделено от новой учётной записи. Уже выполняющийся DAV-запрос также может завершиться. Поэтому эти проверки не доказывают готовность автоматического переноса или пересоздания хранилища. Ошибка Bind DN, недоверенный CA и пустой результат фильтра — разные причины; изучайте журнал, не расширяйте права служебной учётной записи наугад.

Пять сценариев ниже проверяются на отдельном согласованном стенде и выделенных тестовых объектах, не на рабочих сотрудниках. До удаления или пересоздания объекта нужна проверенная резервная копия и возможность восстановить каталог и данные. Запишите исходные objectGUID, адрес и контрольные письма, контакты и события; отдельно отметьте локальные запреты и делегированные права. Проверяйте веб-клиент и настольный клиент отдельно. После каждого изменения запустите синхронизацию и дождитесь её результата: сохранение формы подключения или успешный LDAP Bind не означает завершение обхода.

Обязательно сверьте, что у заново созданного тестового объекта другой objectGUID. Требуемый конечный результат — отдельный новый пустой ящик, а старые письма, контакты, календари, файлы и права остаются у старой личности. Сейчас автоматическое пересоздание ещё не включено: защитный отказ или конфликт идентичности допустим как проверка изоляции, но не является выполнением сценария создания нового ящика. Нельзя открывать старое хранилище новой учётной записи, вручную менять GUID/email в базе или считать совпадение адреса доказательством владения. Полная приёмка этого сценария должна дождаться включённого и проверенного механизма пересоздания.

Сохраните исходный objectGUID и измените mail тестового объекта AD. Для явно назначенного адреса администратор выбирает «Оставить текущий адрес» либо «Переименовать существующий ящик» в уведомлении. Первый вариант сохраняет текущий адрес. Второй пока сохраняет только запрос: перенос данных и смена адреса ещё не подтверждены. Бейдж «Обнаружено изменение адреса» сам по себе не является согласием на переименование. Требуемый итог полноценного переноса — прежние письма, контакты, календари и файлы доступны той же личности по новому адресу, без нового пустого ящика и повышения прав. Пока обработчик переноса не подключён, сохранённое решение не считается успешной приёмкой этого сценария.

Для каждого сценария запишите версию компонентов, время полного обхода, состояние каталога и привязки, результат нового входа и результат уже открытой сессии отдельно. Приложите обезличенные сообщения об ошибках без паролей, токенов и содержимого писем. Восстановление операции после потери ответа базы проверяется отдельно в изолированной среде: таймаут не доказывает откат. Наличие исходников, тестового сценария или записи «запрошено» не подтверждает, что функция собрана, развёрнута и успешно прошла приёмку.