Обзор аутентификации на базе идентификационных данных для доступа SMB с использованием Azure Files

Область применения: ✔️ файловые хранилища SMB Azure

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

Проверка подлинности на основе удостоверений поддерживается через SMB для клиентов Windows, Linux и MacOS. Однако в настоящее время она не поддерживается общими папками сетевой файловой системы (NFS).

Принцип работы

Файловые ресурсы Azure используют протокол Kerberos для аутентификации с источником удостоверений. Если удостоверение, связанное с пользователем или приложением, запущенным на клиенте, пытается получить доступ к данным в общих папках Azure, запрос отправляется источнику идентификации для аутентификации удостоверения. Если проверка подлинности выполнена успешно, источник идентификации возвращает билет Kerberos. Затем клиент отправляет запрос, включающий билет Kerberos, и Azure Files использует этот билет для авторизации запроса. Служба Azure Files получает только билет Kerberos, а не учетные данные доступа пользователя.

Распространенные варианты использования

Аутентификация на основе удостоверений с помощью общих папок Azure SMB может быть полезной в различных сценариях.

Замена локальных файловых серверов

Замена разбросанных по местам файловых серверов — это проблема, с которой сталкивается каждая организация во время модернизации их IT-инфраструктуры. Использование аутентификации на основе удостоверений с Azure Files обеспечивает беспрепятственную миграцию, позволяя конечным пользователям продолжать доступ к данным с теми же учетными данными.

Перенос приложений в Azure по методу lift-and-shift

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

Резервное копирование и аварийное восстановление (DR)

Если вы храните основные файлы в локальной среде, Azure Files является идеальным решением для резервного копирования и аварийного восстановления для обеспечения непрерывности бизнес-процессов. Облачные ресурсы Azure можно использовать для резервного копирования файловых серверов с сохранением дискреционных списков управления доступом (DACL) Windows. Для сценариев аварийного восстановления можно настроить опцию аутентификации для поддержки надлежащего внедрения управления доступом при переключении при отказе.

Выберите источник идентификации для учетной записи хранения

Прежде чем включить проверку подлинности на основе удостоверений в учетной записи хранения, необходимо знать, какой источник удостоверений вы собираетесь использовать. Скорее всего, у вас уже есть один, так как большинство компаний и организаций имеют определенный тип среды домена. Чтобы убедиться, обратитесь к администратору Active Directory (AD) или ИТ-администратору. Если у вас еще нет источника идентификации, его нужно будет настроить, прежде чем включить проверку подлинности на основе идентификации.

Поддерживаемые сценарии проверки подлинности

Вы можете включить аутентификацию на основе удостоверений через SMB, используя один из трех источников удостоверений: локальные доменные службы Active Directory (AD DS),доменные службы Microsoft Entra или Microsoft Entra Kerberos. Вы можете использовать только один источник удостоверений для аутентификации доступа к файлам для каждой учетной записи хранения, которая применяется ко всем файловым хранилищам в учетной записи.

• Локальные доменные службы AD DS: Учетная запись для хранения присоединена к локальным AD DS, и удостоверения из AD DS могут безопасно получить доступ к SMB Azure общим папкам с устройства, присоединенного к домену, либо устройства, постоянно связанного с контроллером домена. Локальная среда AD DS должна быть синхронизирована с идентификатором Microsoft Entra ID с помощью локального приложения Microsoft Entra Connect или облачной синхронизации Microsoft Entra Connect, упрощенного агента, который можно установить из Центра администрирования Microsoft Entra. Полный список необходимых компонентов см. в списке необходимых компонентов.

• Microsoft Entra Kerberos: Идентификатор Microsoft Entra можно использовать для проверки подлинности гибридных или облачных удостоверений (предварительная версия), позволяя конечным пользователям получать доступ к общим папкам Azure. Если вы хотите выполнить проверку подлинности гибридных удостоверений, вам потребуется существующее развертывание AD DS, которое затем синхронизируется с клиентом Microsoft Entra. См. предварительные требования.

• Доменные службы Microsoft Entra: облачные виртуальные машины, присоединенные к доменным службам Microsoft Entra, могут получить доступ к общим папкам Azure с учетными данными Microsoft Entra. В этом решении Microsoft Entra ID работает в традиционном домене Windows Server AD, который является дочерним доменом арендатора Microsoft Entra. См. предварительные требования.

