はじめに

 

PI Vision (旧PI Coresight) 及びPI AFではWindows認証を使用してPI Data Archiveやほかのサービスに

Windowsユーザの認証情報を渡す機能が標準で搭載されております。

この機能はKerberos認証という認証方法を用いて実現できますが、

実際Kerberos認証を設定するためには様々な知識が必要となります。

従来のNTLM認証をそのまま使用されてる場合、Kerberos認証を正しく設定する必要性が感じられないかもしれません。

但し、Kerberos認証によってよりセキュリティを強化し、正しく設定されておりましたら

Windowsユーザの認証情報をそのままPI Data Archive、PI AF、またはほかのサービス(RDB等)に認証情報を渡すことができるようになります。

 

この記事ではKerberos認証について説明し、更にPI VisionでKerberos認証を使用するための手順を説明します。

後半の部分は英語で公開されてる「Coresight Squared – What’s next? Kerberos and more..」記事に基づいて説明します。

 

Kerberosの簡易説明

 

まず、Kerberos認証について説明します。

 

Kerberos認証の目的はクライアントとサービスの間に両者が自分であることを証明し、

サービス側はそのクライアントの認証情報に基づいて適切な権限を与える仕組みです。

いわゆるNTLM認証みたいなネットワーク認証方法の一つです。

 

その仕組みを説明するためにはKerberos認証の用語を紹介する必要があります。

Kerberos認証で主に使われてる単語は以下の通りです。

 

Principal名 (略:PN)

Ticket Granting Server (略:TGS、訳:チケット付与サーバ)

Ticket Granting Ticket (略:TGT、訳:チケット付与チケット)

 

Kerberos認証では二つのPrincipal Nameが使われます。

そのPrincipal Nameは「User Principal Name」(略:UPN)と「Service Principal Name」(略:SPN)です。

UPNはドメインアカウント毎にて定義され、UPNは主にユーザ名とドメイン名を合わせることによって構成されております。

例としてユーザ名「rob」が「test.int」ドメインに登録された場合、そのユーザのUPNは「rob@test.int」となります。

SPNは登録されてるユーザやマシンで実行されてるサービスを定義します。

また、SPNは一つのWindows Forest内で重複されることはできません。

通常の場合、SPNは主にサービスが実行されるマシンに登録されておりますが、場合によってユーザアカウント

(サービス実行専用アカウント等)に登録されることもあります。

例としてSQL Serverが専用のサービスアカウントで実行されてる場合、

そのサービスアカウントに対して以下のSPNが登録されます。

 

MSSQLSvc/sqlserver.test.int:1433

 

PI VisionでKerberos認証を設定する場合、SPNが重要です。

特に、どのアカウントでどのSPNを登録するかによってKerberos認証が正しくできるようになります。

 

TGSはKerberos認証で使われてるチケットの発行マシンです。

多くの場合、これはドメインのドメインコントローラーになります。

 

TGTは最初にユーザがログインされた時、そのユーザに発行されるチケットです。

いわゆる、チケットを要求できるチケットです。

チケットはサービスに認証するため使われる物です。

 

それでは、結局PI Visionによって上記の仕組みがどう動くのかを説明します。

 

Kerberos認証とPI Vision

 

PI Visionのサーバを立てる時、一般的にPIサーバではなく、別のサーバをWebサーバとして設置し、

そのWebサーバ上にPI Visionを導入します。

この構成を取った場合、イメージとしては下記のとおりになります。

 

上記の図で実際何が起きてるかを順番で説明します。

 

1. ユーザがクライアントPCにログオンされた時、ドメインコントローラーにTGTを要求し、TGTが返されてきます。

 

2. PI Visionサーバに登録されてるPI Visionサービスにアクセスするため、

 1で貰ったTGTを使用しPI Visionサービス用のチケットを要求します。

 TGTに問題がなければ、PI Vision認証用のチケットが発行され、クライアントPCに送られます。

 

3. クライアントPCはPI Visionサーバに接続し、1で貰ったTGTと2で貰ったPI Vision認証用のチケットを送ります。

 

4. PI Visionサービスは3で貰ったクライアントユーザのTGTを使ってPI Data ArchiveやPI AFサーバ認証用のチケット発行を要求します。

 

5. 4で貰ったチケットを使用し、PI VisionサービスがクライアントユーザとしてPI Data ArchiveやPI AFサーバに接続し認証されます。

 

上記の手順で重要な点は以下の三つです。

 

  • PI Visionサービスアクセス用のチケット (2)
  • PI VisionサービスがTGTを取り扱える許可 (3)
  • PI VisionサービスがTGTを使って発行できる認証用チケット (4)

 

まず、PI Visionサービスにアクセスするためチケットの発行が必要となります。

