Методики проверки подлинности, поддерживаемые службами Analysis Services

Применимо к: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

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

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

Дополнительные сведения о потоках проверки подлинности бизнес-аналитики и служб Analysis Service см. в разделе Проверка подлинности для бизнес-аналитики Майкрософт и делегирование удостоверений.

Основные сведения о вариантах проверки подлинности

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

Табличная или многомерная модель часто имеет разные уровни доступа к данным (по объекту или в пределах самих данных), исходя из того, кто осуществляет запрос. Чтобы выполнить это требование, можно использовать режим проверки подлинности NTLM, Kerberos, EffectiveUserName или обычной режим. Все эти методы позволяют передавать разные удостоверения пользователей в отдельных подключениях. Однако большая часть этих вариантов должны ограничиваться одним прыжком. Только Kerberos с делегированием позволяет использовать исходное удостоверение пользователя для подключения нескольких компьютеров к хранилищу данных, размещенному на удаленном сервере.

NTLM

Резервной для подключений, в которых указывается SSPI=Negotiate, является подсистема проверки подлинности NTLM, которая используется, когда контроллер домена Kerberos недоступен. При использовании NTLM к ресурсу сервера может обращаться любой пользователь или клиентское приложение, если запросом является прямое подключение от клиента к серверу, у лица, запрашивающего подключение, есть разрешение на доступ к ресурсу, а клиентский и серверный компьютеры находятся в одном домене.

В многоуровневых решениях ограничение NLTM в один прыжок может стать большой проблемой. Удостоверение пользователя, осуществляющего запрос, может олицетворяться только на одном удаленном сервере и не может перемещаться далее. Если для текущей операции требуются службы, работающие на нескольких компьютерах, то в ограниченном делегировании Kerberos необходимо настроить повторное использование токена безопасности на внутренних серверах. Для передачи новых данных идентификации по подключению с одним прыжком можно также использовать сохраненные учетные данные или обычную проверку подлинности.

Проверка подлинности Kerberos и ограниченное делегирование Kerberos

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

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

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

Дополнительные сведения о настройке ограниченного делегирования в службах Analysis Services см. в разделе Configure Analysis Services for Kerberos constrained delegation.

Примечание

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

EffectiveUserName

EffectiveUserName — это свойство строки подключения, с помощью которого службам Analysis Services передаются данные идентификации. Power Pivot для SharePoint использует его для записи действий пользователей в журналах использования. Службы Excel и PerformancePoint могут с помощью этого свойства получать данные, используемые книгами и панелями мониторинга в SharePoint. Его также можно применять в пользовательских приложениях или скриптах, которые выполняют операции в экземпляре служб Analysis Services.

Дополнительные сведения об использовании свойства EffectiveUserName в SharePoint см. в разделе Использование свойства EffectiveUserName служб Analysis Services в SharePoint Server 2010.

Обычная проверка подлинности и анонимный пользователь

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

Для анонимной проверки подлинности можно задать удостоверение анонимного пользователя для определенной учетной записи пользователя Windows (IUSR_GUEST по умолчанию) или удостоверение пула приложений. Учетная запись анонимного пользователя будет использоваться для соединения со службами Analysis Services и должна иметь разрешения на доступ к данным в экземпляре служб Analysis Services. При использовании этого подхода в подключении используется только удостоверение пользователя, связанное с анонимной учетной записью. Если приложение требует дополнительного управления идентификаторами, необходимо выбрать какой-то другой вариант либо дополнить этот вариант собственным решением по управлению идентификаторами.

Обычный и анонимный режимы доступны только при настройке служб Analysis Services для доступа по протоколу HTTP, при этом установление соединения должно производиться с помощью IIS и msmdpump.dll. Дополнительные сведения см. в разделе Настройка http-доступа к службам Analysis Services в службах IIS 8.0.

Сохраненные учетные данные

У большинства служб приложений среднего уровня имеются функции для хранения имени пользователя и пароля, которые затем используются для получения данных из хранилища низкого уровня, например служб Analysis Services или реляционного механизма SQL Server. Как таковые сохраненные учетные данные являются пятым вариантом получения данных. Среди ограничений, связанных с этим методом, можно указать затраты на обновление имен пользователей и паролей и использование одного удостоверения в подключении. Если решению требуется удостоверение исходного инициатора вызова, то использовать сохраненные учетные данные невозможно.

Дополнительные сведения о сохраненных учетных данных см. в разделах Создание, изменение и удаление общих источников данных (SSRS) и Использование службы Excel со службой Secure Store в SharePoint Server 2013.

См. также:

Использование олицетворения при обеспечении безопасности транспорта
Настройка HTTP-доступа к службам Analysis Services в службах Internet Information Services (IIS) 8.0
Настройка служб Analysis Services для ограниченного делегирования Kerberos
SPN registration for an Analysis Services instance