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

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

Эта статья не содержит пошаговых инструкций по установке и настройке шлюза. Их можно найти в статье Локальный шлюз данных. Здесь подробно описаны принципы работы шлюза. Кроме того, статья содержит некоторые сведения об именах пользователей и вопросах безопасности в каталоге Azure Active Directory и в службах Analysis Services, а также о том, как облачная служба использует адрес электронной почты, с которым пользователь входит в нее, шлюз и Active Directory для безопасного подключения и запроса локальных данных.

Принципы работы шлюзов

on-prem-data-gateway-how-it-works

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

Примечание.

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

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

  2. Облачная служба шлюза анализирует запрос и передает его служебной шине Azure.

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

  4. Шлюз получает запрос, расшифровывает учетные данные и использует их для установки подключения к источникам.

  5. Шлюз отправляет запрос в источник данных на исполнение.

  6. Результаты возвращаются источником в шлюз, а оттуда — в облачную службу. Затем служба использует полученные результаты.

Список доступных типов источников данных

Источник данных Активный запрос или запрос DirectQuery Настроенное пользователем ручное или запланированное обновление
Табличная модель Analysis Services Да Да
Многомерная модель Analysis Services Да Да
SQL Server Да Да
SAP HANA Да Да
Oracle Да Да
Teradata Да Да
Файл Нет Да
Папка Нет Да
Список SharePoint (локальный) Нет Да
Веб-приложение Нет Да
OData Нет Да
IBM DB2 Нет Да
MySQL Нет Да
Sybase Нет Да
SAP BW Нет Да
База данных IBM Informix Нет Да
ODBC Нет Да

Учетная запись для входа

Пользователи будут входить в систему с рабочей или учебной учетной записью. Это учетная запись вашей организации. Если у вас есть подписка на Office 365 и вы не указали свой реальный рабочий адрес электронной почты, ваша учетная запись может иметь вид nancy@contoso.onmicrosoft.com. Ваша учетная запись в облачной службе хранится в клиенте в каталоге Azure Active Directory (AAD). В большинстве случаев имя участника-пользователя учетной записи AAD совпадает с адресом электронной почты.

Проверка подлинности в локальных источниках данных

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

Проверка подлинности на динамическом источнике данных Analysis Services

Каждый раз, когда пользователь взаимодействует со службами Analysis Services, действующее имя пользователя передается в шлюз, а затем на локальный сервер служб Analysis Services. В качестве имени пользователя в Analysis Services передается имя участника-пользователя (как правило, это адрес электронной почты, с которым вы вошли в облачную службу). Для его передачи используется свойство подключения EffectiveUserName. Этот адрес электронной почты должен совпадать с именем участника-пользователя, определенным в локальном домене Active Directory. Имя участника-пользователя является свойством учетной записи Active Directory. Для доступа к серверу соответствующая учетная запись Windows должна присутствовать в роли Analysis Services. Если совпадение в Active Directory не обнаруживается, выполнить вход не удается.

Службы Analysis Services также могут выполнять фильтрацию на основе данной учетной записи. Фильтрация выполняется на уровне роли или на уровне строк.

Безопасность на основе ролей

Модели обеспечивают безопасность на основе ролей пользователей. Роли задаются для конкретного проекта модели на этапе разработки в средствах бизнес-аналитики SQL Server Data Tools (SSDT-BI) или после развертывания модели с помощью SQL Server Management Studio (SSMS). Членами ролей могут быть имена пользователей Windows или группы Windows. Роли определяют разрешения, которые имеются у пользователя для выполнения запросов или действий в модели. Большинство пользователей будут принадлежать к роли с разрешениями на чтение. Другие роли предназначены для администраторов и имеют разрешения на обработку элементов, управление функциями базы данных и управление другими ролями.

Безопасность на уровне строк

Безопасность на уровне строк — это функция Analysis Services. Модели могут обеспечивать динамическую безопасность на уровне строк. Пользователь должен принадлежать хотя бы к одной роли; в отличие от этого, динамическая безопасность не является обязательной для любой табличной модели. На высоком уровне динамическая безопасность определяет доступ пользователей на чтение данных непосредственно в определенной строке в определенной таблице. Аналогично ролям, динамическая безопасность на уровне строк основывается на имени пользователя Windows.

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

Реализация безопасности на основе ролей и динамической безопасности на уровне строк в моделях в этой статье не рассматривается. Дополнительные сведения см. в статьях Роли (табличные службы SSAS) и Роли безопасности (службы Analysis Services — многомерные данные) в MSDN. Чтобы максимально полно разобраться в безопасности табличной модели, скачайте и прочтите технический документ Безопасность в табличной семантической модели бизнес-аналитики.

