Поделиться через

Устранение неполадок проверки подлинности на основе удостоверений и авторизации Файлы 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".

Решение

Проверьте правильность настройки разрешений.

  • домен Active Directory службы (AD DS) см. раздел "Назначение разрешений на уровне общего ресурса".

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

  • Доменные службы Microsoft Entra. См. статью Назначение разрешений на уровне общей папки.

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

Причина

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

Решение

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

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

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

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

Во вторых, попробуйте подключить файловый ресурс 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, возвращенный в командлете отладки, чтобы настроить правильное имя SPN.
  3. CheckDomainJoined: убедитесь, что клиентский компьютер присоединен к AD. Если компьютер не присоединен к AD, обратитесь к инструкциям по присоединению компьютера к домену .
  4. CheckPort445Connectivity: проверьте, открыт ли порт 445 для подключения SMB. Если порт 445 не открыт, обратитесь к средству устранения неполадок AzFileDiagnostics для проблем с подключением с Файлы Azure.
  5. CheckSidHasAadUser: проверьте, синхронизирован ли пользователь AD с идентификатором Microsoft Entra. Если вы хотите узнать, синхронизирован ли конкретный пользователь AD с идентификатором Microsoft Entra, можно указать -UserName и -Domain в входных параметрах. Для заданного идентификатора безопасности он проверяет, связан ли пользователь Microsoft Entra.
  6. CheckAadUserHasSid: проверьте, синхронизирован ли пользователь AD с идентификатором Microsoft Entra. Если вы хотите узнать, синхронизирован ли конкретный пользователь AD с идентификатором Microsoft Entra, можно указать -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 соответствующее разрешение на доступ к каталогу или файлу (ACL Windows) для доступа к Файлы Azure. Если нет, настройте разрешение на уровне каталога или файла. Чтобы выполнить эту проверку, необходимо указать -FilePath параметр, а также путь к подключенному файлу, к которому требуется выполнить отладку доступа. (Этот командлет поддерживается в AzFilesHybrid версии 0.2.3+).
  11. CheckAadKerberosRegistryKeyIsOff: проверьте, отключен ли раздел реестра Microsoft Entra Kerberos. Если ключ включен, запустите 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:к общей папке и хотите выполнить проверку, связанную с разрешениями на уровне файлов (ACL 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

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

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

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

$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). Если имя субъекта-службы настроено неправильно, отключите и повторно включите проверку подлинности Entra Kerberos в учетной записи хранения.
  4. CheckRegKey: проверьте, включен ли CloudKerberosTicketRetrieval раздел реестра. Этот раздел реестра необходим для проверки подлинности Entra Kerberos.
  5. CheckRealmMap: проверьте, настроен ли пользователь любые сопоставления областей, которые будут присоединять учетную запись к другой области Kerberos, чем KERBEROS.MICROSOFTONLINE.COM.
  6. CheckAdminConsent: проверьте, предоставлено ли субъекту-службе Entra согласие администратора для разрешений Microsoft Graph, необходимых для получения билета Kerberos.
  7. CheckWinHttpAutoProxySvc: проверяет наличие службы автоматического обнаружения веб-прокси WinHTTP (WinHttpAutoProxySvc), необходимой для проверки подлинности Microsoft Entra Kerberos. Его состояние должно иметь значение Running.
  8. CheckIpHlpScv: проверьте наличие вспомогательной службы IP-адресов (iphlpsvc), необходимой для проверки подлинности Microsoft Entra Kerberos. Его состояние должно иметь значение Running.
  9. CheckFiddlerProxy: проверьте, существует ли прокси-сервер Fiddler, который предотвращает проверку подлинности Microsoft Entra Kerberos.
  10. CheckEntraJoinType: проверьте, присоединен ли компьютер к домену Entra или присоединен к гибридному домену Entra. Это необходимое условие для проверки подлинности Microsoft Entra Kerberos.

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

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

Симптом

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

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

Решение

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

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

Симптом

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

Причина

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

Решение

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

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

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

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

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

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

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

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

Файлы Azure поддерживает шифрование AES-256 Kerberos для проверки подлинности 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. Если вы не хотите повторно создавать оба пароля, не требуется повернуть обратно.

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

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

Решение 1

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

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

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

Снимок экрана: панель

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

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

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

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

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

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

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

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

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

Ошибка: "Запрос к Azure AD Graph завершился сбоем с кодом BadRequest"

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

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

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

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

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

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

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