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

Примечание.

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

После установки локального шлюза данных можно добавить источники данных для использования с шлюзом. В этой статье описывается, как добавить источник данных СЛУЖБ SQL Server Analysis Services (SSAS) в локальный шлюз для использования для запланированного обновления или для динамических подключений.

Дополнительные сведения о настройке динамического подключения к SSAS см. в этом пошаговом руководстве по Power BI: Live Подключение видео служб Analysis Services.

Примечание.

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

Примечание.

Шлюз поддерживает только проверка подлинности Windows для служб Analysis Services.

Добавление источника данных

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

  1. На экране "Создать подключение" для локального шлюза данных выберите службы Analysis Services для типа Подключение ion. Дополнительные сведения о добавлении источника данных см. в разделе "Добавление источника данных".

     Screenshot of adding the Analysis Services data type.

  2. Укажите сведения для источника данных, включая сервер и базу данных. Шлюз использует сведения, которые вы вводите для имени пользователя и пароля для подключения к экземпляру служб Analysis Services.

     Screenshot that shows the data source credentials settings.

    Примечание.

    Введенная учетная запись Windows должна быть членом роли сервера Администратор istrator в экземпляре служб Analysis Services, к которому вы подключаетесь. Если срок действия пароля этой учетной записи истекает, пользователи получают ошибку подключения, если вы не обновляете пароль источника данных. Дополнительные сведения о том, как хранятся учетные данные, см. в разделе "Хранилище зашифрованных учетных данных" в облаке.

  3. Настройте уровень конфиденциальности для источника данных. Этот параметр определяет, как можно объединить данные для запланированного обновления. Параметр уровня конфиденциальности не применяется к динамическим подключениям. Дополнительные сведения о уровнях конфиденциальности для источника данных см. в разделе "Настройка уровней конфиденциальности" (Power Query).

    Screenshot of the Privacy level setting.

  4. При необходимости можно настроить сопоставление имен пользователей. Инструкции см. в разделе "Повторное сопоставление имени пользователя вручную".

  5. После завершения всех полей нажмите кнопку "Создать".

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

Имена пользователей для служб Analysis Services

Чтобы узнать о проверке подлинности с помощью динамических подключений служб Analysis Services в Power BI, просмотрите это видео:

Примечание.

Это видео может использовать более ранние версии Power BI Desktop или служба Power BI.

Каждый раз, когда пользователь взаимодействует с отчетом, подключенным к службам Analysis Services, действующее имя пользователя передается шлюзу, а затем передается на локальный сервер Служб Analysis Services. Адрес электронной почты, используемый для входа в Power BI, передается службам Analysis Services в качестве действующего пользователя в свойстве подключения EffectiveUserName .

Адрес электронной почты должен соответствовать определенному имени участника-пользователя (UPN) в локальном домене Active Directory (AD). Имя участника-пользователя — это свойство учетной записи AD. Учетная запись Windows должна присутствовать в роли служб Analysis Services. Если совпадение не удается найти в AD, вход не выполнен. Дополнительные сведения об именовании AD и пользователей см. в разделе атрибуты именования пользователей.

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

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

Примечание.

Это видео может использовать более ранние версии Power BI Desktop или служба Power BI.

Power BI позволяет сопоставлять имена пользователей для источников данных Служб Analysis Services. Вы можете настроить правила для сопоставления имени пользователя входа в Power BI с EffectiveUserName данным, который передается подключению служб Analysis Services. Эта функция является отличным решением, если имя пользователя Microsoft Entra не соответствует имени участника-пользователя в локальном экземпляре Active Directory. Например, если адрес meganb@contoso.onmicrosoft.comэлектронной почты указан, его можно сопоставить meganb@contoso.comс , а это значение передается шлюзу.

Имена пользователей для служб Analysis Services можно сопоставить двумя разными способами:

  • Повторное сопоставление пользователей вручную в Power BI
  • Сопоставление подстановок Active Directory, которое использует локальный поиск свойств AD для повторного сопоставления имен участника-пользователя Microsoft Entra с локальными пользователями AD.

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

В следующих разделах описаны два подхода к сопоставлению.

Повторное сопоставление пользователей вручную в Power BI

Настраиваемые правила имени участника-службы можно настроить в Power BI для источников данных Analysis Services. Пользовательские правила помогают, если имя входа служба Power BI не соответствует имени имени участника-пользователя локального каталога. Например, при входе в Power BI с meganb@contoso.com помощью имени участника-пользователя meganb@contoso.localлокального каталога можно настроить правило сопоставления для передачи meganb@contoso.local в службы Analysis Services.

Важно!

