Настройка единого входа на основе Kerberos из службы Power BI в локальные источники данных

Включение единого входа (SSO) позволяет легко обновлять отчёты и панели мониторинга Power BI, получая данные из локальных источников, и при этом учитывая разрешения на уровне пользователя, настроенные в этих источниках. Используйте ограниченную делегацию Kerberos, чтобы обеспечить бесшовное подключение с помощью единого входа.

В этой статье описаны действия, необходимые для настройки единого входа на основе Kerberos из службы Power BI в локальные источники данных.

Предпосылки

Для правильной работы ограниченного делегирования в Kerberos необходимо настроить несколько элементов, включая имена главных служб (SPN) и параметры делегирования для учетных записей сервисов.

Замечание

Использование псевдонимов DNS с единым входом не поддерживается.

Структура конфигурации

Ниже приведены шаги, необходимые для настройки единой системы входа для шлюза.

1. Выполните все действия, описанные в разделе 1. Базовая конфигурация.

2. В зависимости от среды Active Directory и используемых источников данных может потребоваться выполнить некоторые или все конфигурации, описанные в разделе 2. Конфигурация для конкретной среды.

   Ниже перечислены возможные сценарии, для которых может потребоваться дополнительная конфигурация:

   Сценарий	Перейти к
   Ваша среда Active Directory является защищенной.	Добавление учетной записи службы шлюза в группу авторизации и доступа Windows
   Учетная запись службы шлюза и учетные записи пользователей, от имени которых будет выступать шлюз, находятся в отдельных доменах или лесах.	Добавление учетной записи службы шлюза в группу авторизации и доступа Windows
   У вас не настроена синхронизация учетных записей пользователей с помощью Microsoft Entra Connect, и имя пользователя (UPN), используемое в Power BI для пользователей, не соответствует имени пользователя в вашей локальной среде Active Directory.	Настройте параметры конфигурации сопоставления пользователей на машине шлюза
   Вы планируете использовать источник данных SAP HANA с единым входом.	Выполнение действий по настройке для конкретного источника данных
   Вы планируете использовать источник данных SAP BW с единым входом (SSO).	Выполнение действий по настройке для конкретного источника данных
   Вы планируете использовать источник данных Teradata с использованием SSO.	Выполнение действий по настройке для конкретного источника данных

3. Проверьте вашу конфигурацию, как описано в разделе 3: Валидируйте конфигурацию, чтобы убедиться, что SSO настроен правильно.

Раздел 1. Базовая конфигурация

Шаг 1. Установка и настройка локального шлюза данных Майкрософт

Локальный шлюз данных поддерживает локальное обновление и принятие настроек существующих шлюзов.

Шаг 2. Получение прав администратора домена для настройки SPNs (SetSPN) и параметров ограниченного делегирования Kerberos.

Чтобы настроить параметры делегирования субъектов-служб и Kerberos, администратор домена не должен предоставлять права кому-то, у кого нет прав администратора домена. В следующем разделе мы подробно рассмотрим рекомендуемые действия по настройке.

Шаг 3. Настройка учетной записи службы шлюза

Ниже приведена необходимая конфигурация, если у вас не настроена настройка Microsoft Entra Connect и синхронизация учетных записей пользователей. В этом случае рекомендуется вариант B.

Вариант A: Запустите службу Windows шлюза от имени учетной записи домена с SPN

В стандартной установке шлюз запускается как учетная запись локальной службы компьютера, NT Service\PBIEgwService.

Чтобы включить ограниченное делегирование Kerberos, шлюз должен работать в качестве учетной записи домена, если только экземпляр Microsoft Entra уже синхронизирован с локальным экземпляром Active Directory (с помощью Microsoft Entra DirSync/Connect). Сведения о переключении на учетную запись домена см. в статье об изменении учетной записи службы шлюза.

Настройте главное имя службы (SPN) для учетной записи службы шлюза

Сначала определите, создан ли SPN для учетной записи домена, используемой в качестве сервисной учетной записи шлюза.

1. В качестве администратора домена запустите оснастку Active Directory Users and Computers в консоль управления Microsoft Management Console (MMC).

2. В левой области щелкните правой кнопкой мыши доменное имя, выберите "Найти", а затем введите имя учетной записи службы шлюза.

3. В результатах поиска щелкните правой кнопкой мыши учетную запись службы шлюза и выберите "Свойства".

4. Если вкладка "Делегирование" отображается в диалоговом окне "Свойства", то SPN уже создан, и вы можете перейти к настройке ограниченного делегирования Kerberos.

