Устранение неполадок Azure Files проверки подлинности и авторизации на основе удостоверений (SMB)

Применимо к: ✔️ файловым ресурсам SMB Azure

Сводка

В этой статье перечислены распространенные проблемы при использовании проверки подлинности на основе удостоверений с общими папками SMB Azure и приводятся возможные причины и разрешения. Используйте это руководство для диагностики и устранения ошибок проверки подлинности, проблем с разрешениями и проблем конфигурации Kerberos.

Ошибка при запуске модуля AzFilesHybrid

При попытке запустить модуль AzFilesHybrid может появиться следующая ошибка:

Клиент не располагает требуемыми правами доступа.

Причина: недостаточно разрешений AD

Эта проблема возникает, так как у вас нет необходимых разрешений Active Directory (AD) для запуска модуля.

Решение

Обратитесь к привилегиям AD или обратитесь к администратору AD, чтобы предоставить необходимые привилегии.

Ошибка 5 при подключении общей папки Azure

При попытке подключить файловый ресурс может выдаваться следующая ошибка:

"Произошла системная ошибка 5. Отказано в доступе".

Причина: неправильные разрешения на уровне общего доступа

Если конечные пользователи получают доступ к общей папке Azure с помощью проверки подлинности на основе удостоверений, доступ к общей папке завершается ошибкой "Доступ запрещен". Если разрешения на уровне общего доступа неверны.

Решение

Убедитесь, что разрешения настроены правильно. См . раздел "Назначение разрешений на уровне общего ресурса".

Ошибка AadDsTenantNotFound при включении проверки подлинности Microsoft Entra Domain Services для Azure Files "Не удалось найти активные тенанты с идентификатором тенанта Microsoft Entra tenant-id".

Причина

Ошибка AadDsTenantNotFound происходит при попытке включить аутентификацию с использованием Microsoft Entra Domain Services для Azure Files в учетной записи хранения, где Microsoft Entra Domain Services не создан в Microsoft Entra клиенте связанной подписки.

Решение

Включите Microsoft Entra Domain Services в клиенте Microsoft Entra подписки, в которую развернута учетная запись хранения. Для создания управляемого домена требуются права администратора клиента Microsoft Entra. Если вы не являетесь администратором клиента Microsoft Entra, обратитесь к администратору и выполните пошаговые инструкции по созданию и настройке управляемого домена доменных служб Microsoft Entra.

Ошибка. Все добавленные URI должны содержать проверенный домен клиента, идентификатор клиента или идентификатор приложения.

Причина

Эта ошибка возникает во время настройки авторизации на основе удостоверенности для файлов Azure при добавлении URI перенаправления или URI идентификатора, которые не соответствуют требованиям безопасности приложения Microsoft Entra ID.

Microsoft Entra ID применяет ограничения к URI идентификатора приложения и URI перенаправления. Недавно добавленные URI должны ссылаться на одно из следующих значений:

• Проверенный клиентом личный домен
• Идентификатор клиента Microsoft Entra
• Идентификатор приложения (клиента)

Если URI использует непроверенный домен, .local имя узла или произвольный URL-адрес, не связанный с клиентом, политика клиента по умолчанию блокирует запрос.

Идентификатор Microsoft Entra реализует это поведение, и оно не ограничивается службой файлов Azure.

Дополнительные сведения можно найти здесь

• Ограничения для URI идентификаторов приложений Microsoft Entra
• Структура и ограничения URI перенаправления (URL-адрес ответа)
• Управление пользовательскими доменными именами в Microsoft Entra ID

Решение

При настройке регистрации приложения или проверки подлинности на основе удостоверений для файлов Azure убедитесь, что любой URI перенаправления или URI идентификатора использует один из поддерживаемых форматов:

• Использование проверенного клиентом личного домена
• Использование идентификатора клиента Microsoft Entra
• Использование идентификатора приложения (клиента)

Не используйте непроверенные домены, .local имена узлов или произвольные URL-адреса, так как политика клиента идентификатора Microsoft Entra отклоняет эти значения. Если вы не уверены, какие домены проверены в клиенте, просмотрите раздел "Имена пользовательских доменов" в Центре администрирования Microsoft Entra или обратитесь к администратору клиента.

Не удается монтировать файловые ресурсы Azure с учетными данными AD.

Действия по самодиагностике

Сначала убедитесь, что вы выполнили шаги по включению аутентификации Azure Files через AD DS.

Во-вторых, попробуйте монтировать общую папку Azure с ключом учетной записи хранения. Если сетевой ресурс не удается подключить, скачайте AzFileDiagnostics, чтобы проверить рабочую среду клиента. AzFileDiagnostics может обнаруживать несовместимые конфигурации клиента, которые могут привести к сбою доступа для Azure Files, предоставить рекомендательное руководство по самостоятельному исправлению и собрать диагностические трассировки.

В-третьих, можно запустить Debug-AzStorageAccountAuth командлет, чтобы выполнить набор базовых проверок конфигурации AD с пользователем AD, вошедшего в систему. Этот командлет поддерживается в AzFilesHybrid v0.1.2+.

1. Войдите в Azure PowerShell интерактивно в качестве пользователя AD, имеющего разрешение владельца в целевой учетной записи хранения:

   Connect-AzAccount
   