Используйте следующие рекомендации, чтобы определить, какой источник идентификации следует выбрать.

• Если у вашей организации уже есть локальная служба AD и она не готова перемещать удостоверения в облако, и если ваши клиенты, виртуальные машины и приложения присоединены к домену или имеют беспрепятственное сетевое подключение к этим контроллерам домена, выберите AD DS.

• Если некоторые или все клиенты не имеют единого сетевого подключения к AD DS или если вы храните профили FSLogix в общих папках Azure для виртуальных машин, присоединенных к Microsoft Entra, выберите Microsoft Entra Kerberos.

• Если у вас есть локальная Active Directory, но планируется перевести приложения в облако, и вы хотите, чтобы удостоверения существовали как в локальной среде, так и в облаке (гибридном), выберите Microsoft Entra Kerberos.

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

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

Включение источника удостоверений

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

AD DS

Для проверки подлинности AD DS можно разместить контроллеры домена AD на виртуальных машинах Azure или локально. В любом случае ваши клиенты должны иметь беспрепятственное сетевое подключение к контроллеру домена, поэтому они должны находиться в корпоративной сети или виртуальной сети (VNET) вашей доменной службы. Мы рекомендуем присоединять клиентские машины или виртуальные машины к домену, чтобы пользователи не должны были вводить свои учетные данные каждый раз при доступе к ресурсу.

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

Чтобы включить проверку подлинности AD DS, сначала ознакомьтесь с обзором локальной службы аутентификации доменных служб Active Directory по протоколу SMB для общих папок Azure, а затем см раздел Включение проверки подлинности AD DS для общих папок Azure.

Microsoft Entra Kerberos

Включение и настройка идентификатора Microsoft Entra для проверки подлинности гибридных или облачных удостоверений (предварительная версия) позволяет пользователям Microsoft Entra получать доступ к общим папкам Azure с помощью проверки подлинности Kerberos. Эта конфигурация использует Microsoft Entra ID для выдачи билетов Kerberos, обеспечивающих доступ к общей папке с помощью стандартного в отрасли протокола SMB. Это означает, что конечные пользователи могут получить доступ к общим папкам Azure, не требуя сетевого подключения к контроллерам домена.

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

Чтобы включить проверку подлинности Microsoft Entra Kerberos, см. раздел Включение проверки подлинности Microsoft Entra Kerberos в файловом хранилище Azure.

Эту функцию можно также использовать для хранения профилей FSLogix в общих папках Azure для виртуальных машин, присоединенных к Microsoft Entra. Дополнительные сведения см. в разделе "Создание контейнера профиля с Azure Files и Microsoft Entra ID".

Доменные службы Microsoft Entra

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

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

• Для представления учетной записи хранения не требуется создать удостоверение в доменных службах Microsoft Entra. Это выполняется процессом включения в фоновом режиме.

• Все пользователи, которые существуют в Microsoft Entra ID, могут быть аутентифицированы и авторизованы. Пользователи могут быть исключительно облачными или гибридными. Синхронизация с идентификатором Microsoft Entra с доменными службами Microsoft Entra управляется платформой, не требуя настройки пользователя. Однако клиент должен быть присоединен к домену, размещенному в службах доменов Microsoft Entra. Устройство не может быть присоединено к Microsoft Entra или зарегистрировано. Доменные службы Microsoft Entra не поддерживают присоединение к домену устройств, не связанных с Azure (например, пользовательские ноутбуки, рабочие станции, виртуальные машины в других облаках и т. д.), домен которого размещен службами доменных технологий Microsoft Entra. Однако можно подключить общую папку из клиента, не присоединенного к домену, предоставив явные учетные данные, такие как DOMAINNAME\username или используя полное доменное имя (username@FQDN).

Чтобы включить проверку подлинности доменных служб Microsoft Entra, см. статью «Включение проверки подлинности доменных служб Microsoft Entra на Azure Files».

См. также

• Обзор авторизации файлов Azure и управления доступом
• Обзор проверки подлинности Kerberos