5. Если в диалоговом окне "Свойства" отсутствует вкладка "Делегирование", вы можете вручную создать SPN в учетной записи, чтобы активировать эту функцию. Используйте средство setspn, которое поставляется с Windows (необходимы права администратора домена для создания SPN).

   Например, предположим, что учетная запись службы шлюза — Contoso\GatewaySvc , а служба шлюза выполняется на компьютере с именем MyGatewayMachine. Чтобы задать SPN для учетной записи службы шлюза, выполните следующую команду:

   setspn -S gateway/MyGatewayMachine Contoso\GatewaySvc

   Вы также можете задать имя главного объекта службы с помощью оснастки MMC пользователи и компьютеры Active Directory.

Вариант B. Настройка компьютера для Microsoft Entra Connect

Если Microsoft Entra Connect настроен и учетные записи пользователей синхронизируются, служба шлюза не должна выполнять локальные поиски Microsoft Entra во время выполнения. Вместо этого можно просто использовать идентификатор безопасности локальной службы (SID) для службы шлюза, чтобы завершить всю необходимую конфигурацию в идентификаторе Microsoft Entra. Действия по настройке ограниченного делегирования Kerberos, описанные в этой статье, совпадают с инструкциями по настройке, необходимыми в контексте Microsoft Entra. Они применяются к объекту компьютера шлюза (как определено идентификатором безопасности локальной службы) в Microsoft Entra ID, а не к учетной записи домена. Идентификатор безопасности локальной службы для NT SERVICE/PBIEgwService выглядит следующим образом:

S-1-5-80-1835761534-3291552707-3889884660-1303793167-3990676079

Чтобы создать SPN для этого SID для компьютера Power BI Gateway, необходимо выполнить следующую команду из административной командной строки (замените <COMPUTERNAME> именем компьютера Power BI Gateway).

SetSPN -s HTTP/S-1-5-80-1835761534-3291552707-3889884660-1303793167-3990676079 <COMPUTERNAME>

Замечание

В зависимости от параметров локальной безопасности может потребоваться добавить учетную запись службы шлюза NT SERVICE\PBIEgwService в группу локальных администраторов на компьютере шлюза, а затем перезапустить службу шлюза в приложении шлюза. Этот параметр не поддерживается для сценариев с несколькими шлюзами, так как Active Directory применяет уникальные служебные имена субъектов во всем лесу. Для этих сценариев используйте вместо этого параметр A .

Шаг 4. Настройка ограниченного делегирования Kerberos

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

Требуются следующие учетные записи служб:

• Учетная запись службы шлюза: пользователь, представляющий шлюз в Active Directory, с SPN, настроенным на шаге 3.
• Учетная запись службы источника данных: пользователь службы, представляющий источник данных в Active Directory, с идентификатором субъекта-службы (SPN), сопоставленным с источником данных.

Замечание

Учетные записи службы шлюза и источника данных должны быть разделены. Ту же учетную запись службы нельзя использовать для представления шлюза и источника данных.

В зависимости от того, какой подход вы хотите использовать, перейдите к одному из следующих разделов. Не завершайте оба раздела.

• Вариант A: Ограниченное делегирование Kerberos стандартное. Это рекомендация по умолчанию для большинства сред.
• Вариант B. Ограниченное делегирование Kerberos на основе ресурсов. Это необходимо, если источник данных принадлежит к домену, отличному от вашего шлюза.

Вариант A: Стандартное ограниченное делегирование Kerberos

Теперь мы установим параметры делегирования для учетной записи службы шлюза. Существует несколько средств, которые можно использовать для выполнения этих действий. Здесь мы будем использовать оснастку MMC Active Directory Users and Computers для администрирования и публикации информации в каталоге. Он доступен по умолчанию на контроллерах домена; на других компьютерах его можно включить с помощью конфигурации компонентов Windows.

Необходимо настроить ограниченное делегирование Kerberos с переходом протокола. При ограниченном делегировании необходимо явным образом определить, какие службы позволяют шлюзу предоставлять делегированные учетные данные. Например, только SQL Server или сервер SAP HANA принимает вызовы делегирования из учетной записи службы шлюза.

В этом разделе предполагается, что вы уже настроили служебные имена субъектов для основных источников данных, таких как SQL Server, SAP HANA, SAP BW, Teradata или Spark. Чтобы узнать, как настроить эти SPN сервера источника данных, обратитесь к технической документации по соответствующему серверу базы данных и найдите раздел Какой SPN требуется вашему приложению? в записи блога Мой контрольный список Kerberos.