2. Debug-AzStorageAccountAuth Запустите командлет:

   $ResourceGroupName = "<resource-group-name-here>"
   $StorageAccountName = "<storage-account-name-here>"
   
   Debug-AzStorageAccountAuth `
       -StorageAccountName $StorageAccountName `
       -ResourceGroupName $ResourceGroupName `
       -Verbose
   

Командлет выполняет эти проверки поочередно и предоставляет рекомендации в случае ошибок:

1. CheckADObjectPasswordIsCorrect: Убедитесь, что пароль, настроенный для идентификации AD, соответствующей учетной записи хранения, совпадает с ключом kerb1 или kerb2 этой учетной записи хранения. Если пароль неверный, можно запустить Update-AzStorageAccountADObjectPassword , чтобы сбросить пароль.
2. CheckADObject: Убедитесь, что в Active Directory есть объект, представляющий учетную запись хранения и имеющий правильное SPN (имя участника службы). Если SPN настроен неправильно, выполните командлет Set-AD, используя командлет отладки, чтобы настроить SPN.
3. CheckDomainJoined: убедитесь, что клиентский компьютер присоединен к Active Directory (AD). Если компьютер не присоединен к AD, обратитесь к инструкциям по присоединению компьютера к домену .
4. CheckPort445Connectivity: проверьте, открыт ли порт 445 для подключения SMB. Если порт 445 не открыт, обратитесь к средству устранения неполадок AzFileDiagnostics для решения проблем с подключением Azure Files.
5. CheckSidHasAadUser. Проверьте, синхронизирован ли пользователь AD с Microsoft Entra ID. Если вы хотите узнать, синхронизирован ли конкретный пользователь AD с Microsoft Entra ID, можно указать -UserName и -Domain в входных параметрах. Для заданного идентификатора безопасности проверяется, есть ли связанный пользователь Microsoft Entra.
6. CheckAadUserHasSid. Проверьте, синхронизирован ли пользователь AD с Microsoft Entra ID. Если вы хотите узнать, синхронизирован ли конкретный пользователь AD с Microsoft Entra ID, можно указать -UserName и -Domain в входных параметрах. Для данного пользователя Microsoft Entra он проверяет идентификатор безопасности. Чтобы выполнить эту проверку, необходимо указать параметр -ObjectId вместе с идентификатором объекта пользователя Microsoft Entra.
7. CheckGetKerberosTicket: Попробуйте получить билет Kerberos для подключения к учетной записи хранилища. Если нет допустимого токена Kerberos, запустите командлет klist get cifs/storage-account-name.file.core.windows.net и проанализируйте код ошибки для определения причины сбоя извлечения билета.
8. CheckStorageAccountDomainJoined: проверьте, включена ли проверка подлинности AD и заполнены ли свойства учетной записи AD. Если нет, включите аутентификацию AD DS в Azure Files.
9. CheckUserRbacAssignment: Проверьте, назначена ли удостоверению AD правильная роль RBAC, чтобы предоставить разрешения уровня общего доступа для доступа к Azure Files. Если нет, настройте разрешение на уровне общего доступа. (Поддерживается в AzFilesHybrid v0.2.3+)
10. CheckUserFileAccess. Проверьте, обладает ли учетная запись AD соответствующими разрешениями каталога или файла для доступа к Azure Files (списки управления доступом Windows, ACLs). Если нет, настройте разрешение на уровне каталога или файла. Чтобы выполнить эту проверку, необходимо указать -FilePath параметр, а также путь к подключенному файлу, к которому требуется выполнить отладку доступа. (Поддерживается в AzFilesHybrid v0.2.3+)
11. CheckKerberosTicketEncryption: проверьте, настроена ли учетная запись хранения для принятия типа шифрования, используемого билетом Kerberos. (Поддерживается в AzFilesHybrid v0.2.5+)
12. CheckChannelEncryption: проверьте, настроена ли учетная запись хранения для принятия типа шифрования канала SMB, используемого клиентом. (Поддерживается в AzFilesHybrid v0.2.5+)
13. CheckDomainLineOfSight: проверьте, имеет ли клиент бесперебойное сетевое подключение к контроллеру домена. (Поддерживается в AzFilesHybrid v0.2.5+)
14. CheckDefaultSharePermission: проверьте, настроено ли разрешение на уровне общего ресурса по умолчанию . (Поддерживается в AzFilesHybrid v0.2.5+)
15. CheckAadKerberosRegistryKeyIsOff. Проверьте, отключен ли ключ реестра Kerberos Microsoft Entra. Если ключ включен, запустите reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 0 из командной строки с повышенными привилегиями, чтобы отключить его, а затем перезагрузите компьютер. (Поддерживается в AzFilesHybrid v0.2.9+)

Если вы просто хотите запустить подмножество предыдущих проверок, можно использовать параметр -Filter, а также указать список проверок, разделенных запятыми. Например, чтобы выполнить все проверки, связанные с разрешениями на уровне общего ресурса (RBAC), используйте следующие командлеты PowerShell:

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth `
    -Filter CheckSidHasAadUser,CheckUserRbacAssignment `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -Verbose

Если у вас есть общий файловый ресурс, подключенный к X:, и если требуется выполнить проверку, связанную с разрешениями на уровне файлов (Windows списки управления доступом), можно выполнить следующие командлеты PowerShell:

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"
$FilePath = "X:\example.txt"

Debug-AzStorageAccountAuth `
    -Filter CheckUserFileAccess `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -FilePath $FilePath `
    -Verbose

Не удалось смонтировать общие папки Azure с помощью Microsoft Entra Kerberos