TGS(ドメインコントローラー)がPI Visionサービスに対してチケットを発行するためには

PI Vision実行ユーザ(NETWORK SERVICE等の場合はマシン)に対してSPNを登録する必要があります。

SPNが存在しない場合、TGSの観点からはそのサービスが存在しないことになり、チケットは発行されません。

すなわち、SPNが登録されてないサービスについてチケット要求をTGSに送っても何も返ってきません。

この場合、Kerberos認証は失敗し、ほかに設定されてる認証方法(NTLM等)を使う必要があります。

 

二つ目のポイントはPI VisionがユーザのTGTを扱う権限です。

デフォルト設定では、ほかのマシンやユーザがTGTを扱える権限を持っておりません。

そのため、PI Visionの実行ユーザに対して明示的にTGTを扱えるように設定する必要があります。

この設定はドメインコントローラー上で行うこと、またはADの編集権限を持つアカウントで

AD編集機能が追加されてるパソコンで設定の編集を行います。

 

三つ目は制約付きKerberos認証が必要です。

PI Coresight 2016 R2から必要となっておりますが、制約付きKerberos認証では

PI Vision実行ユーザが代理で発行できるSPNを定義します。

通常の場合、これはPI Data ArchiveとPI AFのSPNになります。

 

それでは、実際上記の設定を行う手順について説明します。

 

PI VisionのKerberos認証設定手順

 

まず、下記三つのサーバーが存在すると仮定します。

 

  • PIServer.domain.int - PIサーバー (PI Data Archive、PI AFマシン)
  • PIWebServer.domain.int - PI Vision用サーバー
  • DC.domain.int - 「domain.int」ドメインのドメインコントローラーサーバー

 

今回の場合、PI Visionのアプリケーションプールユーザーはデフォルトの「NETWORK SERVICE」と指定します。

では、早速手順を見てみましょう。

 

まず、IIS側でKerberos認証を使用するために下準備を行います。

 

1. Windows認証の有効化

 

IISマネージャーを開き、PI Visionがインストールされているウェブサイトを選択し、

「認証」の項目を選択してください。

認証画面が表示されます。

この画面で「Windows認証」が有効化されていることを確認してください。

 

2. カーネルモード認証の設定

 

上記の1の画面から「Windows認証」を右クリックし、詳細オプションを選択してください。

ここで「カーネルモード認証」のオプションが表示されますが、

こちらが有効化されていることを確認してください。

 

なお、この設定が有効化されていて、カスタムアカウントでPI Visionを

実行する場合、下記の追加作業が必要です。

 

  • PI Visionがインストールされているウェブサイトを選択し、「構成エディター」を選択してください。
  • セクションの欄に下記の文書を記入し、Enterキーを押してください。

system.webServer/security/authentication/windowsAuthentication

  • 中央の画面で「useAppPoolCredentials」の項目を有効化(True)に設定してください。

 

もし上記の作業ができない場合、カーネルモード認証を無効化する必要があります。

 

3. Kerberos認証が可能な状態に設定

 

先ほどの1と2の同じ画面に戻り、「Windows認証」を右クリックし、「プロバイダ」項目を選択してください。

プロバイダの設定画面が表示されます。

ここで「Negotiate」が一番上にあることを確認してください。

「Negotiate」が一番上に存在しない場合、Kerberos認証が行われない可能性があります。

 

IISの下準備はこれで以上になります。

 

続いて、Kerberos認証の設定に移ります。

設定の手順は主に下記の3点で説明できます。

 

  • PI Vision用のSPN作成
  • PI AFやPI Data ArchiveのSPN作成確認
  • 制約付きKerberos認証定義 (Constrained Delegation)

 

それでは、順番に設定方法を案内します。

 

1. PI Vision ウェブサイトアプリケーションプールユーザーに対してSPNを作成

 

PI Visionアプリケーションプールユーザー(NETWORK SERVICE)に対してSPNを作成します。

SPN作成のためにはドメイン管理者権限が必要となります。

 

ドメイン管理者権限を所有するアカウントで管理者権限のコマンドプロンプトを

ドメインに参加しているマシンのいずれかで実行し、下記のコマンドを実行します。

 

setspn -S HTTP/PIWebServer.domain.int PIWebServer
setspn -S HTTP/PIWebServer PIWebServer

 

こちらのコマンドを実行することでSPNが作成されます。

正しく作成されたことを確認するためには下記のコマンドを実行してください。

 

setspn -Q HTTP/PIWebServer

 

なお、こちらのコマンドはどのドメインユーザーでも実行できます。

 

2. PI AFやPI Data ArchiveのSPN作成確認

 

制約付きKerberos認証を設定する必要があるため、