Предполагаем, что в следующих шагах рассматривается локальная среда с двумя компьютерами в одном домене: компьютером шлюза и сервером базы данных, на котором работает SQL Server и который уже настроен для единого входа на основе Kerberos. Шаги можно применить для одного из других поддерживаемых источников данных, если источник данных уже настроен для единого входа на основе Kerberos. В этом примере мы будем использовать следующие параметры:

• Домен Active Directory (Netbios): Contoso
• Имя компьютера шлюза: MyGatewayMachine
• Учетная запись службы шлюза: Contoso\GatewaySvc
• Имя компьютера источника данных SQL Server: TestSQLServer
• Учетная запись службы источника данных SQL Server: Contoso\SQLService

Вот как настроить параметры делегирования:

1. Имея права администратора домена, откройте оснастку MMC Active Directory - пользователи и компьютеры.

2. Щелкните правой кнопкой мыши учетную запись службы шлюза (Contoso\GatewaySvc) и выберите "Свойства".

3. Перейдите на вкладку делегирования.

4. Выберите «Доверять этому компьютеру для делегирования только указанным службам»>Используйте любой протокол проверки подлинности.

5. В разделе "Службы", в которых эта учетная запись может представлять делегированные учетные данные, нажмите кнопку "Добавить".

6. В новом диалоговом окне выберите "Пользователи" или "Компьютеры".

7. Введите учетную запись службы для источника данных и нажмите кнопку "ОК".

   Например, источник данных SQL Server может иметь учетную запись службы, например Contoso\SQLService. Для этой учетной записи уже должен быть установлен соответствующий SPN для источника данных.

8. Выберите SPN, который вы создали для сервера базы данных.

   В нашем примере SPN начинается с MSSQLSvc. Если вы добавили и полное доменное имя (FQDN), и SPN NetBIOS для службы базы данных, выберите оба. Возможно, вы увидите только один.

9. Нажмите ОК.

   Теперь вы должны увидеть SPN в списке сервисов, которым учетная запись службы шлюза может предоставить делегированные учетные данные.

   

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

Вариант B. Ограниченное делегирование Kerberos на основе ресурсов

Для включения подключения единого входа (SSO) для Windows Server 2012 и более поздних версий используется делегирование Kerberos с ограничениями на основе ресурсов. Этот тип делегирования позволяет внешним и серверным службам находиться в разных доменах. Чтобы всё работало, домен бэкенд-службы должен доверять домену фронтенд-службы.

В следующих шагах мы предполагаем, что среда локальная и включает два компьютера в разных доменах: один является шлюзом, а другой — сервером базы данных, работающим под управлением SQL Server, который уже настроен для единого входа на основе Kerberos. Эти шаги можно применить для одного из других поддерживаемых источников данных, если источник данных уже настроен для SSO на основе Kerberos. В этом примере мы будем использовать следующие параметры:

• Интерфейсный домен Active Directory (Netbios): ContosoFrontEnd
• Домен серверной части Active Directory (Netbios): ContosoBackEnd
• Имя компьютера шлюза: MyGatewayMachine
• Учетная запись службы шлюза: ContosoFrontEnd\GatewaySvc
• Имя компьютера источника данных SQL Server: TestSQLServer
• Учетная запись службы источника данных SQL Server: ContosoBackEnd\SQLService

Выполните следующие действия по настройке:

1. Используйте оснастку MMC для Управление пользователями и компьютерами Active Directory на контроллере домена ContosoFrontEnd и проверьте, что настройки делегирования не применяются для учетной записи службы шлюза.

   

2. Используйте пользователи и компьютеры Active Directory на контроллере домена для домена ContosoBackEnd и убедитесь, что параметры делегирования не применяются к учетной записи серверной службы.

   

3. На вкладке редактора атрибутов свойств учетной записи убедитесь, что атрибут msDS-AllowedToActOnBehalfOfOtherIdentity не задан.

   

4. В Active Directory Users and Computers создайте группу на контроллере домена для домена ContosoBackEnd . Добавьте учетную запись службы шлюза GatewaySvc в группу ResourceDelGroup .

   Чтобы добавить пользователей из доверенного домена, эта группа должна иметь область локального домена.

5. Откройте командную строку и выполните следующие команды в контроллере домена contosoBackEnd , чтобы обновить атрибут msDS-AllowedToActOnBehalfOfOtherIdentity внутренней учетной записи службы:

   $c = Get-ADGroup ResourceDelGroup
   Set-ADUser SQLService -PrincipalsAllowedToDelegateToAccount $c
   

6. В Active Directory Users and Computers убедитесь, что обновление отражено на вкладке редактора атрибутов в свойствах учетной записи серверной службы.