Сопоставление работает для определенного источника данных, настроенного. Это не глобальный параметр. Если у вас несколько источников данных Служб Analysis Services, необходимо сопоставить пользователей с каждым источником данных.

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

  1. На значке шестеренки Power BI выберите "Управление шлюзами и подключениями".

  2. Выберите источник данных и выберите Параметры в верхнем меню.

  3. На экране Параметры в поле "Имена пользователей карты" убедитесь, что выбран параметр EffectiveUserName, а затем нажмите кнопку "Добавить новое правило".

     Screenshot of the UPN mapping screen.

  4. В разделе "Сопоставление имен пользователей" для сопоставления введите значения для исходного имени и нового имени, а затем нажмите кнопку "Добавить новое правило". Значение "Заменить " — это адрес входа в Power BI, а значение With — это значение для замены. Замена передается свойству EffectiveUserName для подключения служб Analysis Services.

    Screenshot of Add new rule in the Map user names box.

    Рассмотрим пример.

    Screenshot of example mapping rules.

    Примечание.

    Не изменяйте пользователей, которые вы не собираетесь изменять. Например, если заменить исходное имяcontoso.comновым именем@contoso.local, все входы пользователя, содержащиеся @contoso.com в нем, заменяются.@contoso.local Кроме того, если вы замените исходное имяmeganb@contoso.comновым именемmeganb@contoso.local, вход v-meganb@contoso.com отправляется как .v-meganb@contoso.local

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

Использование дикого карта

Для строки Замены (исходного имени) можно использовать параметр *wild карта. Вы можете использовать только дикий карта самостоятельно, а не с другой строковой частью. Используйте дикую карта если вы хотите заменить всех пользователей одним значением для передачи в источник данных. Этот подход полезен, если требуется, чтобы все пользователи в организации использовали одного и того же пользователя в локальной среде.

Проверка правила сопоставления

Чтобы проверить замену имени, введите значение для исходного имени и выберите "Тест".

 Screenshot of testing a mapping rule.

Примечание.

Сохраненные правила работают сразу же в браузере. Несколько минут, прежде чем служба Power BI начнет использовать сохраненные правила.

Сопоставление подстановок Active Directory

В этом разделе описывается, как выполнить поиск свойств локальная служба Active Directory для повторного сопоставления имен участника-пользователя Microsoft Entra с пользователями AD. Во-первых, ознакомьтесь с тем, как работает перемаделка.

Каждый запрос пользователя Microsoft Entra Power BI к локальному серверу SSAS передается по строке имени участника-пользователя, например firstName.lastName@contoso.com.

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

  1. Найдите Active Directory для поиска. Вы можете использовать автоматический или настраиваемый режим.
  2. Найдите атрибут пользователя Active Directory, например email, из служба Power BI. Атрибут основан на входящей строке имени участника-участника, например firstName.lastName@contoso.com.
  3. Если поиск Active Directory завершается ошибкой, он пытается передать имя участника-пользователя в SSAS в качестве имени EffectiveUserName.
  4. Если поиск Active Directory выполнен успешно, он извлекает UserPrincipalName пользователя Active Directory.
  5. Сопоставление передает UserPrincipalName сообщение электронной почты, например Alias@corp.on-prem.contosoSSAS в качестве EffectiveUserName.

Примечание.

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

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

  1. Обязательно скачайте и установите последний шлюз.

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

  3. Перейдите в папку установки шлюза C :\Program Files\Локальный шлюз данных, чтобы убедиться, что у вас есть разрешения на запись. Откройте файл Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config.

  4. ADUserNameLookupProperty Измените значения и ADUserNameReplacementProperty значения в соответствии с конфигурациями атрибутов AD для пользователей AD. Ниже приведены примеры значений. Эти конфигурации чувствительны к регистру, поэтому убедитесь, что они соответствуют значениям в AD.

    Screenshot of Active Directory settings.

    Если файл не предоставляет значения конфигурации ADServerPath , шлюз использует глобальный каталог по умолчанию. Можно указать несколько значений ADServerPathдля . Значения должны быть разделены точкой с запятой, как показано в следующем примере:

    <setting name="ADServerPath" serializeAs="String">
        <value> GC://serverpath1; GC://serverpath2;GC://serverpath3</value>
    </setting>
    

    Шлюз анализирует значения ADServerPath слева направо, пока не обнаружит совпадение. Если шлюз не находит совпадения, он использует исходное имя участника-участника-участника. Убедитесь, что учетная запись, которая запускает службу шлюза PBIEgwService, имеет разрешения на запрос ко всем серверам AD, указанным в ADServerPath.

    Шлюз поддерживает два типа ADServerPath:

    • Для WinNT: <value="WinNT://usa.domain.corp.contoso.com,computer"/>
    • Для глобального каталога (GC): <value> GC://USA.domain.com </value>
  5. Перезапустите локальную службу шлюза данных, чтобы изменение конфигурации вступило в силу.

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

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

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