PI Visionの接続先にもSPNが定義されている必要があります。

PI Data Archiveの場合、PI Network Subsystemの実行ユーザーに対して

「PIServer/PIDataArchiveホスト名」のSPNを作成する必要があります。

PI AFの場合、PI AF Application Serviceの実行ユーザーに対して

「AFServer/AFServerホスト名」のSPNを作成する必要があります。

 

SPNの作成方法は上記の1と同じになります。

 

3. 制約付きKerberos認証の定義

 

Kerberos認証を使用する場合、以下四つの認証方法があります。

  • 制約付き委任(Kerberosのみ) (英:Constrained Delegation - Kerberos Only)
  • 制約付き委任(すべての認証プロトコル) (英:Constrained Delegation - Any Authentication Protocol)
  • リソースに基づく制約付き委任 (英:Resource based constrained delegation) (Windows Server 2012から実装、GUIから設定不可能)
  • 制約のない委任 (英:Unconstrained Delegation) (非推奨)

 

PI Visionのマニュアルでは「制約付き委任(すべての認証プロトコル)」の設定方法について説明しております。

マニュアルは下記のリンク先でダウンロードできます。 (PI Coresight 2016 R2の日本語マニュアル)

 

https://techsupport.osisoft.com/Downloads/File/83e7f716-0c7b-444b-a0bb-ad3ae6c9cb9b

Kerberos委任設定の手順は49ページから記載されております。

 

こちらでは「リソースに基づく制約付き委任」について説明します。

 

リソースに基づく制約付き委任のKerberos認証方法はWindows Server 2012から

新たに実装された機能です。

こちらの機能を使うことで委任設定を委任元(今回の場合はPI Visionアプリケーションプールユーザー)に

紐付く必要がなく、すべての設定は委任先(PI AFとPI Data Archive)に紐付けられます。

また、ほかの認証方法と違って、設定する際にドメイン管理者権限が要りません。

詳しくは下記のリンク先(Microsoft社のKerberos認証の新機能説明記事)をご参照ください。

 

https://technet.microsoft.com/ja-jp/library/hh831747(v=ws.11).aspx

 

なお、リソースに基づく制約付き委任のKerberos認証を使うためには下記の条件を満たす必要があります。

  • ドメインのレベルがWindows Server 2012以上
  • 委任元の端末(今回ではPI Vision用のサーバ機)がWindows Server 2012以上
  • 委任先のADオブジェクトに対して「Write account restrictions」の権限 (委任設定ユーザーのみ必要)

 

それでは、リソースに基づく制約付き委任を設定します。

設定する端末にはPowerShellのActive Directoryモジュールがインストールされている必要があります。

 

PowerShellを立ち上げて下記のコマンド文を実行してください。

 

$frontendidentity = Get-ADComputer -Identity PIWebServer
$backendidentity = Get-ADComputer -Identity PIServer
Set-ADComputer $backendidentity -PrincipalsAllowedToDelegateToAccount $frontendidentity
Get-ADComputer $backendidentity -Properties PrincipalsAllowedToDelegateToAccount

 

上記の1行目と2行目は委任元と委任先を変数に保存しております。

保存後、3行目のコマンドで委任先に対して委任できる委任元として設定します。

4行目は確認用のコマンドです。

 

こちらの例文はPIWebServerのKerberosチケットをPIServerのサービスに委任できるように設定しております。

今回の場合、こちらのコマンドでPI ServerとAF Server両方の委任設定が完了されますが、

もしAF Serverのサービスが別のユーザーアカウントで実行されている場合、「$backendidentity」の変数を変えて

再度コマンド文を実行する必要があります。

 

以上でKerberos認証の設定が完了されます。

 

まとめ

 

PI VisionとKerberos認証に関しては以上となりますが、いかがでしたでしょうか。

Kerberos認証は相当奥が深い課題ですが、本記事ではできるだけ

PI Visionに関する項目だけを説明しております。

もしほかにKerberos認証について説明が望ましい場合、是非Microsoft社が公開されている記事をご参照ください。

 

上記の手順を実行した後、PI VisionからPI Data ArchiveやPI AFへの接続はKerberos認証が行われ、

PI Visionにアクセスしているユーザーとして権限を持ち編集やデータの閲覧等ができます。

 

PI Visionからイベントフレームにコメントを書き込む作業や

PI Vision 2017で追加されたXYプロットを使用するためにはKerberos認証が必要です。

また、PI Web API経由で処理を行うカスタムシンボルをPI Visionで使用する場合、

Kerberos認証が必要になります。

 

今後の新しい機能を活用するためやPI Visionを更に活用するために

是非Kerberos認証を設定することをご検討ください。