Об Azure Active Directory

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

Каковы функции локального каталога Active Directory?

Чтобы службы Analysis Services могли определить, относится ли подключившийся к ним пользователь к роли с разрешениями на чтение данных, сервер должен преобразовать действующее имя пользователя, переданное из AAD в шлюз, а затем на сервер служб Analysis Services. Сервер Analysis Services передает действующее имя пользователя на контроллер домена Windows Active Directory. Затем контроллер домена Active Directory проверяет, является ли действующее имя пользователя действительным именем участника-пользователя в локальной учетной записи, и возвращает его имя пользователя Windows обратно на сервер служб Analysis Services.

Параметр EffectiveUserName нельзя использовать в на сервере Analysis Services, который не присоединен к домену. Чтобы избежать ошибок при входе, локальный сервер Analysis Services должен входить в домен.

Как узнать свое имя участника-пользователя?

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

whoami /upn

Имя участника-пользователя для локальной учетной записи домена будет похоже на адрес электронной почты. Если вы используете источник данных Analysis Services для динамических подключений, этот параметр должен совпадать со значением, передаваемым в свойстве EffectiveUserName из шлюза.

Сопоставление имен пользователей для источников данных Analysis Services

В Power BI можно сопоставлять имена пользователей для источников данных Analysis Services. Вы можете настроить правила сопоставления имени пользователя, выполнившего вход в Power BI, с именем, которое передается в свойстве EffectiveUserName для подключения служб Analysis Services. Это удобный способ в ситуации, когда имя пользователя в AAD не соответствует имени участника-пользователя (UPN) в локальной службе Active Directory. Например, адрес электронной почты nancy@contoso.onmicrsoft.com можно сопоставить с адресом nancy@contoso.com, и это значение будет передано шлюзу. Вы можете ознакомиться с дополнительными сведениями о сопоставлении имен пользователей.

Синхронизация локальной Active Directory с Azure Active Directory

Если вы планируете работать с динамическими подключениями Analysis Services, учетные записи в вашем локальном каталоге Active Directory должны соответствовать содержимому Azure Active Directory. В частности, должны совпадать имена участников-пользователей.

Облачным службам известно только об учетных записях, которые хранятся в каталоге Azure Active Directory. Неважно, добавили ли вы соответствующую запись в локальную службу Active Directory: если ее нет в AAD, использовать ее нельзя. Синхронизировать учетные записи в локальном каталоге Active Directory со службой Azure Active Directory можно разными способами.

  1. Вы можете вручную добавить учетные записи в Azure Active Directory.

    Вы можете создать на портале Azure или портале администрирования Office 365 учетную запись, имя которой будет совпадать с именем участника-пользователя учетной записи в локальном каталоге Active Directory.

  2. Вы можете синхронизировать локальные учетные записи со своим клиентом Azure Active Directory с помощью средства Azure AD Connect.

    Приложение Azure AD Connect позволяет настроить параметры синхронизации каталогов и паролей. Если вы не являетесь администратором клиента или локального домена, для их настройки вам потребуется обратиться к своему ИТ-администратору.

  3. Вы можете настроить службы федерации Active Directory (ADFS).

    Сервер ADFS можно связать с клиентом AAD с помощью инструмента Azure AD Connect. ADFS использует функцию синхронизации каталогов, описанную выше, однако также позволяет реализовать единый вход. Например, находясь в рабочей сети, вы сможете подключаться к облачной службе и входить в нее, не вводя имя пользователя и пароль. Уточните, доступна ли такая возможность для вашей организации, у своего ИТ-администратора.

Приложение Azure AD Connect помогает обеспечить соответствие между именами участников-пользователей в AAD и локальном каталоге Active Directory.

Примечание.

При синхронизации учетных записей с помощью Azure AD Connect создаются новые учетные записи в клиенте AAD.

Теперь в дело вступает шлюз.

Шлюз выступает в качестве моста между облачной службой и локальным сервером. Передача данных между облаком и шлюзом защищена с помощью служебной шины Azure. Служебная шина создает защищенный канал обмена информацией между облачной средой и локальным сервером через исходящее подключение на шлюзе. Вам не потребуется настраивать на своем локальном брандмауэре возможность входящих соединений.

Если у вас есть источник данных Analysis Services, необходимо установить шлюз на компьютере, присоединенном к тому же лесу или домену, что и сервер служб Analysis Services.

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

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

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

Управление своим источником данных — службы Analysis Services
Управление своим источником данных — SAP HANA
Управление своим источником данных — SQL Server
Управление своим источником данных — Oracle
Управление источником данных — импорт или запланированное обновление

Где могут возникнуть проблемы

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

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

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

