Как проверить фактический identity source, Kerberos ticket, share-level роль, файловые ACL и июльский переход AES, не меняя AD-объект вслепую.
Начните с фактического identity source
Запишите имя storage account и откройте его SMB identity-based access configuration. Microsoft разделяет on-premises AD DS, Microsoft Entra Domain Services и Microsoft Entra Kerberos; сходные названия не делают режимы взаимозаменяемыми. Entra join клиентского ПК сам по себе не означает, что storage account настроен на Entra Kerberos. Не переключайте источник идентификации ради теста: это изменение затронет других пользователей. Сначала зафиксируйте режим, доменную принадлежность пользователя и способ синхронизации гибридной учётной записи, не сохраняя пароль или ticket в отчёте.
Разложите авторизацию на ticket, роль и ACL
Успешная аутентификация Kerberos ещё не даёт доступ к файлу. Для AD DS Microsoft требует share-level permission и файловые ACL. Поэтому проверка строится в три шага: получает ли клиент ticket для файлового сервиса, назначена ли пользователю или группе нужная роль на share и разрешает ли NTFS ACL нужную операцию. Используйте тестовую папку и чтение нейтрального файла, а не изменение прав корня. Если ticket отсутствует, ACL не является первой ветвью; если доступ к share есть, но отдельная папка запрещена, не меняйте identity source.
Проверьте границу июльского изменения AES
Официальная статья об encryption troubleshooting ограничивает июльское изменение storage accounts, использующими on-premises AD DS. Entra Kerberos следует другой границе применимости. Для AD DS зафиксируйте поддерживаемый тип шифрования объекта и результат официальной диагностики, но не делайте вывод по одному сообщению KRB_AP_ERR_MODIFIED: Microsoft также связывает его с SPN/UPN mismatch. Переход к AES-256 требует проверки зависимостей и change window. Не включайте старые алгоритмы обратно как универсальный обход и не редактируйте SPN без резервной фиксации текущего состояния.
Стоп-условия и данные для владельцев платформы
Остановитесь до изменений, если один storage account обслуживает production, нет прав читать конфигурацию AD или тест затрагивает общую группу. Для эскалации соберите тип join устройства, identity source, время попытки UTC, имя share в обезличенном виде, факт наличия ticket, назначенную роль, результат доступа к тестовой папке, тип encryption и вывод Debug-AzStorageAccountAuth без секретов. Не прикладывайте ticket cache, пользовательские SID, токены, полные имена серверов и ACL с персональными группами в публичную ветку. Цель пакета — показать, на каком из трёх рубежей прекращается доступ.
Материал подготовлен редакцией VOne с применением ИИ для структурирования; технические границы вручную проверены по Microsoft Learn, обсуждение использовано только как обезличенный сигнал.
Источники и проверка
- Microsoft Learn — Azure Files AD DS overview проверено 2026-08-03
- Microsoft Learn — Azure Files encryption troubleshooting проверено 2026-08-03
- Microsoft Learn — Enable AD DS authentication проверено 2026-08-03
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.