Разрешить пользователям из внешней сети доступ к кубам SSAS
Я хотел бы знать, каким образом можно достичь следующего.
Предположим, что компания с именем CompanyA использует кубы SSAS, а CompanyA приобретена другой компанией с именем CompanyB. Пользователи CompanyA перемещаются в сеть CompanyB поэтапно.
Следовательно, кубы SSAS должны быть доступны пользователям, которые все еще находятся в сети CompanyA, а также пользователям, которые были перенесены в сеть CompanyB.
Также домен CompanyA не принадлежит домену доверенного пользователя CompanyB и наоборот
Реален ли такой сценарий? Если да, то, пожалуйста, дайте мне знать, как можно достичь этого, кроме использования VPN.
Я гуглил по этому сценарию, но большинство из них говорят о внешней сети. Но в этом случае внешняя сеть принадлежит приобретенной компании, что делает его другим.
1 ответ
Вероятно, самый простой вариант (наименьший код и наименьшая сложность) - это ежедневное резервное копирование кубов, копирование файлов резервных копий на новый сервер SSAS в сети компании B, а затем восстановление резервных копий, пропуская членов ролей безопасности (что является опцией в диалог восстановления в SSMS). Все это может быть автоматизировано для ежедневного запуска. Возможно, новый сервер домена компании B может даже иметь псевдоним DNS, соответствующий имени сервера в сети компании A.
Однако, если вы не хотите размещать другую копию куба в домене компании B, тогда есть другой вариант, который потребует некоторого кодирования C#. Для пользователей Excel вы можете разместить этот прокси-код на общедоступном веб-сайте. Веб-сайт допускает "базовую авторизацию", а код отвечает за определение правильности учетных данных. Таким образом, вы могли бы выяснить, как позволить пользователям Компании B аутентифицироваться соответствующим образом. Убедитесь, что используете HTTPS. Это решение использует свойство CustomData для передачи имени пользователя в куб. Таким образом, вам необходимо настроить пользовательскую роль в кубе с помощью функции MDD CustomData () или игнорировать ее, если не требуется защита на уровне данных. Я сделал это для клиента, так что это определенно работает.
Для SSRS я бы порекомендовал создать отдельный пользовательский веб-сайт для пользователей компании B, который отображает соответствующие отчеты с использованием элемента управления ReportViewer в режиме удаленной обработки. Это предполагает, что отчеты могут подключаться к SSAS с учетной записью компании A, и все пользователи видят одни и те же данные.
Я бы порекомендовал описанный выше подход к SSRS, поскольку он проще и менее инвазивен, чем изменение всего сайта SSRS для использования пользовательских форм авторизации.
Для Power BI можно изменить шлюз на использование CustomData. На веб-сайте Power BI значок шестеренки... Управление шлюзами... Разверните шлюз и источник данных... перейдите на вкладку Пользователи... нажмите кнопку Сопоставить имена пользователей. Вы увидите такой экран. Выберите CustomData.
Я считаю, что вы должны просто иметь возможность приглашать пользователей bob@companyb.com, и это должно работать. Я подозреваю, что приборная панель должна работать в Power BI Premium в компании. Арендатор Power BI или bob@companyb.com должны иметь лицензию Power BI Pro.
Кстати, Power BI Desktop и Power BI Service, которые я последний раз проверял, не поддерживают настраиваемый прокси-сервер SSAS, который я упоминал для сценария Excel выше. Но если вы можете публиковать данные в службе Power BI с помощью упомянутого выше параметра пользовательских имен Map Map, вам не нужно подключать пользователей к Power BI Desktop.