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

  • Статья

В этой статье перечислены распространенные проблемы при использовании общих папок Azure SMB с проверкой подлинности на основе удостоверений. Он также предоставляет возможные причины и способы устранения этих проблем. Проверка подлинности на основе удостоверений в настоящее время не поддерживается для общих папок Azure NFS.

Сфера применения

Тип общей папки SMB NFS
Общие папки уровня "Стандартный" (GPv2), LRS/ZRS
Общие папки уровня "Стандартный" (GPv2), GRS/GZRS
Общие папки уровня "Премиум" (FileStorage), LRS/ZRS

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

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

Клиент не имеет необходимых привилегий.

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

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

Решение

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

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

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

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

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

Если конечные пользователи получают доступ к общей папке Azure с помощью доменные службы Active Directory (AD DS) или Доменные службы Microsoft Entra проверки подлинности, доступ к общей папке завершается ошибкой "Доступ запрещен", если разрешения на уровне общего ресурса неверны.

Примечание.

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

Решение

Убедитесь, что разрешения настроены правильно:

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

Причина

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

Решение

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

Не удается подключить общие папки Azure с учетными данными AD

Шаги самостоятельного диагностика

Во-первых, убедитесь, что вы выполнили действия по включению проверки подлинности Файлы Azure AD DS.

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

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

$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 есть объект, представляющий учетную запись хранения и имеющий правильное имя субъекта-службы (имя субъекта-службы). Если имя субъекта-службы настроено неправильно, выполните Set-AD командлет, возвращенный в командлете отладки, чтобы настроить имя субъекта-службы.
  3. CheckDomainJoined: проверьте, присоединен ли клиентский компьютер к домену AD. Если компьютер не присоединен к домену AD, см. инструкции по присоединению компьютера к домену .
  4. CheckPort445Connectivity: убедитесь, что порт 445 открыт для подключения SMB. Если порт 445 не открыт, обратитесь к средству устранения неполадок AzFileDiagnostics, чтобы узнать о проблемах с подключением к Файлы Azure.
  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.
  9. CheckUserRbacAssignment: проверьте, имеет ли удостоверение AD правильное назначение роли RBAC для предоставления разрешений на доступ к Файлы Azure на уровне общего ресурса. Если нет, настройте разрешение на уровне общего доступа. (Поддерживается в AzFilesHybrid версии 0.2.3+
  10. CheckUserFileAccess: проверьте, имеет ли удостоверение AD соответствующее разрешение на доступ к Файлы Azure каталогу или файлу (списки управления доступом Windows). Если нет, настройте разрешение на уровне каталога или файла. Чтобы запустить эту проверка, необходимо указать -FilePath параметр вместе с путем к подключенному файлу, к которому требуется отладить доступ. (Поддерживается в AzFilesHybrid версии 0.2.3+
  11. CheckAadKerberosRegistryKeyIsOff: проверьте, отключен ли раздел реестра Kerberos Microsoft Entra. Если ключ включен, выполните команду reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 0 из командной строки с повышенными привилегиями, чтобы отключить ее, а затем перезагрузите компьютер. (Поддерживается в AzFilesHybrid версии 0.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

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

Признак

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

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

Решение

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

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

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

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

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

Эта ошибка, скорее всего, вызвана синтаксической ошибкой в команде Join-AzStorageAccountforAuth . Проверьте команду на наличие ошибок или синтаксических ошибок и убедитесь, что установлена последняя версия модуля AzFilesHybrid (https://github.com/Azure-Samples/azure-files-samples/releases).

Файлы Azure поддержка локальной проверки подлинности AD DS для шифрования Kerberos AES-256

Файлы Azure поддерживает шифрование Kerberos AES-256 для проверки подлинности AD DS, начиная с модуля AzFilesHybrid версии 0.2.2. AES-256 — это рекомендуемый метод шифрования, который используется по умолчанию, начиная с модуля AzFilesHybrid версии 0.2.5. Если вы включили проверку подлинности AD DS с версией модуля ниже версии 0.2.2, необходимо скачать последний модуль AzFilesHybrid и запустить PowerShell ниже. Если вы еще не включили проверку подлинности AD DS в учетной записи хранения, следуйте этим рекомендациям.

Важно!

Если ранее вы использовали шифрование RC4 и обновили учетную запись хранения для использования AES-256, следует запустить klist purge на клиенте, а затем повторно подключить общую папку, чтобы получить новые билеты Kerberos с AES-256.

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

Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -StorageAccountName $StorageAccountName

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

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

Роли владельца и участника учетной записи хранения предоставляют возможность перечислять ключи учетной записи хранения. Ключ учетной записи хранения обеспечивает полный доступ к данным учетной записи хранения, включая общие файловые ресурсы, контейнеры BLOB-объектов, таблицы и очереди, а также ограниченный доступ к операциям управления Файлы 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.

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

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

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

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

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

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

Ошибка: "Сбой запроса на Azure AD Graph с кодом BadRequest"

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

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

  1. Вы используете бета-версию или предварительную версию функций политик управления приложениями.
  2. Вы (или администратор) настроили политику на уровне клиента , которая:
    • Не имеет даты начала или даты начала до 1 января 2019 г.
    • Устанавливает ограничение на пароли субъектов-служб, которое запрещает пользовательские пароли или задает максимальное время существования пароля менее 365,5 дней.

В настоящее время для этой ошибки нет обходного решения.

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

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

$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 не поддерживает использование проверки подлинности NTLM для учетных данных домена. Клиент не может получить билет Kerberos в учетную запись хранения, так как полное доменное имя приватного канала не зарегистрировано ни в одном существующем приложении Microsoft Entra.

Решение

Решение заключается в добавлении полного доменного имени privateLink в приложение Microsoft 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. Повторите попытку подключения общей папки.

Ошибка AADSTS50105

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

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

Причина

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

Решение

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

См. также

Свяжитесь с нами для получения помощи

Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.