Этот адрес электронной почты должен соответствовать определенному имени участника-пользователя в локальном домене Active Directory. Имя участника-пользователя — это свойство учетной записи AD. Учетная запись Windows должна присутствовать в роли служб Analysis Services, чтобы иметь доступ к серверу. Если совпадение не найдено в Active Directory, вход не будет успешным.

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

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

  • Безопасность на основе ролей. Модели обеспечивают безопасность на основе ролей пользователей. Вы можете определить роли для конкретного проекта модели во время разработки в средствах бизнес-аналитики SQL Server Data Tools. После развертывания модели можно определить роли с помощью SQL Server Management Studio. Роли содержат участников, назначенных именем пользователя Windows или группой Windows.

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

  • Безопасность на уровне строк. Модели могут обеспечить динамическую безопасность на уровне строк. Любая определенная безопасность на уровне строк зависит от служб Analysis Services. Для обеспечения безопасности на основе ролей каждый пользователь должен иметь по крайней мере одну роль, но для табличной модели не требуется динамическое обеспечение уровня строк.

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

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

Проверка подлинности Microsoft Entra

Облачные службы Майкрософт используют идентификатор Microsoft Entra для проверки подлинности пользователей. Идентификатор Microsoft Entra — это клиент, содержащий имена пользователей и группы безопасности. Как правило, адрес электронной почты, с которым пользователь входит, совпадает с именем участника-пользователя учетной записи.

Роли в локальном экземпляре Active Directory

Чтобы службы Analysis Services определили, принадлежит ли пользователь роли с разрешениями на чтение данных, серверу необходимо преобразовать эффективное имя пользователя, переданное из идентификатора Microsoft Entra в шлюз и на сервер Служб Analysis Services. Сервер служб Analysis Services передает действующее имя пользователя контроллеру домена Windows Active Directory (DC). Затем контроллер домена Active Directory проверяет, является ли действующее имя пользователя допустимым именем участника-пользователя в локальной учетной записи. Контроллер домена возвращает имя пользователя Windows обратно на сервер служб Analysis Services.

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

Определение имени участника-пользователя

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

whoami /upn

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

Синхронизация локального AD с идентификатором Microsoft Entra

Если вы планируете использовать динамические подключения служб Analysis Services, локальные учетные записи AD должны соответствовать идентификатору Microsoft Entra. Имя участника-пользователя должно совпадать между учетными записями.

Облачные службы используют только учетные записи в идентификаторе Microsoft Entra. Если вы добавляете учетную запись в локальный экземпляр AD, который не существует в идентификаторе Microsoft Entra, вы не можете использовать эту учетную запись. Существует несколько способов сопоставления локальных учетных записей AD с идентификатором Microsoft Entra:

  • Добавьте учетные записи вручную в идентификатор Microsoft Entra.

    Создайте учетную запись в портал Azure или в Центр администрирования Microsoft 365 с именем учетной записи, которая соответствует имени участника-пользователя локальной учетной записи AD.

  • Синхронизация локальных учетных записей с клиентом Microsoft Entra с помощью Microsoft Entra Подключение Sync.

    Microsoft Entra Подключение гарантирует соответствие имени участника-пользователя между идентификатором Microsoft Entra и локальным экземпляром AD. Средство Microsoft Entra Подключение предоставляет параметры синхронизации каталогов и настройки проверки подлинности. Варианты включают синхронизацию хэша паролей, сквозную проверку подлинности и федерацию. Если вы не являетесь администратором или администратором локального домена, обратитесь к ИТ-администратору, чтобы помочь в настройке.

    Примечание.

    Синхронизация учетных записей с Microsoft Entra Подключение Sync создает новые учетные записи в клиенте Microsoft Entra.

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

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

Примечание.

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

Связь между набором данных и источником данных в шлюзе основана на имени сервера и имени базы данных. Эти имена должны совпадать. Например, если вы предоставляете IP-адрес для имени сервера в Power BI Desktop, необходимо использовать IP-адрес для источника данных в конфигурации шлюза. Если вы используете SERVER\INSTANCE в Power BI Desktop, необходимо также использовать SERVER\INSTANCE в источнике данных, настроенном для шлюза. Это требование относится как к динамическим подключениям, так и к запланированному обновлению.

Использование источника данных с динамическими подключениями

Вы можете использовать динамическое подключение для табличных или многомерных экземпляров. При первом подключении к данным вы выбираете динамическое подключение в Power BI Desktop. Убедитесь, что имя сервера и базы данных совпадает между Power BI Desktop и настроенным источником данных для шлюза. Кроме того, чтобы пользователи могли публиковать динамические наборы данных подключения, пользователи должны отображаться в разделе "Пользователи " в списке источников данных.

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

Использование источника данных с запланированным обновлением

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

Screenshot of selecting the on-premises gateway to use for scheduled refresh.

Ограничения динамических подключений служб Analysis Services

  • Функции форматирования и перевода на уровне ячеек не поддерживаются.

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

Требования К SKU

Версия сервера Обязательный номер SKU
2012 с пакетом обновления 1 (SP1) с накопительным пакетом обновления 4 (CU4) или более поздней версии Бизнес-аналитика и номер SKU enterprise
2014 Бизнес-аналитика и номер SKU enterprise
2016 Номер SKU уровня "Стандартный" или более поздней версии

Есть еще вопросы? Попробуйте Сообщество Power BI.