Действия по самодиагностике

Сначала убедитесь, что вы выполнили действия по включению аутентификации Kerberos через Microsoft Entra.

Во-вторых, можно запустить Debug-AzStorageAccountAuth командлет для выполнения набора основных проверок. Этот командлет поддерживается для учетных записей хранения, настроенных для проверки подлинности Kerberos Microsoft Entra в AzFilesHybrid v0.3.0+.

1. Войдите в Azure PowerShell интерактивно в качестве пользователя AD, имеющего разрешение владельца в целевой учетной записи хранения:

   Connect-AzAccount
   

2. Debug-AzStorageAccountAuth Запустите командлет:

   $ResourceGroupName = "<resource-group-name-here>"
   $StorageAccountName = "<storage-account-name-here>"
   
   Debug-AzStorageAccountAuth -StorageAccountName $StorageAccountName -ResourceGroupName $ResourceGroupName -Verbose
   

Командлет выполняет эти проверки поочередно и предоставляет рекомендации в случае ошибок:

1. CheckPort445Connectivity: проверьте, открыт ли порт 445 для подключения SMB. Если порт 445 не открыт, используйте средство устранения неполадок AzFileDiagnostics для проблем с подключением к Azure Files.
2. CheckAADConnectivity: проверьте подключение Entra. Подключения SMB с аутентификацией Kerberos могут завершиться ошибкой, если клиент не может обратиться к Entra. Если эта проверка завершается ошибкой, это означает, что возникла ошибка сети (возможно, проблема брандмауэра или VPN).
3. CheckEntraObject: Убедитесь, что в Entra есть объект, представляющий учетную запись хранения и имеющий правильное имя субъекта-службы (SPN). Если SPN настроен неправильно, отключите и снова включите аутентификацию Entra Kerberos в учётной записи хранилища.
4. CheckRegKey: проверьте, включен ли CloudKerberosTicketRetrieval раздел реестра. Этот ключ реестра необходим для аутентификации Entra Kerberos.
5. CheckRealmMap: проверьте, настроены ли какие-либо сопоставления областей, чтобы присоединить учетную запись к другой области Kerberos, чем KERBEROS.MICROSOFTONLINE.COM.
6. CheckAdminConsent Проверьте, была ли учетная запись службы Entra предоставлено согласие администратора для разрешений Microsoft Graph, необходимых для получения тикета Kerberos.
7. CheckWinHttpAutoProxySvc: проверяет наличие службы автоматического обнаружения веб-прокси WinHTTP (WinHttpAutoProxySvc), необходимой для проверки подлинности Kerberos Microsoft Entra. Его состояние должно иметь значение Running. По соображениям безопасности вы можете, при необходимости, отключить автоматическое обнаружение веб-прокси (WPAD) через параметры реестра. Однако вы не должны отключать всю WinHttpAutoProxySvc службу, так как она отвечает за множество других важных функций, включая запросы прокси-сервера Центра распространения ключей Kerberos (KDC Proxy).
8. CheckIpHlpScv. Проверьте наличие службы IP Helper (iphlpsvc), необходимой для аутентификации Microsoft Entra с Kerberos. Его состояние должно иметь значение Running.
9. CheckFiddlerProxy: Проверьте, существует ли прокси-сервер Fiddler, который предотвращает аутентификацию Microsoft Entra Kerberos.
10. CheckEntraJoinType: проверьте, присоединен ли компьютер к домену Entra или присоединен к гибридному домену Entra. Это необходимое условие для проверки подлинности Microsoft Entra Kerberos.

Если вы просто хотите запустить подмножество предыдущих проверок, можно использовать параметр -Filter, а также указать список проверок, разделенных запятыми.

Подключение к Azure Files завершается ошибкой при использовании Entra Kerberos из-за неподдерживаемых типов шифрования Kerberos

При монтировании файлового ресурса Azure с использованием проверки подлинности Entra Kerberos операция монтирования завершается ошибкой. Сбор журналов может показать, что служебный билет Kerberos не может быть расшифрован. Вы также можете найти, что настроен следующий раздел реестра: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\SupportedEncryptionTypes

Причина

Если раздел реестра SupportedEncryptionTypes настроен со значением, которое не включает AES Windows разрешает только типы шифрования, указанные в битовой маске. Например, значение 0x7 указывает, что клиент поддерживает только следующие типы шифрования Kerberos:

• DES_CBC_CRC
• DES_CBC_MD5
• RC4_HMAC

Так как Entra Kerberos всегда шифрует билеты на обслуживание с помощью AES-256 (AES256-CTS-HMAC-SHA1-96), монтирование завершается ошибкой, если AES не включен в поддерживаемые типы шифрования для учетной записи или компьютера.

Решение

Чтобы успешно подключить файловые ресурсы Azure с использованием Entra Kerberos, необходимо включить AES-256 в поддерживаемые типы шифрования.

Используйте один из следующих вариантов:

Вариант 1: Удалите раздел реестра (рекомендуется, если он не настроен намеренно)

Если типы шифрования не были намеренно ограничены:

1. Удалить раздел реестра: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\SupportedEncryptionTypes
2. Перезагрузите компьютер.

После перезагрузки повторите подключение общей папки.

Вариант 2. Явно включить AES-256 с помощью групповой политики

Если вашей организации требуется явно настроенные типы шифрования Kerberos:

