Japan SharePoint Group 2015/03/14で使ったネタ。 （SharePointには全く関係なし） WebApplicationProxyを使った非ドメインデバイスから統合Windows認証アプリへのSSOの話 ＋Next Generation Credentials（NGC）とWindows10のCloud Domain Join（CDJ）の話

1. Microsoftの認証システムの歴史と
過渡期におけるWAPの活用
+Next Generation Credentials
2015.03.14
Naohiro Fujie（MVP for Forefront Identity Manager）
IdM実験室（http://idmlab.eidentity.jp）

2. 自己紹介
Blog
◦ IdM実験室（Identityに関することを徒然と）：http://idmlab.eidentity.p
Social
◦ Facebook Page : eIdentity（Identityに関するFeed）：https://www.facebook.com/eidentity
Web記事
◦ Windowsで構築する、クラウド・サービスと社内システムのSSO環境
（http://www.atmarkit.co.jp/fwin2k/operation/adsf2sso01/adsf2sso01_01.html）
◦ クラウド・サービス連携の基本と最新トレンド
（http://www.atmarkit.co.jp/fwin2k/operation/idftrend01/idftrend01_01.html）
◦ 開発者にとってのWindows Azure Active Directoryの役割と今後の展開
（http://www.buildinsider.net/enterprise/interviewvittorio/01）
その他
◦ 日本ネットワークセキュリティ協会（JNSA）アイデンティティ管理WG
（書籍：「クラウド環境におけるアイデンティティ管理 ガイドライン」etc）
◦ OpenID Foundation Japan
教育・翻訳WG（OAuth/OpenID Connect仕様翻訳）、エンタープライズ・アイデンティティWG
2

3. Microsoftの認証システムの歴史とこれから
統合Windows認証
(Windows95/NT-Current)
• LM⇒NTLM⇒NTLMv2⇒Kerberos
• WindowsPC、Windowsアプリ、
Webアプリ（IE）
Identity Federation
(WS2003R2-Current)
• ws-trust / ws-federation
/ SAML ⇒ OpenID
Connect
• Webアプリ
Next Generation
Credentials
(Azure/Windows 10-)
• Device、ネイティブアプ
リ、Webアプリ
3
PCの時代 Webの時代 デバイス＆サービスの時代

4. 統合Windows認証/NTLM
Challenge - Response
個別認証
4
出展：@IT
http://www.atmarkit.co.jp/fsecurity/hybooks/win_server_sec/ws
s01-01.html
Web/DBアプリへのログオン例

5. 統合Windows認証/Kerberos
Ticketベース
認証情報の引継ぎ
5
Web/DBアプリへのログオン例
出展：日経ITPro
http://itpro.nikkeibp.co.jp/article/COLUMN/20060518/238303/

6. Identity Federation（ID連携）
トークン（XML/JSON）ベース
認証情報を含むID情報を安全に
受け渡すための仕組み
6

7. 同列ではない（認証⇒ID連携）
方式 特徴 認証範囲 利用シナリオの例
NTLM 単なる認証の方法
（ID/PWDの検証方法）
認証システムとアプリ
ケーションの間のみ
PCへのログイン
アプリへのログイン（個別ログイン）
Kerberos 認証＋認証結果を連携す
るための仕組み
ドメイン（レルム）内
のみ
同一ドメイン内のPC、アプリ間でのSSO
（PCにチケットを保持、アプリアクセス
時はチケットをサービス用のチケットに
交換するので再度認証は不要）
SAML
ws-federation
OpenID Connect
認証結果を含むID情報
を連携するための仕組み
制限なし（信頼関係
/Circle of Trustを構築
した範囲内）
同じIdPを使っているアプリ間でのSSO
（ブラウザに認証Cookieを保持、別アプ
リからIdPへリダイレクトされても再度認
証は不要）
7
大きく考え方が異なる

8. 過去の資産との付き合い方
IT環境の変化
◦ クラウドの活用 ⇒ 境界の変化（ネットワーク境界を超えるIT利用）
◦ デバイスの変化 ⇒ 非ドメインクライアント（BYOD、スマホ、タブレット）
既存インフラはついていけるのか？
◦ 過去に構築した統合Windows認証のASP.NETアプリをタブレットから使うとページ
単位でIDとパスワードを聞いてくる・・・
◦ Federationに対応させるとなるとコストが・・・
8
一つの解としてのWeb Application Proxy

9. ドメイン（レルム）の範囲
Federation信頼の範囲（Circle of Trust）
PCログイン時に取得した
Kerberosチケットの有効範囲
ブラウザでログイン時に取得した
トークンの有効範囲
AD FSの役割はKerberosチケットと
SAMLトークンの変換（AD FSでの認証
をKerberosチケットで実施）
⇒KerberosレルムとCoTの橋渡し
AD FS
WAP
WAPの役割はSAMLトークンと
Kerberosチケットの変換
⇒CoTとKerberosレルムの橋渡し
9
WAP：Web Application Proxy（旧AD FS Proxy）
AD FS：Active Directory Federation Service

10. Demo
WAPを使い、非統合Windows環境よりSSOする
10