Шаг 5. Включение шифрования AES в учетных записях служб

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

Замечание

Если в учетных записях служб существуют определенные типы шифрования, обратитесь к администратору Active Directory, так как после выполнения приведенных ниже действий существующие значения типов шифрования будут перезаписаны, и это может нарушить работу клиентов.

1. С правами администратора домена откройте оснастку консоли MMC "Пользователи и компьютеры Active Directory".

2. Щелкните правой кнопкой мыши учетную запись шлюза или службы источника данных и выберите "Свойства".

3. Перейдите на вкладку Учетная запись.

4. В разделе "Параметры учетной записи" включите хотя бы один (или оба) из следующих параметров. Обратите внимание, что для всех учетных записей служб необходимо включить одинаковые параметры.

   • Эта учетная запись поддерживает шифрование Kerberos AES 128-разрядной версии
   • Эта учетная запись поддерживает шифрование Kerberos AES 256-разрядной версии

Замечание

Если вы не уверены, какую схему шифрования следует использовать, обратитесь к администратору Active Directory.

Шаг 6. Предоставление прав локальной политики учетной записи службы шлюза на компьютере шлюза

Наконец, на компьютере, на котором запущена служба шлюза (MyGatewayMachine в нашем примере), предоставьте учетной записи службы шлюза локальные политики олицетворения клиента после проверки подлинности и Act в составе операционной системы (SeTcbPrivilege). Выполните эту настройку с помощью редактора локальной групповой политики (gpedit.msc).

1. На компьютере шлюза запустите gpedit.msc.

2. Перейдите в Политику локального компьютера>Конфигурацию компьютера>Параметры Windows>Параметры безопасности>Локальные политики>Назначение прав пользователей.

   

3. В разделе "Назначение прав пользователя" в списке политик выберите имитировать клиента после проверки подлинности.

   

4. Щелкните правой кнопкой мыши политику, откройте свойства и просмотрите список учетных записей.

   Список должен содержать учетную запись службы шлюза (Contoso\GatewaySvc или ContosoFrontEnd\GatewaySvc в зависимости от типа ограниченного делегирования).

5. В разделе "Назначение прав пользователей" выберите Act в составе операционной системы (SeTcbPrivilege) из списка политик. Убедитесь, что учетная запись службы шлюза включена в список учетных записей.

6. Перезапустите локальный процесс службы шлюза данных .

Шаг 7. Учетная запись Windows может получить доступ к компьютеру шлюза

Метод единого входа (Single Sign-On, SSO) использует проверку подлинности Windows, поэтому убедитесь, что учетная запись Windows может получить доступ к шлюзовому компьютеру. Если вы не уверены, добавьте NT-AUTHORITY\Authenticated Users (S-1-5-11) в локальную группу "Пользователи".

Раздел 2. Конфигурация для конкретной среды

Добавление учетной записи службы шлюза в группу авторизации и доступа Windows

Выполните этот раздел, если применяются какие-либо из следующих ситуаций:

• Ваша среда Active Directory является защищенной.
• Учетная запись службы шлюза и учетные записи пользователей, от имени которых будет выступать шлюз, находятся в отдельных доменах или лесах.

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

Дополнительные сведения см. в разделе "Доступ к авторизации Windows".

Чтобы выполнить этот шаг конфигурации, для каждого домена, содержащего пользователей Active Directory, необходимо, чтобы учетная запись службы шлюза могла олицетворить:

1. Войдите на компьютер в домене и запустите оснастку "Пользователи и компьютеры Active Directory" в MMC.
2. Найдите группу авторизации Windows и группу доступа, которая обычно находится в контейнере Builtin .
3. Дважды щелкните группу и выберите вкладку "Члены ".
4. Выберите Добавить и измените расположение домена на домен, в котором находится учетная запись службы шлюза.
5. Введите имя учетной записи службы шлюза и выберите "Проверить имена" , чтобы убедиться, что учетная запись службы шлюза доступна.
6. Нажмите ОК.
7. Нажмите кнопку "Применить".
8. Перезапустите службу шлюза.

Настройте параметры конфигурации сопоставления пользователей на шлюзовом устройстве

Выполните этот раздел, если:

• У вас нет Microsoft Entra Connect с настроенной синхронизацией учетных записей пользователей И
• UPN, используемый в Power BI для пользователей, не соответствует UPN в вашей локальной среде Active Directory.

Каждый пользователь Active Directory, сопоставленный таким образом, должен иметь доступ SSO для источника данных.