1. Нажмите Win + R, введите gpedit.msc, и нажмите ВВОД.
2. Перейдите к: Политика локального компьютера > Конфигурация компьютера > Настройки Windows > Параметры безопасности > Локальные политики > Параметры безопасности
3. Откройте сетевую безопасность: настройте типы шифрования, разрешенные для Kerberos.
4. Включите следующие типы шифрования:
   • AES256_HMAC_SHA1
   • AES128_HMAC_SHA1 (необязательно)
5. Примените изменение и перезагрузите компьютер.

После перезагрузки повторите подключение общей папки.

Не удалось настроить разрешения на уровне каталога или файла (списки контроля доступа Windows (ACL)) в Проводнике Windows

Симптом

При попытке настроить списки управления доступом Windows с помощью проводника Windows в подключенном файловом ресурсе может возникнуть один из описанных ниже симптомов:

• После нажатия кнопки "Изменить разрешение " на вкладке "Безопасность " мастер разрешений не загружается.
• При попытке выбрать нового пользователя или группу в поле расположения домена не отображается правильный домен AD DS.
• Вы используете несколько лесов AD и получаете следующее сообщение об ошибке: "Контроллеры домена Active Directory, необходимые для поиска выбранных объектов в следующих доменах, недоступны. Убедитесь, что доступны Active Directory контроллеры домена и повторите попытку выбрать объекты".

Решение

Рекомендуем настроить разрешения на уровне каталогов/файлов с помощью icacls вместо использования Проводника Windows.

Не удается просмотреть UserPrincipalName (UPN) владельца файла или каталога в Проводнике

Симптом

Проводник отображает идентификатор безопасности (SID) владельца файла или каталога, но не унифицированное имя пользователя (UPN).

Причина

Проводник вызывает API RPC непосредственно на сервер (Azure Files), чтобы преобразовать SID в имя пользователя в формате UPN. Azure Files не поддерживает этот API, поэтому UPN не отображается.

Решение

На клиенте, присоединенном к домену, используйте следующую команду PowerShell для просмотра всех объектов в директории и их владельцев, включая UPN (User Principal Name).

Get-ChildItem <Path> | Get-ACL | Select Path, Owner

Ошибки при выполнении командлета Join-AzStorageAccountForAuth

Ошибка: "Службе каталогов не удалось выделить относительный идентификатор"

Эта ошибка может возникнуть, если контроллер домена, выполняющий роль мастера операций FSMO RID, недоступен или был удален из домена и восстановлен из резервной копии. Удостоверьтесь, что все контроллеры доменов работают и доступны.

Ошибка: "Не удается привязать позиционные параметры, поскольку имена не предоставлены"

Эта ошибка, скорее всего, активируется синтаксической ошибкой в команде Join-AzStorageAccountforAuth . Проверьте команду на наличие ошибок или ошибок синтаксиса и убедитесь, что установлена последняя версия модуля AzFilesHybrid .

Поддержка Azure Files для локальной проверки подлинности AD DS с использованием шифрования AES-256 Kerberos.

Azure Files использует проверку подлинности Kerberos для доступа на основе идентификации при использовании локальной Active Directory Domain Services (AD DS). Шифрование Kerberos AES-256 поддерживается с момента использования модуля AzFilesHybrid версии 0.2.2, и это метод шифрования по умолчанию с момента выпуска модуля 0.2.5. Исторически rc4 был единственным поддерживаемым вариантом шифрования до добавления поддержки AES-256.

Шаг 1. Проверка наличия влияния на вас

Выполните следующую команду PowerShell на компьютере, присоединенном к домену, чтобы определить учетные записи хранения, использующие Azure Files с проверкой подлинности AD DS, но не были обновлены до AES-256:

Get-ADObject `
    -LDAPFilter "(&(servicePrincipalName=*.file.core.windows.net)(!(msDS-SupportedEncryptionTypes=*)))" -Properties servicePrincipalName, msDS-SupportedEncryptionTypes |
    Select-Object Name, ObjectClass, servicePrincipalName, msDS-SupportedEncryptionTypes

Если результаты не возвращаются, учетные записи уже поддерживают AES-256, и вам не нужно предпринимать никаких действий. Если возвращаются какие-либо учетные записи, необходимо обновить эти учетные записи для поддержки AES-256 с помощью одного из двух вариантов, описанных на шаге 2.

Шаг 2. Обновление до AES-256

Существует два варианта обновления учетной записи хранения до AES-256. Настоятельно рекомендуется использовать вариант 1 с помощью модуля PowerShell AzFilesHybrid, так как он обрабатывает все необходимые действия автоматически с помощью одной команды. Вариант 2 предоставляет инструкции вручную, если вы не можете использовать модуль.

Вариант 1: Использовать командлет AzFilesHybrid (рекомендуется)

Скачайте последний модуль AzFilesHybrid и запустите следующий скрипт PowerShell.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -StorageAccountName $StorageAccountName

В рамках обновления командлет поворачивает ключи Kerberos, которые необходимо переключить на AES-256. Если вы не хотите повторно создавать оба пароля, вам не нужно поворачиваться обратно.

Вариант 2. Действия вручную

Если вы не можете использовать модуль AzFilesHybrid, можно вручную обновить до AES-256, выполнив следующие действия.

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

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

$sa = Get-AzStorageAccount -ResourceGroupName $ResourceGroupName -Name $StorageAccountName
$sa.AzureFilesIdentityBasedAuth.ActiveDirectoryProperties | Select-Object DomainName, SamAccountName, AccountType

Необходимо проверить, что DomainName, SamAccountName и AccountType возвращают значения, и что эти значения соответствуют учетной записи AD. Эти значения можно проверить в учетной записи Active Directory, используя следующий PowerShell-скрипт.

$domainInformation = Get-ADDomain
$domainName = $domainInformation.DnsRoot
$samAccountName = $saAdObject.sAMAccountName.TrimEnd('$')
$type = if ($saAdObject.objectClass -contains "computer") { "Computer" } `
    elseif ($saAdObject.objectClass -contains "user") { "User" }

