hzhao

Coresight系列讨论 - Kerberos和更多

Blog Post created by hzhao Employee on Aug 19, 2016

接上一个系列:Coresight 系列讨论 - Coresight 安装 ,原文链接为:Coresight Squared – What’s next? Kerberos and more..

 

该系列目前包括三部分:

Server核心版的安装和配置

PI Coresight的安装

Kerberos配置及更多 << 您在这

 

到这里,Coresight已经可以使用了,不过我们这个系列还没有结束,我们将会谈谈大家最喜欢的三头怪(Kerberos是希腊神话中的一个三头狗)Kerberos

声明:

这篇文章中不会涉及Kerberos端口如何工作的技术细节,也不会包含Kerberos的troubleshooting。(可能会在下一次会谈)。与之对应的是我们会将如何利用Kerberos认证和Kerberos委任来加强PI系统的安全性。

 

Coresight - IIS 设置

 

在配置 Kerberos之前,确保 Kerberos 验证在PI Coresight 上是可行的。

 

1. 启用 Windows Authentication(Windows 认证)

选择 Coresight Web Application > Authentication Settings:

2. 启用 Kernel-mode Authentication

右键点击 Windows Authentication > Advanced Settings... > 确保Kernel-mode authentication是被启用的:

 

 

 

 

按照上面的描述,Microsoft 推荐保持启用Kernel-mode 认证。一些关于Kernel-mode 认证对于性能的好处的数据可以在这里看到

 

如果Kernel-mode 认证被:

  • 启用, Kerberos 票据默认用Local System 账户解码.
  • 禁用, Kerberos 票据默认用app pool 账户解码.


这样的话,如果Coresight AppPools以如下用户运行:

  • 虚拟或者机器账户 (比如Network Service) - 不需要更多操作

 

  • 自定义域账户 - 启用 AppPool 账户来解码 Kerberos 票据:
    IIS Manager 中,选择Coresight Web Application > Configuration Editor > 导航到 system.webServer/security/authentication/windowsAuthentication > 设置 useAppPoolCredentialsTrue。这保证了 AppPool 用户是被用户解码传数过来的Kerberos票据的,允许Kerberos认证可以正常工作。

 

3. 使 Kerberos 认证 成为可能

右键点击 Windows Authentication > Providers... > 确保 Negotiate provider是列表中的第一个选项. 比如:

 

Kerberos 简化版: “三个头”

为了尽可能简化,让我们考虑三个主要的关注点:

1. 前端服务器主体名称(SPN,Service Principal Name) - Coresight 终端用户需要能够使用 Kerberos 认证来登录 Coresight (前端服务)

2. 端服务器主体名称(SPN,Service Principal Name)PI 或者 AF Server ( 后端服务) 需要可以接受Kerberos请求 (委任的凭据)

3. Kerberos 委任 - Coresight 服务用户 (前端服务身份) 需要被允许去委任终端用户的凭据给后端服务 (PI or AF Server)

 

第一头: 前端服务器主体名称


一个服务器主体名称是一个服务实例唯一标识符。 服务器主题名称(SPNs)被Kerberos 认证用于将一个服务实例和服务账户联结起来。

服务主体名称能够被分成两部分(这里省略了端口号和服务名,因为它们和我们的内容不大相关)

 

服务类/目标主机, 被安排到一个合适的服务账号.

 

服务类(ServiceClass) – 一个指明服务普通类的字符串。和PI系统有关的常用的服务类包括:

PI Data Archive – PIServer

PI AF Server – AFServer

PI Coresight – HTTP

无论Coresight是不是用了SSL,服务类都是HTTP!

 

目标主机(TargetHost) - 服务运行的机器的主机名和全域名。对Coresight服务器总是既创建两个服务主体名称(SPN)一个给主机名,另一个给全域名!

 

服务账号(ServiceAccount) – 运行服务的用户,如果是:

域账户 - 服务器主体名称(SPN)是被安排给实际存在的运行服务的域用户

虚拟或者机器账号 (Network Service, NT Service\Service 等.) – 服务器主体名称(SPN)被安排给计算机(服务在运行的那台)

 

服务器主体名称(SPNs)可以用 setSPN.exe 工具来创建 (在命令行中可用). 在大多数环境下,创建新的服务器主体名称需要域管理员的权限

 

为了OSI\CoresightSVC 运行的PI Coresight 创建服务器主体名称(SPN), 在 Core01.it.local 机器上运行:

setspn -S HTTP/Core01.it.local OSI\CoresightSVC  
setspn -S HTTP/Core01 OSI\CoresightSVC

为了用Network Service运行的PI Coresight 创建服务器主体名称(SPN),在Core01.it.local 机器上运行:

setspn -S HTTP/Core01.it.local Core01  
setspn -S HTTP/Core01 Core01  

 

用setSPN.exe来验证是否服务器主体名称(SPNs)已经被正确创建和安排。

 

列举安排给某一个域账户所有的服务器主体名称(SPNs):

setspn -L domain\account  
Example: setspn -L OSI\CoresightSVC 

 

检查特定的SPN是否存在

setspn -Q SPN  
Example: setspn -Q HTTP/Core01  

 

第二头: 后端服务器主体名称

 

相同的适用于前端的服务器主体名称的原则也适用于后端。保证合适的 (PIServer/TargetHost and AFServer/TargetHost, 分别) SPNs 被安排给正确的服务用户 (PI Network Manager 服务账号 对应PI Data Archive; PI AF Application Service 的服务账号 对应AF的).

 

第三头: Kerberos委任

 

一旦Kerberos委任被启用,前端服务 (PI Coresight) 可以委任终端用户的凭据给后端服务 (PI Data Archive 或者 PI AF Server) 从而保证终端用户用安全的方法读取后端的数据。

 

在我们的案例中, Coresight 服务用户需要被允许委任终端用户的凭据给 PI Data Archive. 从PI Coresight 2016开始,对AF Server的Keberos 委任对于给Event Frame添加注释是必须的。

 

有三种主要的Kerberos委任的方式:

  • 通常的 (不约束的) 委任
  • 约束委任


  • 按资源的委任

要了解更多信息,请参阅 KB01222 - Types of Kerberos Delegation. 我们将使用最新的方式 – 按照资源的委任。这种方法有多个好处,主要有:

  • 用于委任的权限与后端关联而不是前端
  • 不需要域管理员特权
  • 可以跨域或者跨森林工作

这对于非IT管理员用户是一个非常好的消息,因为它允许后端资源的管理员,如PI Data Archive和PI AF的管理员来控制是否这些资源接受被委任的凭据。 但是要使用基于资源的约束委任也有一些要求。

  • 前端和后端账户域都必须有Server 2012或更高等级的Kerberos分配中心
  • 前端服务器必须安装在Windows Server 2012或更高版本的操作系统上

 

要配置基于资源的约束委任,在Powershell中使用活动目录命令集

下面的例子是给 用域用户 picoresight 运行的PI Coresight和用默认虚拟账户NT Service\AFService 运行的AF Server PIAF01

 

分步指导:

 

1. 获得前端和后端服务标识。如果服务用一个域账户运行,用Get-ADUser。如果用机器账号如 Network Service 或者一个虚拟账号运行, 使用 Get-ADComputer.

$frontendidentity = Get-ADUser -Identity picoresight  
$backendidentity = Get-ADComputer -Identity PIAF01 

2. 安排 front-end identity(前端标识)back-end identity(后端标识)  PrincipalsAllowedToDelegateToAccount 属性

 

Set-ADComputer $backendidentity -PrincipalsAllowedToDelegateToAccount $frontendidentity 

 

3. 观察更新后的后端身份标识的 PrincipalsAllowedToDelegateToAccount 属性,验证它是被合理设置的:

 

Get-ADComputer $backendidentity -Properties PrincipalsAllowedToDelegateToAccount 

 

 

另外:

 

允许多个主体委任给相同的后端,设置 PrincipalsAllowedToDelegateToAccount 给所有需要的标识,以逗号隔开:

 

Set-ADComputer $backendidentity -PrincipalsAllowedToDelegateToAccount $frontendidentity1, $frontendidentity2 

 

 

如果有多个域参与其中,当指定Get-ADUser时指定更多标准,下面这个例子包含了-Server 参数来指定一个标识所在的域控制器:

$frontendidentity = Get-ADUser -Identity picoresight -Server piDC01.pidoge.local 

 

推荐 Kerberos 阅读

OSIsoft: Kerberos Authentication and web browsers

How Windows Server 2012 Eases the Pain of Kerberos Constrained Delegation, Part 1

How Windows Server 2012 Eases the Pain of Kerberos Constrained Delegation, Part 2

If there are multiple domains involved, specify more criteria when executing the Get-ADUser cmdlet. The example below includes the -Server parameter to specify a DC of the domain where the identity resides:

Outcomes