1. Откройте файл конфигурации основного шлюза. Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll По умолчанию этот файл хранится в C:\Program Files\On-premises data gateway.

2. Установите для ADUserNameLookupProperty не используемый атрибут Active Directory. Мы будем использовать msDS-cloudExtensionAttribute1 в следующих шагах. Этот атрибут доступен только в Windows Server 2012 и более поздних версиях.

3. Задайте значение ADUserNameReplacementPropertySAMAccountName и сохраните файл конфигурации.

   Замечание

   В сценариях с несколькими доменами может потребоваться задать ADUserNameReplacementProperty для userPrincipalName сохранения информации о домене пользователя.

4. На вкладке "Службы" диспетчера задач щелкните правой кнопкой мыши службу шлюза и выберите "Перезапустить".

   

5. Для каждого пользователя службы Power BI, для которого необходимо включить единый вход Kerberos, задайте свойство msDS-cloudExtensionAttribute1 локального пользователя Active Directory (с разрешением единого входа в источник данных) на полный UPN пользователя службы Power BI. Например, если вы входите в службу Power BI как test@contoso.com, и хотите сопоставить этого пользователя с локальным пользователем Active Directory с разрешениями единого входа, например, test@LOCALDOMAIN.COM, задайте для атрибута msDS-cloudExtensionAttribute1 этого пользователя значение test@contoso.com.

   Вы можете задать msDS-cloudExtensionAttribute1 свойство с помощью оснастки консоли MMC «Пользователи и компьютеры Active Directory»:

   1. Как администратор домена запустите Active Directory - пользователи и компьютеры.

   2. Щелкните правой кнопкой мыши доменное имя, выберите "Найти", а затем введите имя учетной записи локального пользователя Active Directory для сопоставления.

   3. Перейдите на вкладку "Редактор атрибутов ".

      msDS-cloudExtensionAttribute1 Найдите свойство и дважды щелкните его. Задайте значение полного имени пользователя (UPN) пользователя, используемого для входа в службу Power BI.

   4. Нажмите ОК.

      

   5. Нажмите кнопку "Применить". Убедитесь, что в столбце "Значение " задано правильное значение.

Выполнение действий по настройке для конкретного источника данных

Для источников данных SAP HANA, SAP BW и Teradata требуется дополнительная конфигурация для использования с шлюзом единого входа (SSO).

• Используйте Kerberos для единого входа в SAP HANA.
• Используйте единый вход Kerberos в SAP BW с помощью CommonCryptoLib (sapcrypto.dll).
• Используйте Kerberos для единого входа в Teradata.

Замечание

Хотя другие библиотеки SNC также могут работать для авторизации единого входа BW, они официально не поддерживаются корпорацией Майкрософт.

Раздел 3. Проверка конфигурации

Шаг 1. Настройка источников данных в Power BI

После завершения всех шагов настройки используйте страницу "Управление шлюзом" в Power BI, чтобы настроить источник данных для использования в функции единого входа (SSO). Если у вас несколько шлюзов, убедитесь, что вы выбрали шлюз, который вы настроили для Kerberos SSO. Затем в разделе «Параметры» источника данных убедитесь, что для отчетов на основе DirectQuery выбрана опция «Использовать единый вход с помощью Kerberos для запросов DirectQuery» или «Использовать единый вход с помощью Kerberos для запросов DirectQuery и импорта», а для отчетов на основе импорта выбрана опция «Использовать единый вход с помощью Kerberos для запросов DirectQuery и импорта».

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

Используйте единый вход с помощью Kerberos для запросов DirectQuery:

• Для отчетов на основе DirectQuery используются учетные данные единого входа пользователя.
• Для отчетов на основе импорта учетные данные единого входа не используются, но используются учетные данные, введенные на странице источника данных.

Используйте единый вход через Kerberos для запросов DirectQuery и импорта:

• Для отчетов на основе DirectQuery используются учетные данные единого входа пользователя.
• Для отчетов на основе импорта используются учетные данные единого входа владельца семантической модели независимо от пользователя, активировающего импорт.

Шаг 2. Проверка единого входа

Перейдите к конфигурации единого входа (SSO), чтобы быстро проверить правильность настройки конфигурации и устранить распространенные проблемы.

Шаг 3. Запуск отчета Power BI

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

Связанный контент

Дополнительные сведения о локальном шлюзе данных и DirectQuery см. в следующих ресурсах:

• Что такое локальный шлюз данных?
• DirectQuery в Power BI
• источники данных, поддерживаемые DirectQuery
• DirectQuery и SAP BW
• DirectQuery и SAP HANA