Write-Host "DomainName=$domainName, samAccountName=$samAccountName, type=$type"

Чтобы убедиться, что все свойства домена настроены правильно в учетной записи хранения, выполните следующий сценарий. Это безопасно, даже если свойства домена уже настроены правильно в учетной записи хранения.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

$domainInformation = Get-ADDomain
$domainGuid = $domainInformation.ObjectGUID.ToString()
$domainName = $domainInformation.DnsRoot
$domainSid = $domainInformation.DomainSID.Value
$forestName = $domainInformation.Forest
$netBiosDomainName = $domainInformation.DnsRoot

$saAdObject = Get-ADObject `
    -LDAPFilter "(servicePrincipalName=cifs/$StorageAccountName.file.core.windows.net)" `
    -Properties *

$saADObjectSid = $saAdObject.objectSid.Value
$samAccountName = $saAdObject.sAMAccountName.TrimEnd('$')
$type = if ($saAdObject.objectClass -contains "computer") { "Computer" } `
    elseif ($saAdObject.objectClass -contains "user") { "User" }

Set-AzStorageAccount `
    -ResourceGroupName $ResourceGroupName `
    -Name $StorageAccountName `
    -EnableActiveDirectoryDomainServicesForFile $true `
    -ActiveDirectoryDomainName $domainName `
    -ActiveDirectoryNetBiosDomainName $netBiosDomainName `
    -ActiveDirectoryForestName $forestName  `
    -ActiveDirectoryDomainGuid $domainGuid `
    -ActiveDirectoryDomainSid $domainSid `
    -ActiveDirectoryAzureStorageSid $saADObjectSid `
    -ActiveDirectorySamAccountName $samAccountName `
    -ActiveDirectoryAccountType $type

Для получения дополнительной информации см. раздел Включение проверки подлинности AD DS для Azure Files.

Включение AES-256 в объекте домена

$saAdObject = Get-ADObject `
    -LDAPFilter "(servicePrincipalName=cifs/$StorageAccountName.file.core.windows.net)" `
    -Properties *

$identity = $saAdObject.DistinguishedName

Чтобы определить тип учетной записи, проверьте AccountType значение из проверки свойств домена или выполните команду $saAdObject.objectClass. Если класс объекта имеет значение computer, используйте Set-ADComputer. Если это user, используйте Set-ADUser.

Чтобы включить шифрование AES-256 в учетной записи, выполните следующую команду.

Set-ADComputer -Identity $identity -KerberosEncryptionType "AES256"

Чтобы включить шифрование AES-256 в учетной записи входа в службу, выполните следующую команду.

Set-ADUser -Identity $identity -KerberosEncryptionType "AES256"

Обновление пароля объекта домена

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

$KeyName = "kerb1" # Could be either the first or second kerberos key, this script assumes we're refreshing the first
$KerbKeys = New-AzStorageAccountKey -ResourceGroupName $ResourceGroupName -Name $StorageAccountName -KeyName $KeyName
$KerbKey = $KerbKeys.keys | Where-Object {$_.KeyName -eq $KeyName} | Select-Object -ExpandProperty Value
$NewPassword = ConvertTo-SecureString -String $KerbKey -AsPlainText -Force

Set-ADAccountPassword -Identity $identity -Reset -NewPassword $NewPassword

Шаг 3. Подтверждение обновления AES-256

После завершения варианта 1 или варианта 2 следует очистить кэшированные билеты Kerberos на клиенте и проверить обновление путем повторного подключения к общей папке.

1. Запустите klist purge из командной строки с повышенными правами, чтобы очистить все кэшированные билеты Kerberos, которые по-прежнему используют RC4.
2. Повторно подключите файловое хранилище Azure.
3. Выполните команду klist get cifs/<storage-account-name>.file.core.windows.net , чтобы убедиться, что новый билет Kerberos использует шифрование AES-256.

Выходные данные должны отображаться AES-256-CTS-HMAC-SHA1-96 как для типа шифрования KerbTicket , так и для типа ключа сеанса, как показано ниже.

#1>     Client: user @ DOMAIN.CONTOSO.COM
        Server: cifs/<storage-account-name>.file.core.windows.net @ DOMAIN.CONTOSO.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        Start Time: 3/20/2026 23:16:32 (local)
        End Time:   3/21/2026 9:16:32 (local)
        Renew Time: 3/27/2026 23:16:32 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: <domain-controller-name>

Удостоверение пользователя, для которого ранее была назначена роль "Владелец" или "Участник", по-прежнему предоставляет доступ к ключу учетной записи хранения