11. デモ環境
11
Kerberos認証する様に構成したアプリケーション
• SharePoint Central Administration
• Microsoft Identity Manager 2015 ドメイン参加した
WAPとAD FS
AD FS
SharePoint
MIM PortalAD DS
登録
WAP
リバプロ通信統合
Windows
認証 WAP経由の
アプリSSO利用
（AD FS経由で認証）

12. 前提事項（そしてはまりポイント）
そのアプリ、本当にKerberosで構成されている？
Kerberos Authentication Tester ver.0.9.3(beta)で事前にチェック。
http://blog.michelbarneveld.nl/media/p/33.aspx
※.NET Framework 3.5が必要
12
WAPサーバで起動し、対象URLを入
れて[Test]
⇒Authentication Type：Kerberos、
SPNにWAPに設定するSPNが表示さ
れていることを確認

13. まとめ①
WAPは単なるAD FS専用のリバプロじゃない
既存アプリをクラウドへ持っていく前の過渡期に活用できる
（かも）
対象アプリのKerberos構成の事前確認が大事
13

14. これからの話
Next Generation Credentials（NGC）と
Cloud Domain Join（CDJ）
14
【ご注意】
現在公開されている情報、および個人的な試行錯誤がベースと
なっているため、勘違いや今後の仕様変更などがある可能性が
非常に高いので取扱いにはご注意ください。

15. Next Generation Credentials(NGC)
◆課題
真のSSOへの道は険しい⇒非ドメイン環境でのデバイスログインとブラウザログイン
パスワードをいつまで使い続けるのか
15
◆クレデンシャルに関する議論
⇒パスワード
• 本当にその人のパスワードかどうかの保証がない
• 中間者攻撃（Man in the Middle）に弱い
⇒スマートカード
• 本人（持ち主）である保証の確率は比較的高い
• 対応したクライアントが必要
シンプルで安全なクレデンシャルが求められている
• なりすませない、傍受されない
• プラットフォームを選ばない

16. Next Generation Credentials(NGC)
基本的な考え方/特徴は以下の通り
秘密鍵と公開鍵のペア
秘密鍵はデバイスに残さない
秘密鍵はTPMで保護される
サーバは公開鍵を持つ
クライアントが秘密鍵で署名し、サーバが公開鍵で署名確認をする
FIDO、OAuth2.0 JWTの標準ベース
※tech days 2015 france & Google翻訳より
http://fr.slideshare.net/DecideursIT/sec303
16

17. Cloud Domain Join(CDJ)
Windows 10 Technical Preview 9926より利用可能
NGCを利用
Azure Active Directoryへドメイン参加（デバイス登録）
Azure ADアカウントでPCへログイン可能
セットアップ後はパスワードを使わず、PINでログイン
PCログインとアプリケーション・ログインのSSO（まだ限定的）
17

18. Demo
Windows10 TP 9926へAADアカウントでログインする
18

19. ステップ
1. デバイス登録
2. 鍵の生成と登録
3. ユーザ認証
4. アクセストークンの要求
19
セットアップ・フェーズ
認証・フェーズ
デモ

20. ステップ①：デバイス登録
20
• AzureADのDRS（Device Registration Service）へ
デバイス登録を試行
• AzureADの認証サービスでユーザ認証（MFAも利用
可能）し、DRSへのアクセストークンを受け取り、
DRSへデバイス登録
• DRSがデバイス証明書を送り返してくるのでデバイ
スに証明書をインストール

21. ステップ②：鍵の生成と登録
21
• Windows10デバイス側でユーザ鍵ペア、デバイス
鍵ペアを作成し、ユーザとデバイスそれぞれについ
てアテステーションblobを作成
• Azure AD鍵登録サービス（KRS）へ鍵登録要求を行
う（アクセストークン、公開鍵などを含む）
• Azire AD鍵登録サービスがNGC-KEYをデバイスへ
送り、デバイスはKGC-KEYを保持しておく

22. ステップ③：ユーザ認証
22
• AzureADの認証サービスにアクセス、NONCEを取
得する
• NONCEとNGC KEY-IDを秘密鍵で署名
• 認証要求
• プライマリ・リフレッシュトークンとアクセストー
クンを取得、対象鍵をTPMにインポートする

23. ステップ④：アクセストークンの要求
23
• KsKの生成
• AzureAD認証サービスにアクセストークンを要求
（要求時、ターゲットリソース情報、Kskを送信）
• アクセストークンを返却
現状はPCログインと一部サービスしかSSO出来な
いが、いずれOffice365などにも広がる（はず）

24. まとめ②
Password is dead！
やっぱりPCログインとサービスへのログインをSSOしたい
（ブラウザ/ネイティブ）
24

25. 参考）デモ時のWAP構成
25

26. 社内環境（統合Windows認証）
ドメインPC
SSO
26

27. 社外/スマホ（非統合Windows認証）
遷移するとID/PWDを
聞かれる（非SSO）非ドメイン
PC/スマホ
27

28. WAP経由
28
AD FSで認証された
後はSSO
非ドメイン
PC/スマホ

29. WAP構成
29
AD FSで事前認証する形でアプリ
ケーションを公開

30. AD FS構成
30
証明書利用者信頼に要求に非対応
のアプリケーションとして登録

31. Service Principal Name構成
31
Application Pool実行ユーザに
SPNを登録
WAPサーバに委任設定