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

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

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

Предварительные требования

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Machine-local service account

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

Вариант Б. Настройка компьютера для Azure AD Подключение

Если настроено средство Azure AD Connect и учетные записи пользователей синхронизированы, службе шлюза не требуется выполнять поиск в локальном экземпляре Azure AD во время выполнения. Вместо этого можно просто применить идентификатор безопасности локальной службы в службе шлюза, чтобы выполнить все необходимые настройки в Azure AD. Этапы настройки ограниченного делегирования Kerberos, описанные в этой статье, будут для этой конфигурации такими же, как и в контексте Azure AD. Здесь они применяются к объекту-компьютеру шлюза (который определяется по идентификатору безопасности локальной службы) в Azure AD, а не к учетной записи домена. Идентификатор безопасности локальной службы для 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>

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

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

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

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

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

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

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

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

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

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

    setspn -S gateway/MyGatewayMachine Contoso\GatewaySvc

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

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

В параметрах делегирования можно указать ограниченное делегирование Kerberos на основе ресурсов или стандартное ограниченное делегирование Kerberos. Дополнительные сведения о различиях между двумя подходами к делегированию см. на странице общих сведений об ограниченном делегировании 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 (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. Для этой учетной записи должно быть задано соответствующее имя субъекта-службы для источника данных.

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

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

  9. Щелкните ОК.

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

    Gateway Connector Properties dialog box

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

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

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

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

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

Выполните следующие шаги для конфигурации:

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

    Gateway connector properties

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

    SQL service properties

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

    SQL service attributes

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

    Group properties

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

    $c = Get-ADGroup ResourceDelGroup
    Set-ADUser SQLService -PrincipalsAllowedToDelegateToAccount $c
    
  6. Можно убедиться, что обновление отображается на вкладке редактора атрибутов в разделе свойств для учетной записи серверной службы в оснастке Пользователи и компьютеры Active Directory.

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

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

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

  2. Перейдите к конфигурации Configuration>Local Computer> PolicyComputer Windows Параметры>Security Параметры>Local PoliciesUser>Rights Assignment.

    Local Computer Policy folder structure

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

    Impersonate a client policy

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

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

  5. В списке политик в разделе Назначение прав пользователя выберите Работа в режиме операционной системы (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 Authorization and Access Group (Группа авторизации и доступа Windows), которая обычно находится в контейнере Builtin (Встроенные).
  3. Дважды щелкните группу и перейдите на вкладку Участники.
  4. Щелкните Добавить и укажите домен, в котором находится учетная запись службы шлюза.
  5. Введите имя учетной записи службы шлюза и щелкните Проверить имена, чтобы убедиться, что учетная запись службы шлюза доступна.
  6. Нажмите кнопку ОК.
  7. Нажмите кнопку Применить.
  8. Перезапустите службу шлюза.

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

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

  • У вас нет настроенных Azure AD Подключение AND
  • Имя участника-пользователя, используемое в 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, чтобы всегда использовать имя участника-пользователя Power BI.

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

    Screenshot of Task Manager Services tab

  5. Для каждого пользователя службы Power BI, которому потребуется единый вход Kerberos, в свойстве msDS-cloudExtensionAttribute1 локального пользователя Active Directory (с разрешением единого входа для используемого источника данных) укажите полное имя пользователя службы 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 и дважды щелкните его. В качестве значения введите полное имя пользователя, которое вы используете для входа в службу Power BI (имя участника-пользователя).

    4. Щелкните ОК.

      String Attribute Editor window

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

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

Для SAP HANA источников данных SAP BW и Teradata требуется дополнительная настройка для использования с единым входом шлюза:

Примечание

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

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

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

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

 Screenshot of adding settings for single-sign on.

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

Использовать единый вход (SSO) через Kerberos для запросов DirectQuery.

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

Использовать единый вход (SSO) через Kerberos для запросов DirectQuery и импорта.

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

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

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

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

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

Дальнейшие действия

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