Роли владельца и участника учетной записи хранения позволяют выводить список ключей учетной записи хранения. Ключ учетной записи хранения обеспечивает полный доступ к данным учетной записи хранения, включая общие папки, большие двоичные объекты, таблицы и очереди. Он также предоставляет ограниченный доступ к операциям управления Azure Files через устаревшие API управления, предоставляемые через API FileREST. При изменении назначений ролей следует учитывать, что пользователи, удаленные из ролей владельца или участника, могут продолжать иметь доступ к учетной записи хранения с помощью сохраненных ключей учетной записи хранения.

Решение 1

Вы можете легко устранить эту проблему путем ротации ключей учетной записи хранения. Рекомендуем выполнять ротацию ключей по одному, переключая доступ между ними в процессе ротации. Существует два типа совместных ключей, предоставляемых учетной записью хранения: ключи учетной записи хранения, которые обеспечивают уровень доступа суперадминистратора к данным этой учетной записи, и ключи Kerberos, которые используются как общий секрет между учетной записью хранения и контроллером домена Windows Server Active Directory, применяемы в сценариях Windows Server Active Directory.

Чтобы изменить ключи Kerberos учетной записи хранения, см. раздел "Обновление пароля удостоверения учетной записи хранения" в AD DS.

$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"

# Rotate primary key (key 1). You should switch to key 2 before rotating key 1.
New-AzStorageAccountKey `
    -ResourceGroupName $resourceGroupName `
    -Name $storageAccountName `
    -KeyName "key1"

# Rotate secondary key (key 2). You should switch to the new key 1 before rotating key 2.
New-AzStorageAccountKey `
    -ResourceGroupName $resourceGroupName `
    -Name $storageAccountName `
    -KeyName "key2"

RESOURCE_GROUP_NAME="<resource-group>"
STORAGE_ACCOUNT_NAME="<storage-account>"

# Rotate primary key (key 1). You should switch to key 2 before rotating key 1.
az storage account keys renew \
    --resource-group $RESOURCE_GROUP_NAME \
    --account-name $STORAGE_ACCOUNT_NAME \
    --key "primary"

# Rotate secondary key (key 2). You should switch to the new key 1 before rotating key 2.
az storage account keys renew \
    --resource-group $RESOURCE_GROUP_NAME \
    --account-name $STORAGE_ACCOUNT_NAME \
    --key "secondary"

Установка разрешений API для вновь созданного приложения

После включения проверки подлинности Kerberos в Microsoft Entra, необходимо явно предоставить согласие администратора для нового приложения Microsoft Entra, зарегистрированного в вашем клиенте Microsoft Entra, чтобы завершить настройку. Разрешения API можно настроить на портале Azure, выполнив следующие действия.

1. Откройте Microsoft Entra ID.
2. Выберите App registrations в левой области.
3. Выберите все приложения в правой области.
4. Выберите приложение с именем , соответствующим [учетной записи хранения] $storageAccountName.file.core.windows.net.
5. Выберите разрешения API в левой области.
6. Выберите "Добавить разрешения " в нижней части страницы.
7. Выберите "Предоставить согласие администратора" для "DirectoryName".

Ошибки, которые могут возникнуть при включении проверки подлинности Kerberos в Microsoft Entra

При включении проверки подлинности Kerberos Microsoft Entra могут возникнуть следующие ошибки.

Ошибка. Предоставление согласия администратора отключено

В некоторых случаях администратор Microsoft Entra может отключить возможность предоставления согласия администратора Microsoft Entra приложениям. Вот снимок экрана, как это выглядит на портале Azure.

Если это так, попросите администратора Microsoft Entra предоставить согласие администратора новому приложению Microsoft Entra. Чтобы найти и просмотреть администраторов, выберите роли и администраторы, а затем выберите администратора облачных приложений.

Ошибка : "Запрос на Microsoft Graph произошел сбоем с кодом BadRequest"

Причина 1. Политика управления приложениями предотвращает создание учетных данных

При включении проверки подлинности Kerberos Microsoft Entra вы можете столкнуться с этой ошибкой, если вы (или ваш администратор) настроили политику на уровне клиента или политику управления приложениями, которая:

• Применяется к корпоративному приложению "Поставщик ресурсов хранилища" (идентификатор a6aa9161-5291-40bb-8c5c-923b567bee3bприложения).
• Задает ограничение на пароли служебного принципала, которое блокирует добавление паролей или ограничивает максимальное время существования пароля менее 365,5 дней.

Чтобы устранить эту ошибку, необходимо настроить политику оскорбления, чтобы предоставить исключение корпоративному приложению "Поставщик ресурсов хранилища" (идентификатор a6aa9161-5291-40bb-8c5c-923b567bee3bприложения).

Причина 2. Приложение уже существует для учетной записи хранения

Вы также можете столкнуться с этой ошибкой, если ранее включили проверку подлинности Microsoft Entra Kerberos с помощью шагов ручного ограниченного предварительного просмотра. Для удаления существующего приложения клиент или ИТ-администратор могут запустить следующий сценарий. Выполнение этого сценария приведет к удалению старого приложения, созданного вручную, и позволит новому интерфейсу автоматически создавать и администрировать только что созданное приложение. После запуска подключения к Microsoft Graph войдите в приложение средств командной строки Microsoft Graph на устройстве и предоставьте разрешения приложению.

$storageAccount = "exampleStorageAccountName"
$tenantId = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
Install-Module Microsoft.Graph
Import-Module Microsoft.Graph
Connect-MgGraph -TenantId $tenantId -Scopes "User.Read","Application.Read.All"