Учетная запись для входа

Пользователи будут входить в систему с рабочей или учебной учетной записью. Это учетная запись вашей организации. Если у вас есть подписка на Office 365 и вы не указали свой реальный рабочий адрес электронной почты, ваша учетная запись может иметь вид nancy@contoso.onmicrosoft.com. Ваша учетная запись в облачной службе хранится в клиенте в каталоге Azure Active Directory (AAD). В большинстве случаев имя участника-пользователя учетной записи AAD совпадает с адресом электронной почты.

Учетная запись служб Windows

Локальный шлюз данных настроен для входа в службы Windows с учетными данными NT SERVICE\PBIEgwService. По умолчанию он имеет право выполнять вход в качестве службы. Это происходит в контексте компьютера, на котором устанавливается шлюз.

Примечание.

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

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

Если у вас возникнут проблемы с проверкой подлинности через прокси-сервер, вы можете сменить учетную запись службы Windows на учетную запись пользователя домена или управляемую учетную запись службы. Инструкции по смене учетной записи приведены в разделе о настройке прокси-сервера.

Порты

Шлюз создает исходящее подключение к служебной шине Azure. Связь осуществляется через исходящие порты TCP 443 (по умолчанию), 5671, 5672, 9350–9354. Шлюзу не требуются входящие порты. Дополнительные сведения

Рекомендуется добавить IP-адреса для региона, в котором хранятся ваши данные, в список разрешений брандмауэра. Вы можете скачать список IP-адресов центров данных Microsoft Azure. Он обновляется еженедельно. Шлюз будет взаимодействовать со служебной шиной Azure, используя IP-адрес и полное доменное имя (FQDN). При принудительной установке связи по протоколу HTTPS шлюз будет использовать только полное доменное имя, поэтому он не будет устанавливать связь по IP-адресам.

Примечание.

IP-адреса в списке адресов центров данных Azure указаны в формате CIDR. Например, запись 10.0.0.0/24 не означает диапазон адресов с 10.0.0.0 по 10.0.0.24. Ознакомьтесь с дополнительными сведениями о формате CIDR.

Вот список полных доменных имен, которые используются шлюзом.

Имена доменов Исходящие порты Описание
*.download.microsoft.com 80 HTTP, используемый для скачивания установщика.
*.powerbi.com 443 HTTPS
*.analysis.windows.net 443 HTTPS
*.login.windows.net 443 HTTPS
*.servicebus.windows.net 5671-5672 Расширенный протокол управления очередью сообщений (AMQP)
*.servicebus.windows.net 443, 9350-9354 Прослушиватели для ретранслятора служебной шины по протоколу TCP (порт 443 требуется для получения маркера контроля доступа).
*.frontend.clouddatahub.net 443 HTTPS
*.core.windows.net 443 HTTPS
login.microsoftonline.com 443 HTTPS
*.msftncsi.com 443 Используется для проверки подключения к Интернету, если шлюз недоступен для службы Power BI.
*.microsoftonline p.com 443 Используется для проверки подлинности в зависимости от конфигурации.
Примечание.

Трафик, передаваемый на сайты visualstudio.com или visualstudioonline.com, нужен для работы компонента Application Insights. Этот трафик не влияет на функционирование шлюза.

Принудительная установка связи по HTTPS со служебной шиной Azure

Для шлюза можно настроить принудительную установку связи со служебной шиной Azure по протоколу HTTPS, а не TCP. Это может повлиять на производительность. Для такой настройки измените в файле Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config значение AutoDetect на значение Https, как показано во фрагменте кода ниже. По умолчанию этот файл располагается здесь: C:\Program Files\On-premises data gateway.

<setting name="ServiceBusSystemConnectivityModeString" serializeAs="String">
    <value>Https</value>
</setting>

Кроме того, для шлюза можно настроить принудительный режим, описанный выше, с помощью пользовательского интерфейса шлюза. Ознакомиться с ним вы можете в мартовском выпуске 2017 г. В пользовательском интерфейсе шлюза выберите раздел Сеть, а затем задайте для режима подключения к служебной шине Azure значение Включено.

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

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

Высокая доступность

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

Как перезапустить шлюз

Шлюз работает в качестве службы Windows. Его можно запустить и остановить, как и любую службу Windows. Существует несколько способов это сделать. Вот как это можно сделать из командной строки.

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

  2. Остановить службу можно с помощью следующей команды:

    net stop PBIEgwService

  3. Запустить службу можно с помощью следующей команды:

    net start PBIEgwService

См. также:

Устранение неполадок локального шлюза данных
Служебная шина Azure
Azure AD Connect
Появились дополнительные вопросы? Ответы на них см. в сообществе Power BI.