Вопрос или проблема
Я планирую мигрировать с Azure SQL VMs на Azure SQL Managed Instance и у меня есть несколько вопросов, связанных с интеграцией этого с локальным доменом Windows Active Directory.
У нас есть несколько устаревших приложений, работающих на отдельных Windows VMs. Эти VMs присоединены к домену Windows AD.
Приложения настроены на работу как службы в Windows, и мы используем опцию Log on as для службы, чтобы предоставить учетные данные для учетной записи AD, под которой будет работать служба. Приложение должно аутентифицироваться в SQL базе данных, используя ту же учетную запись AD, под которой работает приложение. Мы не хотим предоставлять учетные данные в строке подключения SQL, поэтому в настоящее время используем Trusted_Connection = true.
При миграции на SQL MI у нас нет доступа к базовому хосту, поэтому мы не можем присоединить хост к нашему домену AD. Исходя из некоторых документов, которые я видел от Microsoft, мы можем настроить поток, основанный на доверии, чтобы все еще использовать учетные записи Windows AD для аутентификации в SQL MI.
-
В этом документе говорится, что
"вы превратите свой арендатор Microsoft Entra в независимую сферу Кербероса и создадите входящее доверие в домене клиента.". Будет ли наш арендатор Entra преобразован в сферу Кербероса, и если да, то можно ли это сделать обратимым? -
В этом документе указаны различные режимы метаданных аутентификации SQL. Если я использую
Paired, нужно ли мне все еще синхронизировать пользователя Windows AD с Entra ID? -
Преимущество режима
Pairedзаключается в том, что я могу иметь независимых пользователей/группы в Entra ID, которые не найдены в Windows AD, и разрешить как пользователям/группам Entra ID, так и пользователям/группам Windows AD входить в SQL MI? -
В этом документе мне нужно будет настроить GPO для прокси KDC. Могу ли я настроить это для конкретных VMs или это будет применяться ко всем VMs, присоединенным к домену?
-
Когда мое приложение работает и пытается аутентифицироваться в SQL MI, как работает поток аутентификации? Приложение пытается аутентифицироваться к ресурсу SQL MI, и затем, поскольку я использую режим метаданных аутентификации SQL Paired, знает ли SQL MI, как найти установленное ранее доверие? Я немного запутался, как именно работает весь этот поток аутентификации.
-
Мне нужно выполнить
CREATE LOGIN [DOMAIN\USER] FROM WINDOWSв SQL MI? Это также помогает в потоке аутентификации для определения, является ли пользователь из Entra ID или Windows AD в моем предыдущем вопросе?
Ответ или решение
Azure SQL Managed Instance и Windows аутентификация
В условиях миграции с Azure SQL VMs на Azure SQL Managed Instance (SQL MI) с интеграцией с локальным доменом Windows Active Directory, важно учесть множество аспектов, связанных с аутентификацией и настройками безопасности. Давайте подробно рассмотрим ваши вопросы.
-
Преобразование Microsoft Entra в Керберос-реальность и его обратимость:
Согласно документации Microsoft, ваша учетная запись Entra будет использоваться для создания входящей доверительной линии с доменом Active Directory. Важно отметить, что Microsoft Entra не «превращается» в Керберос-реальность; вместо этого, Entra будет действовать как управляющий центр для аутентификации, который использует протокол Kerberos. Этот процесс не является необратимым, но изменения могут потребовать значительных усилий для восстановления прежнего состояния. Если вам потребуется отменить настройки, потребуется внимательно подойти к процедуре вывода из эксплуатации создаваемого доверия. -
Необходимость синхронизации пользователей Windows AD с Entra ID при использовании режима
Paired:
В режимеPairedсинхронизация пользователей Windows AD с Entra ID не является обязательной, если все пользователи, которым требуется доступ к SQL MI, уже существуют в Entra ID. Если вы хотите, чтобы пользователи, находящиеся только в Windows AD без соответствующей записи в Entra, имели доступ, вам в любом случае потребуется создать соответствующие учетные записи в Entra ID. -
Преимущества режима
Paired:
Данный режим действительно позволяет иметь независимых пользователей и группы в Entra ID, которые не обязательно соответствуют Windows AD. Это увеличивает гибкость и упрощает управление аутентификацией, поскольку вы можете комбинировать учетные данные Entra ID и Windows AD для доступа к SQL MI. Это полезно, если вы планируете внедрение гибридных сценариев и хотите учитывать пользователей из обеих систем. -
Настройка GPO для KDC Proxy:
Политики группы (GPO) можно настроить на уровне OU (Organizational Unit), что позволяет вам применять политику только для определенных виртуальных машин, а не для всех доменных подключенных устройств. Это важно для снижения риска и управления конфигурацией безопасности. -
Процесс аутентификации приложения к SQL MI:
Когда ваше приложение пытается аутентифицироваться к SQL MI, оно сначала отправляет учетные данные на ресурс SQL MI. Если используется режимPaired, SQL MI проверяет доверительные отношения, установленное между вашим локальным AD и Entra ID, что позволяет ему определить, какой метод аутентификации следует применять. Этот процесс предполагает использование Kerberos для аутентификации, что обеспечивает безопасность и упрощает управление. -
Команда
CREATE LOGIN [DOMAIN\USER] FROM WINDOWS:
Вы действительно должны создать логин для каждого пользователя из Windows AD в SQL MI. Это является частью процесса, который позволяет SQL MI различать учетные записи из Entra ID и Windows AD. Когда SQL MI обрабатывает аутентификацию, он будет использовать настройки, определённые для пользователей и групповых логинов, чтобы определить, подходит ли аутентификация под локальное AD или Entra ID.
Заключение
Переход с Azure SQL VMs на Azure SQL Managed Instance требует тщательной настройки и понимания процессов аутентификации. Ознакомившись с этими аспектами, вы сможете обеспечить безопасный доступ к вашим базам данных, сохраняя при этом необходимые бизнес-процессы. Настройка аутентификации требует времени и планирования, но результат обеспечит защищенное и эффективное взаимодействие между вашими приложениями и базами данных.