$application = Get-MgApplication -Filter "DisplayName eq '${storageAccount}'"
if ($null -ne $application) {
   Remove-MgApplication -ObjectId $application.ObjectId
}

Ошибка. Срок действия пароля учетной записи службы истек в Microsoft Entra ID.

Если вы ранее включили аутентификацию Kerberos в Microsoft Entra с помощью ограниченных шагов предварительного вручного просмотра, пароль учетной записи службы для учетной записи хранения истекает каждые шесть месяцев. После истечения срока действия пароля пользователи не могут получить билеты Kerberos для доступа к общей папке.

Чтобы устранить эту проблему, у вас есть два варианта: либо заменять пароль старшего администратора службы в Microsoft Entra каждые шесть месяцев, либо выполнить следующие шаги: отключить Microsoft Entra Kerberos, удалить существующее приложение и перенастроить Microsoft Entra Kerberos.

Не забудьте сохранить свойства домена (domainName и domainGUID) перед отключением Microsoft Entra Kerberos, так как их потребуется во время перенастройки, если вы хотите настроить разрешения на уровне каталога и файлов с помощью Windows проводника. Если вы не сохранили свойства домена, вы по-прежнему можете настроить разрешения уровня каталога или файла с помощью icacls в качестве обходного решения.

1. Отключение Microsoft Entra Kerberos
2. Удаление существующего приложения
3. Перенастроить Microsoft Entra Kerberos через портал Azure

После перенастройки Microsoft Entra Kerberos новый интерфейс автоматически создает и управляет только что созданным приложением.

Ошибка 1326. Имя пользователя или пароль неверны при использовании приватного канала

Если вы подключаетесь к учетной записи хранения через частную конечную точку или приватную ссылку, используя аутентификацию Microsoft Entra Kerberos, при попытке подключить общую папку через net use или другим методом, клиенту предлагается ввести учетные данные. Вероятно, пользователь введёт свои учетные данные, но они будут отклонены.

Причина

Это связано с тем, что клиент SMB пытался использовать Kerberos, но не удалось, поэтому он возвращается к использованию проверки подлинности NTLM и Azure Files не поддерживает использование проверки подлинности NTLM для учетных данных домена. Клиент не может получить билет Kerberos в учетную запись хранения, так как полное доменное имя приватного канала не зарегистрировано в существующем приложении Microsoft Entra.

Решение

Решение — добавить полное доменное имя FQDN PrivateLink в приложение Microsoft Entra для учетной записи хранения перед монтированием файловой доли. Требуемые идентификаторыUri можно добавить в объект приложения с помощью портала Azure, выполнив следующие действия.

1. Откройте Microsoft Entra ID.

2. Выберите App registrations в левой области.

3. Выберите Все приложения.

4. Выберите приложение с именем , соответствующим [учетной записи хранения] $storageAccountName.file.core.windows.net.

5. Выберите манифест в левой области.

6. Скопируйте и вставьте существующее содержимое, чтобы у вас была дубликатная копия.

7. Измените манифест JSON. Для каждой <storageAccount>.file.core.windows.net записи добавьте соответствующую <storageAccount>.privatelink.file.core.windows.net запись. Например, если манифест имеет следующее значение для identifierUris:

   "identifierUris": [
       "api://<tenantId>/HOST/<storageaccount>.file.core.windows.net",
       "api://<tenantId>/CIFS/<storageaccount>.file.core.windows.net",
       "api://<tenantId>/HTTP/<storageaccount>.file.core.windows.net",
       "HOST/<storageaccount>.file.core.windows.net",
       "CIFS/<storageaccount>.file.core.windows.net",
       "HTTP/<storageaccount>.file.core.windows.net"
   ],
   

   Затем измените identifierUris поле следующим образом:

   "identifierUris": [
       "api://<tenantId>/HOST/<storageaccount>.file.core.windows.net",
       "api://<tenantId>/CIFS/<storageaccount>.file.core.windows.net",
       "api://<tenantId>/HTTP/<storageaccount>.file.core.windows.net",
       "HOST/<storageaccount>.file.core.windows.net",
       "CIFS/<storageaccount>.file.core.windows.net",
       "HTTP/<storageaccount>.file.core.windows.net",
   
       "api://<tenantId>/HOST/<storageaccount>.privatelink.file.core.windows.net",
       "api://<tenantId>/CIFS/<storageaccount>.privatelink.file.core.windows.net",
       "api://<tenantId>/HTTP/<storageaccount>.privatelink.file.core.windows.net",
       "HOST/<storageaccount>.privatelink.file.core.windows.net",
       "CIFS/<storageaccount>.privatelink.file.core.windows.net",
       "HTTP/<storageaccount>.privatelink.file.core.windows.net"
   ],
   

8. Просмотрите содержимое и нажмите кнопку "Сохранить ", чтобы обновить объект приложения с новым идентификаторомUris.

9. Обновите все внутренние ссылки на DNS, чтобы указать на частную ссылку.

10. Повторите попытку монтирования общей папки.

Периодические сбои проверки подлинности после изменения сети при использовании Microsoft Entra Kerberos

Симптом

Клиенты Windows, использующие проверку подлинности Kerberos Microsoft Entra для доступа к Azure Files, периодически теряют доступ после изменения сети (например, повторное подключение к VPN, смена Wi-Fi, выход из спящего режима или его завершение). Доступ может быть недоступен, пока пользователь не выйдет и не войдет в систему Windows заново.

Причина

