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


Устранение неполадок с проверкой подлинности и авторизацией на основе удостоверений в Службе файлов 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 tenant-id"

Причина

Ошибка 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 командлет, возвращенный в командлете отладки, чтобы настроить имя субъекта-службы.
  3. CheckDomainJoined: проверьте, присоединен ли клиентский компьютер к домену AD. Если компьютер не присоединен к домену AD, см. инструкции по присоединению компьютера к домену .
  4. CheckPort445Connectivity: проверьте, открыт ли порт 445 для подключения SMB. Если порт 445 не открыт, обратитесь к средству устранения неполадок AzFileDiagnostics , чтобы узнать о проблемах с подключением к службе "Файлы Azure".
  5. CheckSidHasAadUser: проверьте, синхронизирован ли вошедший в систему пользователь AD с идентификатором Microsoft Entra. Если вы хотите узнать, синхронизирован ли конкретный пользователь AD с идентификатором Microsoft Entra ID, можно указать -UserName и -Domain во входных параметрах. Для заданного идентификатора безопасности проверяется, связан ли пользователь Microsoft Entra.
  6. CheckAadUserHasSid: проверьте, синхронизирован ли вошедший в систему пользователь AD с идентификатором Microsoft Entra. Если вы хотите узнать, синхронизирован ли конкретный пользователь 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 соответствующее разрешение на доступ к файлам или каталогу (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:, и вы хотите выполнить только проверку, связанную с разрешениями на уровне файлов (списки управления доступом 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.

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

Не удается настроить разрешения на уровне каталогов и файлов (списки управления доступом 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).

Поддержка локальной проверки подлинности 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. Нет необходимости в обратном повороте, если вы не хотите повторно создать оба пароля.

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

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

Возможные ошибки при включении проверки подлинности 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 новый интерфейс будет автоматически создавать только что созданное приложение и управлять им.

Если вы подключаетесь к учетной записи хранения через частную конечную точку или приватный канал с помощью проверки подлинности 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.