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

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

Сводка

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

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

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

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

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

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

Решение

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

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

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

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

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

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

Примечание.

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

Решение

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

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

Причина

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

Решение

Включите Доменные службы Microsoft Entra в клиенте 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.

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

Решение

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

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

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

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

Самостоятельные диагностические действия

Сначала убедитесь, что вы выполнили действия, необходимые для включения аутентификации AD DS для Файлы Azure.

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

В-третьих, запустите командлет 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.
  5. CheckSidHasAadUser. Проверьте, синхронизирован ли пользователь AD с Microsoft Entra ID. Чтобы узнать, синхронизирован ли конкретный пользователь AD с Microsoft Entra ID, укажите -UserName и -Domain в входных параметрах. Для заданного SID проверяется, связан ли с ним пользователь Microsoft Entra ID.
  6. CheckAadUserHasSid. Проверьте, синхронизирован ли пользователь AD с Microsoft Entra ID. Чтобы узнать, синхронизирован ли конкретный пользователь AD с Microsoft Entra ID, укажите -UserName и -Domain в входных параметрах. Для данного пользователя Microsoft Entra ID проверяется его SID. Чтобы выполнить эту проверку, укажите параметр -ObjectId вместе с идентификатором объекта пользователя Microsoft Entra ID.
  7. CheckGetKerberosTicket: Попробуйте получить билет Kerberos для подключения к учетной записи хранилища. Если действительный токен Kerberos отсутствует, запустите командлет klist get cifs/storage-account-name.file.core.windows.net и проверьте код ошибки, чтобы определить причину сбоя получения билета.
  8. CheckStorageAccountDomainJoined: проверьте, включена ли проверка подлинности AD и заполнены ли свойства учетной записи AD. Если нет, включите аутентификацию AD DS в Файлы Azure.
  9. CheckUserRbacAssignment: Проверьте, назначена ли удостоверению AD правильная роль RBAC, чтобы предоставить разрешения уровня общего доступа для доступа к Файлы Azure. Если нет, настройте разрешение на уровне общего доступа. (Поддерживается в AzFilesHybrid v0.2.3+)
  10. CheckUserFileAccess. Проверьте, обладает ли учетная запись AD соответствующими разрешениями каталога или файла для доступа к Файлы Azure (списки управления доступом 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, ACL), выполните следующие командлеты 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 командлет, чтобы выполнить набор основных проверок. Этот командлет поддерживает учетные записи хранилища, настроенные для аутентификации Microsoft Entra Kerberos, в 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.
  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), необходимой для аутентификации Kerberos для Microsoft Entra. Его состояние должно иметь значение Running.
  9. CheckFiddlerProxy: проверяет, существует ли прокси-сервер Fiddler, который препятствует аутентификации Kerberos в Microsoft Entra.
  10. CheckEntraJoinType: проверяет, присоединен ли компьютер к домену Entra или присоединен к гибридному домену Entra. Это обязательное условие для аутентификации Kerberos в Microsoft Entra.

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

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

При подключении файлового ресурса Azure с помощью аутентификации Kerberos Microsoft Entra операция подключения завершается ошибкой. Сбор журналов может показать, что служебный билет 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

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

Примечание.

Шифрование AES включено по умолчанию в современных операционных системах Windows. Если вы не настроите ключ реестра SupportedEncryptionTypes, Windows автоматически согласовывает использование AES, если он доступен.

Решение

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

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

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

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

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

Подсказка

Удаление ключа восстанавливает поведение Windows по умолчанию, при котором Active Directory может автоматически согласовывать использование AES при выдаче билетов Kerberos.

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

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

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

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

Внимание

Для успешного монтирования файловых ресурсов Azure с использованием Entra Kerberos требуется AES256_HMAC_SHA1. Конфигурации, использующие только RC4 или DES, завершаются сбоем. Дополнительные сведения о ключах реестра см. в разделе Расшифровка выбора поддерживаемых типов шифрования Kerberos.

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

Симптом

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

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

Решение

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

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

Симптом

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

Причина

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

Решение

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

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

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

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

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

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

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

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

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

Решение 1

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

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

Перейдите к нужной учетной записи хранения на портале Azure. В оглавлении нужной учетной записи хранения выберите ключи доступа в заголовке "Безопасность и сеть ". В области Ключ доступа выберите Повернуть ключ над нужным ключом.

Снимок экрана: панель ключей доступа.

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

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

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

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

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

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

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

Снимок экрана: колонка

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

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

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

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

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

Чтобы устранить эту ошибку, настройте проблемную политику так, чтобы предоставить исключение корпоративному приложению "Storage Resource Provider" (идентификатор приложения 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 ID каждые шесть месяцев, либо выполнить следующие действия, чтобы отключить 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. Имя пользователя или пароль неверны при использовании приватного канала

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

Причина

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

Решение

Добавьте FQDN privateLink в приложение Entra учетной записи хранения, прежде чем подключить файловый ресурс. Требуемые идентификаторыUris можно добавить в объект приложения с помощью портала Azure и следующих действий:

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

  2. Выберите Регистрация приложений в левой области.

  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, периодически теряют доступ после изменения сети (например, повторное подключение к VPN, смена Wi-Fi, выход из спящего режима или его завершение). Доступ может быть недоступен, пока пользователь не выйдет и не войдет в систему Windows заново.

Причина

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

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

Это ограничение зависит от клиента Windows. Ни Файлы Azure, ни конфигурация 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 теряют доступ примерно через 10 часов непрерывного использования. Доступ восстанавливается только после выхода пользователя и входа в Windows.

Причина

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

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

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

Решение

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

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

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

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

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

Ошибка AADSTS50105

Симптом

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

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

Причина

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

Решение

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

См. также

  • Last updated on