Эта проблема вызвана известным поведением Windows, когда определенные изменения сети очищают конфигурацию кэшированного прокси-сервера KDC на клиенте. При удалении конфигурации прокси-сервера KDC клиент не может обновить билеты на обслуживание Kerberos из Microsoft Entra ID.

Хотя первичный маркер обновления пользователя (PRT) остается действительным, отсутствующая конфигурация прокси-сервера KDC предотвращает получение клиентом нового служебного билета, что приводит к сбоям проверки подлинности.

Это ограничение клиента Windows и не вызвано Azure Files или конфигурацией Microsoft Entra ID.

Решение

Option one: выход из Windows и повторный вход восстанавливает доступ, получая новый PRT, который включает обновленный билет выдачи билета (TGT) и настройку прокси KDC. Однако это приводит к плохому интерфейсу пользователя.

Вариант два. Настройте параметр групповой политики для сохранения конфигурации прокси-сервера KDC на клиенте, что снижает прерывания проверки подлинности, вызванные изменениями сети.

1. Настройте параметры прокси-сервера KDC с помощью групповой политики.

2. Откройте групповую политику управления и измените соответствующую политику.

3. Перейдите к: Административные шаблоны>Система>Kerberos>Указать прокси-серверы KDC для клиентов Kerberos

4. Выберите "Включено".

5. В разделе "Параметры" выберите "Показать ", чтобы открыть диалоговое окно "Показать содержимое".

6. Добавьте следующее сопоставление, заменив Microsoft_Entra_tenant_id идентификатором клиента Microsoft Entra. Включите пространство после https и перед закрытием /.

   Имя параметра	Ценность
   KERBEROS.MICROSOFTONLINE.COM	<https login.microsoftonline.com:443:your_Microsoft_Entra_tenant_id/kerberos />

7. Нажмите кнопку ОК, а затем — Применить.

После применения этой политики клиенты Windows сохраняют конфигурацию прокси-сервера KDC при изменении сети, уменьшая перебои в проверке подлинности.

Проверка подлинности останавливается примерно через 10 часов при использовании Microsoft Entra Kerberos

Симптом

Windows клиенты, использующие проверку подлинности Kerberos Microsoft Entra для доступа к Azure Files теряют доступ примерно через 10 часов непрерывного использования. Доступ восстанавливается только после выхода пользователя и входа в Windows.

Причина

Эта проблема вызвана известным ограничением проверки подлинности Kerberos в Microsoft Entra. Microsoft Entra ID в настоящее время не поддерживает продление билетов для выдачи билетов (TGT).

В сценариях Microsoft Entra Kerberos, TGT получается как часть Первичного маркера обновления (PRT) пользователя. Так как продление TGT не поддерживается, клиент не может обновить TGT после истечения срока его действия. После истечения срока действия TGT клиент не может получить новые служебные билеты, что вызывает сбои проверки подлинности.

Выход из системы и повторный вход в Windows решает проблему получением нового PRT, который включает новый TGT. Это известное ограничение Microsoft Entra Kerberos и не вызвано конфигурацией Azure Files.

Решение

В качестве устранения рисков клиенты могут использовать облачное доверие между локальными Active Directory Domain Services (AD DS) и Microsoft Entra ID при доступе к Azure Files.

При настройке доверия к облаку Windows клиенты получают TGT из AD DS вместо Microsoft Entra ID. Выданные AD DS TGT поддерживают продление, избегая поведения, связанного с истечением срока действия, наблюдаемого с Microsoft Entra Kerberos. Затем билет TGT, выданный AD DS, обменивается на реферальный TGT Entra, который используется для получения служебных билетов для Azure Files.

Это смягчение применяется только к клиентам, которые:

• Присоединен домен AD DS или
• Присоединено гибридное Microsoft Entra
• Клиенты, работающие только в облаке (Microsoft Entra—только), не могут использовать это решение.

Чтобы применить эту защиту, настройте доверие к облаку между локальными доменными службами AD DS и Microsoft Entra ID для доступа к Azure Files. Пошаговые инструкции см. в статье Configure cloud trust for Azure Files authentication.

Ошибка AADSTS50105

Симптом

Запрос был прерван следующей ошибкой AADSTS50105:

Администратор настроил приложение "Enterprise application name" так, чтобы оно блокировало пользователей, если им специально не предоставлен доступ к приложению. Пользователь, вошедший в систему "{EmailHidden}", заблокирован, так как он не является непосредственным членом группы с доступом и не был напрямую назначен доступ администратором. Обратитесь к администратору, чтобы назначить этому приложению доступ.

Причина

Если вы настроили "назначение необходимо" для соответствующего корпоративного приложения, вы не сможете получить билет Kerberos, и Microsoft Entra журналы входа будут отображать ошибку, даже если пользователям или группам назначены приложению.

Решение

Не выбирайте Assignment required for Microsoft Entra application для учетной записи хранения, так как мы не заполняем права в билете Kerberos, который возвращается обратно запрашивающему. Дополнительные сведения см. в разделе "Ошибка AADSTS50105 - вошедший в систему пользователь не назначен роли для приложения".

См. также

• Устранение неполадок Azure Files
• Устранение проблем с производительностью Azure Files
• Устранение неполадок подключения к Azure Files (SMB)
• Устранение общих проблем SMB с Azure Files в Linux
• Устранение общих проблем с NFS в Azure Files на Linux
• Устранение неполадок с Azure File Sync