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

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

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

Необходимые компоненты

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вариант A. Запуск службы Windows шлюза в качестве учетной записи домена с помощью имени участника-службы

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

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

Настройка имени субъекта-службы для учетной записи службы шлюза

Сначала определите, создан ли имя субъекта-службы для учетной записи домена, используемой в качестве учетной записи службы шлюза:

1. В качестве администратора домена запустите оснастку Пользователи и компьютеры Active Directory консоли управления Майкрософт (MMC).

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

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

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

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

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

   setspn -S gateway/MyGatewayMachine Contoso\GatewaySvc

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

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

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

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

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

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

Примечание.

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

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

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

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

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

Примечание.

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

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

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

Вариант A. Ограниченное делегирование Kerberos уровня "Стандартный"

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

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

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

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

• домен Active Directory (Net биография s): 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. В этой учетной записи уже должна быть задана соответствующая имя субъекта-службы для источника данных.

8. Выберите имя субъекта-службы, созданное для сервера базы данных.

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

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

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

   

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

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

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

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

• Интерфейсный домен Active Directory (Net биография s): ContosoFrontEnd
• Серверный домен Active Directory (Net биография s): 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 создайте группу на контроллере домена для домена ContosoBackEnd. Добавьте учетную запись службы шлюза GatewaySvc в группу ResourceDelGroup.

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

Примечание.

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

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

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

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

2. Перейдите в раздел "Конфигурация>компьютера локальной политики>компьютеров" Windows Параметры Security Параметры>> Local Policies>User Rights Assignment.

   

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

   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   Примечание.

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

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

Примечание.

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

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

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

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