この記事では、Windows Server での Kerberos の制約付き委任の新機能について説明します。
機能の説明
Kerberos の制約付き委任は、サービスで使用できるより安全な形式の委任を提供するために、Windows Server で導入されました。 構成されている場合、制約付き委任によって、指定されたサーバーがユーザーの代わりに動作できるサービスが制限されます。 これには、サービスのドメイン アカウントを構成するためのドメイン管理者特権が必要であり、アカウントを 1 つのドメインに制限します。 最新の企業では、フロントエンド サービスは、ドメイン内のサービスとのみ統合するように設計されていません。
以前のオペレーティング システムでは、ドメイン管理者がサービスを構成し、サービス管理者は、所有しているリソース サービスに委任されたフロントエンド サービスを知る方法がありませんでした。 また、リソース サービスに委任されるフロントエンド サービスは攻撃ポイントになる可能性がありました。 フロントエンド サービスをホストするサーバーが侵害され、そのフロントエンド サービスがリソース サービスに委任されるように構成されている場合、リソース サービスも侵害される可能性がありました。
Windows Server 2012 R2 および Windows Server 2012 では、サービスの制約付き委任を構成する機能がドメイン管理者からサービス管理者に転送されます。この方法で、バックエンド サービス管理者は、フロントエンド サービスを許可または拒否できます。
Kerberos プロトコルの Windows Server 2012 R2 および Windows Server 2012 の実装には、制約付き委任専用の拡張機能が含まれています。 Service for User to Proxy (S4U2Proxy) は、サービスがユーザー用の Kerberos サービス チケットを使用して、キー配布センター (KDC) からバックエンド サービスへのサービス チケットを取得できるようにします。 これらの拡張によって、バックエンド サービスのアカウントが別のドメインにあっても、そのバックエンド サービスに制約付き委任を構成できます。 これらの拡張機能の詳細については、MSDN ライブラリの [MS-SFU]: Kerberos プロトコル拡張機能: Service for User および制約付き委任プロトコルの仕様を参照してください。
実際の適用例
制約付き委任により、サービス管理者は、アプリケーション サービスがユーザーに代わって動作できる場所を制限することで、アプリケーションの信頼境界を指定して適用できます。 サービス管理者は、どのフロントエンド サービス アカウントがそれぞれのバックエンド サービスに委任できるのかを構成できます。
Microsoft Internet Security and Acceleration (ISA) Server、Microsoft Forefront Threat Management Gateway、Microsoft Exchange Outlook Web Access (OWA)、Microsoft SharePoint Server などのフロントエンド サービスでは、制約付き委任を使用して、他のドメイン内のサーバーに対して認証を行うことができます。 これにより、既存の Kerberos インフラストラクチャを使用して、ドメインをまたがるサービス ソリューションがサポートされます。 Kerberos の制約付き委任は、ドメイン管理者またはサービス管理者が管理できます。
リソースに基づくドメイン間の制約付き委任
Kerberos の制約付き委任を使用すると、フロントエンド サービスとリソース サービスが同じドメインにない場合に、制約付き委任を提供できます。 サービス管理者は、リソース サービスのアカウント オブジェクトでユーザーを偽装できるフロントエンド サービスのドメイン アカウントを指定することで、新しい委任を構成できます。
この変更によって追加される値は何ですか?
サービスでは、制約のない委任を使用する代わりに、制約付き委任を使用して他のドメイン内のサーバーに対する認証を行うことができます。 これにより、既存の Kerberos インフラストラクチャを使用するクロスドメイン サービス ソリューションの認証サポートが提供されます。フロントエンド サービスに対する信頼を必要とせずに、任意のサービスに委任できます。
これにより、サーバーが委任された ID のソースを信頼する必要があるかどうかの決定が、ドメイン管理者からリソース所有者への委任からシフトします。
動作の違いは何ですか?
基盤となるプロトコルに対する変更により、ドメインをまたがる制約付き委任が可能になります。 Kerberos プロトコルの Windows Server 2012 R2 および Windows Server 2012 の実装には、ユーザー間サービス (S4U2Proxy) プロトコルの拡張機能が含まれています。 これは、Kerberos プロトコルに対する一連の拡張であり、サービスがユーザー用の Kerberos サービス チケットを使用して、キー配布センター (KDC) からバックエンド サービスへのサービス チケットを取得できるようにします。
これらの拡張機能の実装については、MSDN の [MS-SFU]: Kerberos プロトコル拡張機能: Service for User および制約付き委任プロトコルの仕様を参照してください。
Service for User (S4U) 拡張機能と比較した場合の、転送された Ticket Granting Ticket (TGT) を使用した Kerberos の委任での基本的なメッセージ シーケンスの詳細については、[MS-SFU]: Kerberos プロトコル拡張機能: Service for User および制約付き委任プロトコルの仕様の、1.3.3 プロトコルの概要セクションを参照してください。
リソースベースの制約付き委任のセキュリティへの影響
リソースベースの制約付き委任では、アクセスするリソースを所有する管理者に委任を制御できます。 これは、委任するために信頼されているサービスではなく、リソース サービスの属性に依存します。 その結果、リソースベースの制約付き委任では、以前にプロトコルの移行を制御していた信頼された認証-for-Delegation ビットを使用できません。 リソースベースの制約付き委任を実行する場合、KDC はビットが設定されているかのように常にプロトコル遷移を許可します。
KDC ではプロトコルの移行が制限されないため、2 つの新しい既知の SID によって、この制御がリソース管理者に提供されます。 これらの SID はプロトコル遷移が発生したかどうかを識別し、必要に応じて標準のアクセス制御リストと併用してアクセスを許可または制限することができます。
| SID | Description |
|---|---|
| AUTHENTICATION_AUTHORITY_ASSERTED_IDENTITY S-1-18-1 |
クライアントの ID がクライアント資格情報の所有証明に基づいて認証機関によってアサートされることを示す SID。 |
| SERVICE_ASSERTED_IDENTITY S-1-18-2 |
クライアントの ID がサービスによってアサートされることを示す SID。 |
バックエンド サービスでは、標準の ACL 式を使用して、ユーザーがどのように認証されたかを判断できます。
リソース ベースの制約付き委任を構成する方法
ユーザーの代わりにフロントエンド サービスがリソースにアクセスできるようにリソース サービスを構成するには、Windows PowerShell コマンドレットを使用します。
プリンシパルの一覧を取得するには、プロパティ PrincipalsAllowedToDelegateToAccount パラメーターを指定して、Get-ADComputer、Get-ADServiceAccount、および Get-ADUser コマンドレットを使用します。
リソース サービスを構成するには、PrincipalsAllowedToDelegateToAccount パラメーターで New-ADComputer、New-ADServiceAccount、New-ADUser、Set-ADComputer、Set-ADServiceAccount、および Set-ADUser コマンドレットを使用します。