active directory をinternetから使用するための4つのシナリオ
Post on 03-Jul-2015
9.169 Views
Preview:
DESCRIPTION
TRANSCRIPT
1
マクロソフト株式会社 エバンジェリスト
あんのう じゅんいち
安納 順一 http://blogs.technet.com/junichia/
T6-303
2
このセッションの目的
このセッションでは、 ンターネットからゕプリケーションサーバーへのゕクセスを Active Directoryで認証することが、
どのようなメリットをもたらすのか そしてそれは果たして可能なのか? できるとしたら、トレードオフが発生するのか?
についてお話します。 もちろん、
「うーん、うちには適用できないな」 と言う結論に達する可能性もあります。 みなさんが抱えている案件を思い浮かべながら お聞きください。
3
想定しているシナリオ ゕプリケーションを社内、社外両方から同様に使用する 利用者は社員または外部利用者(パートナー企業やパートタマー)
Remote Desktop Service
Direct Access
VPN
Federation
いっそのこと Cloud? Hungry..
Reverse Proxy
4
DMZ
Active Directory Domain
DC DC
INTRANET
もっともシンプルなのは?
理想的な構成
Internet
外からも使いたいゕプリケーションはDMZに設置し、必要な認証サーバーもDMZ上に構築する。もちろんユーザーは全てDMZ上の認証サーバーに登録。
DMZにAD DS置いて認証! きまりです!
5
そんなの怖くて....
6
Agenda
計画 どのような構成が考えられるのか - 4つの展開モデル - RODCについて
設計 RODCをDMZに展開するにあたり全体設計に影響する 7つの考察
7
略語一覧
略語
AD DS Active Directory Directory Service
SSO Single Sign-On
Appサーバー ゕプリケーションサーバー
DC Domain Controller
GP Group Policy
PII Personally Identifiable Information
HBI High Business Impact
RODC Read Only Domain Controller
RWDC Read-Writable Domain Controller
FRS File Replication Service
DFSR DFS Replication
DFS Distributed File System
8
DMZにAD DS を展開するにあたり、 事前に何を考慮しなければならないのか
9
考慮事項
IDに要求されることは何か?
IDの集中管理が必要か?
SSOに対するニーズは?
個人情報の漏洩についてどの程度の対策が求められるか?
ゕプリケーションが使用する情報はAD DSに格納されるか?
10
4つの展開モデル
モデル1:AD DSを使わない
モデル2:分割フォレスト
モデル3:フォレスト間信頼
モデル4:拡張フォレスト
11
モデル1:AD DSを使わない
モデル2:分割フォレスト
モデル3:フォレスト間信頼
モデル4:拡張フォレスト
12
DMZ
モデル1:AD DSを使用しない
DMZ上のゕプリケーションサーバーは独自に認証DBを持つ
INTRANET
Active Directory Domain
Internet
ユーザー情報の格納庫:
ユーザーの利便性:
管理性:
安全性:
構築の容易性:
SAM、DB、ハードコーデゖング・・・・
独自のID/パスワード,SSO不可能
ゕプリ個別に管理
Appサーバーに依存。IDが分散するため、セキュリテゖポリシーの統一が困難。
複数のデゖレクトリ
13
モデル1が合致する条件
IDに要求されることは何か? 特に無い。ゕプリの認証が行えればそれでよい
集中管理された管理が必要か? ゕプリケーションサーバー数とユーザー数はさほど多くないので必要ない
どんなSSOへのニーズがあるのか? シングルサンオンの恩恵を受けるユーザーはいないので必要ない 独自のSSOの仕組みを構築している
情報漏洩についてどの程度の対策が求められるか?
ユーザーIDを含め社内データの一切の漏えいは認められないため、
DMZへの登録も禁止する
アプリケーションが使用する情報はAD DSに格納されるか? AD DSを使用するゕプリケーションは存在しない AD DSに対応させるための改修を行いたくない
14
モデル1:AD DSを使わない
モデル2:分割フォレスト
モデル3:フォレスト間信頼
モデル4:拡張フォレスト
15
DMZ INTRANET
モデル2:分割フォレスト ンターネットゕプリケーション用に新しいフォレストを構築 社内フォレストとの信頼関係は構築しない DMZ内でゕプリサーバーの認証を統合することが可能
安全性:
管理性:
構築の容易性:
ユーザー情報の格納庫:
ユーザーの利便性:
DC DC
Internet
AD DS
DMZ内は統一。内部と異なるID/パスワードとなる可能性がある
内部とは完全に個別管理するか、同期が必要
DMZドメンへのゕタックによりAppサーバーが危険。
DMZで共通のデゖレクトリ。ゕプリ設計必要
16
モデル2が合致する条件
IDに要求されることは何か?
DMZ上で使用するIDは完全に社内のIDと分断されていてほしい
集中管理された管理が必要か?
複数のAppサーバーがあるのでDMZ内で使用するIDの集中管理は必要だ
し、今後サーバーが増えればGPでAppサーバーの制御も行いたい
どんなSSOへのニーズがあるのか?
社内ネットワークとのSSOは望ましくないが、DMZ上のAppサーバー間
でのSSOができると便利
情報漏洩についてどの程度の対策が求められるか?
ユーザーIDを含め社内データの一切の漏えいは認められないため、DMZ
への社内IDの登録を禁止する
アプリケーションが使用する情報はAD DSに格納されるか?
Appサーバーの中にAD DSを使用するものがあり、AD DSへの書き込み
も発生する
17
モデル1:AD DSを使わない
モデル2:分割フォレスト
モデル3:フォレスト間信頼
モデル4:拡張フォレスト
18
DMZ
DC
INTRANET
DC
モデル3:フォレスト信頼モデル ンターネットゕプリケーション用に新しいフォレストを構築 社内フォレストとの信頼関係を構築し、社内からのゕクセスはSSOを実現 DMZ内でゕプリサーバーの認証を統合することが可能
Internet
構築の容易性:
ユーザー情報の格納庫:
安全性:
管理性:
ユーザーの利便性:
信頼関係
AD DS
DMZで共通のデゖレクトリ。ユーザーIDの登録は必要ない
ユーザーIDは内部で一元管理可能
DMZドメンへのゕタックによりAppサーバーが危険にさらされる。
ユーザーは社内ドメンで
19
モデル3が合致する条件 IDに要求されることは何か?
ユーザーIDは完全に統合したい。
集中管理された管理が必要か?
複数のAppサーバーがあるのでDMZ内で使用するIDの集中管理は必要
だし、今後サーバーが増えればGPでAppサーバーの制御も行いたい。
ただし、DMZと社内の管理は分かれても良い。
どんなSSOへのニーズがあるのか?
社内ネットワークとのSSO環境が望ましい
情報漏洩についてどの程度の対策が求められるか?
ユーザーIDを含め社内データの一切の漏えいは認められないため、
DMZへのユーザーIDの登録も禁止する。
アプリケーションが使用する情報はAD DSに格納されるか?
Appサーバーの中にAD DSを使用するものがあり、AD DSへの書き込
みも発生する。内部ADに書き込みを許可するかどうかは要検討。
20
モデル1:AD DSを使わない
モデル2:分割フォレスト
モデル3:フォレスト間信頼
モデル4:拡張フォレスト
21
INTRANET DMZ
DMZと社内をまたいだ同一ドメン ゕカウントは完全なる一元管理 DMZにはRODCを展開
モデル4:フォレスト拡張
RODC Internet
構築の容易性:
ユーザー情報の格納庫:
安全性:
管理性:
ユーザーの利便性:
AD DS
考慮事項が多数あり
完全に同一IDとパスワードを使用可能。
覚えるべき操作はあるものの、社内と完全に統一された管理環境。
読み取り専用であってもセキュリテゖポリシーによっては情報漏洩の可能性は存在。改ざんは防衛可能。
RWDC 複製
22
モデル4が合致する条件 IDに要求されることは何か?
IDはコンピューターゕカウントを含め集中管理したい。
集中管理された管理が必要か?
複数のAppサーバーがあるのでDMZ内で使用するIDの集中管理は必要。
管理コストを下げるために、ドメン数は極力減らしたい。
どんなSSOへのニーズがあるのか?
社内ネットワークとのSSO環境が望ましい
情報漏洩についてどの程度の対策が求められるか?
社内AD DSの PII や HBI がDMZを介して社外に漏えいしない
アプリケーションが使用する情報はAD DSに格納されるか?
ゕプリケーションはAD DSに格納された情報を使用するが、書き込み
は発生しない。また、RODC互換ゕプリである。
23
構築の容易性:
安全性:
管理性:
ユーザーの利便性:
ユーザー情報の格納庫:
展開モデルのまとめ
モデル1 No AD DS
モデル2 分割フォレスト
モデル3 フォレスト間信頼
モデル4 拡張フォレスト
AD DS AD DS AD DS 独自
SAM 等
24
拡張フォレストモデルで使用されるRODCには どのようなメリットと制限事項が存在するのか
25
RODC とは? Windows Server 2008 から実装された読み取り専用のドメンコントローラ
RODCの優れた点
ドメンコントローラである セキュリテゖ
読み取り専用である(AD,DNS,Sysvol) 一般ユーザーにRODC専用の管理を委任できる RWDCから複製を受け取るだけである RWDCからの複製を属性単位でフゖルタリング(FAS) 独自の krbtgt ゕカウント パスワード複製ポリシー(PRP) 緊急時のパスワードリセット機能 RODCで認証したユーザーの捕捉 Server Core 上に構築可能
RODCの考慮事項 フォレストとドメンの機能レベル スキーマ拡張 修正モジュールの適用(2003/XP/Vista) ゕプリケーションとの互換性 PIIとHBI の漏洩防止
26
RODCの考慮事項 ①
フォレスト機能レベル :Windows Server 2003以上 - Linked-value replication (LVR) 機能
ドメン機能レベル :Windows Server 2003以上 - Kerberos の強制委任機能
Windows Server 2008 スキーマに拡張 - Windows Server 2008 DC が必須
2008 RWDC は RODC と同一ドメンに展開 - RODC の複製元は 2008 RWDC とする
RODC
2008 RWDC
2003 RWDC
27
RODCの考慮事項 ②
修正モジュールの適用(2003/XP/Vista) KB944043 http://support.microsoft.com/kb/944043/en-us
グループポリシーのWMIフゖルタが正しく適用されない
RODCからIPSecポリシーを受信できない
RODCと時刻同期が行えない
クラゕントがドメンに参加できない
パスワード変更が行えない
クラゕントのData Protection API (DPAPI)がマスターキーを複合で
きない。
プリンタをADに公開しようとすると失敗する
ADに公開されたプリンタの検索を行うとダゕログボックスの応答が無
くなる
ADSIのリクエストが常に書き込み可能なドメンコントローラに送ら
れてしまう
Windows Server 2003 ドメンコントローラが、RODCを含んだサ
トの自動サトカバレッジを実施してしまう
修正一覧
28
RODCの考慮事項 ③ アプリケーションとの互換性
■大原則:RODCには書き込めない!
読み取り操作が非効率的になったり失敗する
ADSIは規定ではRWDCを検索するため
ADsOpenObject 関数の呼び出しに ADS_READONLY_SERVER を使
用する(使用しなければ書き込み可能なDCのみが検索される)
書き込み操作が失敗する
RODCは書き込み要求に対して RWDC への referral を返す
ゕプリケーションがRWDCと直接通信が行えなければならない
書き込み-再読み取り操作が失敗する
書き込んだデータがRODCに複製されるまでのタムラグのため
書き込んだDCを読み取りに使用する
参考~ADSIゕプリケーションとRODCの互換性 http://technet.microsoft.com/ja-jp/library/cc772597(WS.10).aspx http://technet.microsoft.com/ja-jp/library/cc753644(WS.10).aspx
4
29
DMZ
RODC
INTRANET
RWDC
RODCに書き込みが発生した場合の動作
①RWDCを照会
②RWDCと 直接通信
③RWDC から複製
ゕプリケーションサーバーとRWDCの通信が可能でなければならない
30
(参考)RODCによる書き込みのForward
パスワード変更 Service Principal Name(SPN)の更新 Netlogonサービスによるクラゕント属性の変更
client name DnsHostName OsVersionInfo OsName Supported Encryption Types LastLogonTimeStamp
RODCは一部の属性の書き込み要求をRWDCにForwardする
DMZ INTRANET
RODC RWDC
書き込み
書き込み依頼
31
INTRANET
RODCの考慮事項 ④ PII と HBI の漏洩防止
※PII: Personally identifiable information
※HBI:High business impact
FAS(Filtered Attribute Set)の適用
DMZ
RODC RWDC
複製を フゖルター
FAS
ユーザーID 氏名 住所 性別 電話番号 所属 健康保険番号....
ユーザーID
32
RODCが設計に及ぼす影響
33
展開モデル4のおさらい
DMZ INTRANET Internet
RODC RWDC
Active Directory Domain
34
設計に影響する7つの事項+1
1. RODC への昇格 2. DNS の更新 3. RODC の管理者 4. 慎重に扱うべき情報 5. RODC と RWDC の複製トポロジ 6. RODC の通信モデル 7. Appサーバーのドメンへの参加 + 8. SYSVOLの整合性
モデル4を採用するにはRODCに関して考慮すべき事項が存在する
35
1.RODCへの昇格
設計に影響するポイント
どちらのネットワーク(DMZ or 内部)で昇格させるか 昇格の際に発生するRODC-RWDC間の通信を確保 昇格時にDNSに登録されるレコード
昇格の手順
通常の昇格手順では管理者IDが必要となるが、 2ステージンストールでは管理者権限は要求されない
2ステージンストール方式を使用してDMZ内から昇格
Server Core を使用する
推奨
※通信については「4.RODCの通信モデル」参照
36 DMZ INTRANET
RODC RWDC
(参考)2ステージンストール
事前に RODC ゕカウントを作成しておき、DMZ専用の管理者ID(Domain Adminsである必要はない)にンストールを委任することが可能
ゕカウント作成時にウゖザードを使用して必要情報を事前指定 DMZでのンストールはほぼ自動的に完了
Stage2 作成したゕカウントにゕタッチ
Dcpromo /UseExistingAccount:Attach レプリケーション元の指定 管理ゕカウントを指定 RODC コンピュータゕカウントを選択 その他は従来の Active Directory と同様の情報
を指定
Stage1
[ Active Directory ユーザーとコンピュータ ] の [ Domain Controllers ] OU を右クリック
RWDC上にRODCのコンピュータゕカウントを作成する
37
2.DNSの更新 設計に影響するポイント
RODCは書き込み可能なAD統合ゾーンを保持していない DNSクラゕントからの更新を受け付けられない SOA(start of authority)クエリーに対しRWDCを返す
手動更新か動的更新か 動的な場合クラゕントはRWDCと直接通信しなければならない
どの名前空間を公開すべきか
選択肢 DNSを使用しない(HOSTSフゔルで名前解決) 手動で管理する(Appサーバーが少ない場合には最適) Appサーバー-RWDC 間のポートをオープンして DHCPサーバーに動的更新を行わせる
DHCPサービスのゕカウントを 明に設定すること MACゕドレスでリース予約
すること 事前に以下のグループを作成
しておくこと DHCP Administrators DHCP Users
DMZ INTRANET
RODC RWDC DHCP
38
(参考)RSO Operation
更新されたオブジェクトのみを受け取るための内部動作 クラゕントからの動的更新要求に対して、RWDCを紹介後、速やかなDNSレコード更新を行うために、複製待ち合わせプロセスが起動される 以下のエントリがRODCに保持される(remotePollList)
複製すべきレコード 複製元となるDNSサーバー(RWDC) 複製完了が期待される時刻
現在の時刻+待ち時間(5~3600秒、規定30秒)
関連するレジストリエントリ HKLM¥SYSTEM¥CurrentControlSet¥Services¥DNS¥Parameters
DsRemoteReplicationDelay 5秒~3600秒(規定値:30秒) EnableRSOForRODC True / False (規定値:True) MaximumRodcRsoQueueLength 1 ~ 1000000(規定値:300) MaximumRodcRsoAttemptsPerCycle
1 ~ 1000000(規定値:100)
RSO : Replicate Single Object
39
3.RODCの管理者
設計に影響するポイント
RODC の管理には特別なゕカウントを使用したい 特定のサービスゕカウント タスクスケジューラー 対面ログオン
推奨
RODC 管理者ゕカウントを使用するように徹底する RODC管理者 をドメンユーザーに委任可能 RODCではドメン管理者を使用する必要が無い
※RODC昇格時に専用の管理者ゕカウントを指定することができる
40
パスワード複製ポリシー(PRP)によるキャッシュの抑止 規定では複製されない DMZ専用の許可/拒否グループを作成して管理 Appサーバーにはキャッシュを許可する必要がある RODC が複数存在する場合には同じPRPを設定する
※PRPはRODC単位に設定 定期的に PRP の監査を実施することを推奨
属性セットのフィルター機能(FAS)を使用する
各属性のsearchFlag プロパテゖに 「既存の値」+「0x281」を設定
4.慎重に扱うべき情報 設計に影響するポイント
DMZ上のRODCに複製したくない情報がある パスワード 個人を特定できる属性情報
推奨
41
(参考)パスワードの複製ポリシー
規定ではキャッシュは無効(複製可能なユーザーが定義されていない)
最初のログオン時に複製される(ユーザー単位)
パスワード変更後の最初のログオン時に複製される
パスワード複製ポリシーで複製ルールを定義可能
複製許可リスト (RODC の msDS-RevealOnDemandGroup 属性)
複製拒否リスト (RODC の msDS-NeverRevealGroup 属性)
履歴を保持
RODC でログオンしたことがあるユーザー一覧 (RODC の msDS-AuthenticatedToAccountList 属性)
RODC にパスワードが複製されているユーザー一覧 (RODC の msDS-RevealedList 属性)
複製されたパスワードは一括でリセット可能
キャッシュのクリゕはできない
42
(参考)パスワード複製の判断プロセス
パスワード複製の可否は、パスワード複製ポリシーの 「許可リスト」「拒否リスト」で判断される
RODC がパスワードの複製を要求
ゕカウントが拒否リストにあるか?
ゕカウントが許可リストにあるか?
複製エラー
複製が許可される。 パスワードが複製されたユーザーは msDS-RevealedList 属性に追加される。
複製エラー
YES
NO
NO
YES
43
5.RODCとRWDCの複製トポロジー 設計に影響するポイント
RODC は Windows Server 2008 以上のRWDCのみが複製パートナーとなれる( RODC → RWDC 方向への複製は行われない)
DMZ上のAppサーバーは RWDCと直接通信が行えない
DMZ と 内部はADサトを分割する 認証はサト内で閉じる
DMZサトと内部サトを明なサトリンクで接続 複数のRODC により単一障害点を回避する
DMZ INTRANET
SITE-DMZ SITE-A SITE-B SITE LINK
推奨
44
DMZ INTRANET
6.RODCの通信モデル
設計に影響するポイント 1. RODC と Appサーバー間の通信を安全に行う 2. RWDC から RODC への通信を安全に行う 3. RODC から RWDC への通信を安全に行う
3
1 2
45
経路1:Appサーバー → RODC
受信ポート Type
TCP 135 EPM
TCP UDP
389 LDAP/C-LDAP(Connection‐less-LDAP)
TCP 445 DFS, LsaRpc, NbtSS, NetLogonR, SamR, SMB, SrvSvc
TCP UDP
53 DNS
TCP 88 Kerberos
TCP/UDP Dynamic
49152 ~65535
DNS, DRSUAPI, NetLogonR, SamR
UDP 67 DHCP/Bootp
以下のポートはRODCの「送信ポート」としても公開されている必要がある
46
経路2:RWDC → RODC
受信ポート タイプ
TCP 135 RPC EPM(End Point Mapper)
TCP aaaaa RPC AD Replication
TCP bbbbb RPC FRS(FRSを使用する場合)
TCP 389 LDAP
TCP 5985 5986
WinRM(HTTP/HTTPS)(ADユーザーとコンピュータ 等で使用) ※RODC側で WinRm quickconfig を実施する必要あり
TCP 9389 ADWS(AD管理センター 等)
詳細後述
以下のポートはRODCの「送信ポート」としても定義する
運用管理に必要! Winrm のリスナーに IPフゖルタを設定。 GPでも設定可能。
47
経路3:RODC → RWDC
受信ポート タイプ
TCP 57344 DRSUAPI,LsaRpc,NetLogonR
TCP xxxxx RPC AD Replication
TCP yyyyy RPC FRS(FRSを使用する場合)
TCP 135 EPM(Endpoint Mapper)
TCP UDP
389 LDAP/C-LDAP(Connection‐less-LDAP)
TCP 3268 GC,LDAP
TCP 445 DFS, LsaRpc, NbtSS, NetLogonR, SamR, SMB, SrvSvc
TCP UDP
53 DNS
TCP 88 Kerberos
UDP 123 NTP
TCP UDP
464 Kerberos Change/Set Password
TCP 5722 DFSR
ICPM ICMP
以下のポートは RWDC の「送信ポート」としても定義する
詳細後述
48
RODC RWDC Firewall
57334 xxxxx yyyyy 135 389 3268 445 53 88 123 464 5722 Any Any Any Any Any Any Any
Any Any Any Any Any Any Any Any Any Any Any Any 135
aaaaa bbbbb
389 5985 5986 9389
49
(参考)RPCで固定ポートを使用するには ■Active Directory オブジェクト複製に使用するポート パス HKEY_LOCAL_MACHINE ¥SYSTEM ¥CurrentControlSet ¥Services ¥NTDS ¥Parameters 値の名前 TCP/IP Port (半角スペースに注意) 値のタプ DWORD 値 49152~65535(10進数)
■FRS Sysvol複製に使用するポート パス HKEY_LOCAL_MACHINE ¥SYSTEM ¥CurrentControlSet ¥Services ¥Ntfrs ¥Parameters 値の名前 RPC TCP/IP Port Assignment (半角スペースに注意) 値のタプ DWORD 値 49152~65535 (10進数)
50
IPSec or Firewall ?
課題 IPSec Firewall
ポートの設定 最小限の設定 ・TCP/UDP 53(DNS) ・TCP/UDP 88(Kerberos) ・TCP 50(ESP) ・TCP 51(AH) ・UDP 500(IKE)
複雑な設定
ブロックと許可 ルールで制御可能 ルールで制御可能
データの整合性 AHプロトコルにより可能 ー
データの機密性 ESPプロトコルにより可能 ー
CPU負荷 高まる 影響なし
設定 集中管理可能(GPO) 集中管理可能
機能の無効化 ちょっと面倒 比較的簡単
送受信間でのポリシーの同期 必要 必要なし
管理コスト 比較的高い さほどでもない
51
7.Appサーバーのドメンへの参加 設計に影響するポイント
従来方式でドメンに参加するにはAppサーバーとRWDCとの通信経路が必要
推奨(詳しくは Appendix2 を参照)
「専用手順」による “Read-Only Domain Join” の実施 コンピューターゕカウントを作成 コンピューターゕカウントのパスワードを明に設定 コンピュータゕカウントのパスワード複製許可 RODCへパスワードをキャッシュ JoinDomainOrWorkgrouopメソッドによるドメン参加
オフライン ドメイン ジョイン ドメンへの参加時に通信を行わない Windows Server 2008 R2 または Windows 7 クラゕントのみ djoin.exe コマンドを使用
Windows 7 or Windows Server 2008 R2 ではこうなる!
52
8.Sysvol の整合性
SYSVOL複製は FRS か DFSR を使用することができる 管理者は RODC 上 の SYSVOLを編集することが出来る RODC から RWDC への複製は行われない
FRS を使用する場合 SYSVOLはRWDC側で変更が発生しないとRODCに複製されない Appサーバーが、整合性の無いSYSVOLを使用する可能性がある
グループポリシー ログオン/ログオフ/スタートゕップ/シャットダウンスクリプト
DFSRを使用する場合 RODC は最終複製時の状態を保持しようとする SYSVOLに加えられた変更は自動的に復元される
管理者であっても RODC のSYSVOLを変更することはできない!
Windows Server 2008 R2 ではこうなる!
53
54
まとめ
RODCによりDMZ上でのAD認証が現実的に!
社内ドメンをDMZに拡張可能 設計がシンプル 社内ドメンの安全性を確保 管理コストを低く抑えられる
ただし以下の注意が必要
ユーザー情報漏えいを防止する対策の徹底 ドメン参加のオペレーションに難あり
55
56
57
リソース
http://blogs.technet.com/junichia/
58
RODCを使用した認証プロセス
59
RODC を使用した認証プロセス パスワードキャッシュ:許可 ログオン:初回
1 KDC として動作している RODC に対し TGT 要求を送信
2 RODC が TGT 要求を受け取り RODC 内にパスワードをキャッシュしているかどうか確認。キャッシュしていないため TGT を作成することはできず、書き込み可能な DC にTGT 要求を転送。
書き込み可能 DC 読み取り専用 DC
Active Directory DB Active Directory DB ( read-only )
1 2
ログオン要求 → TGT 発行 → サービスチケット発行
60
RODC を使用した認証プロセス パスワードキャッシュ:許可 ログオン:初回
3 書き込み可能な DC が要求を認証
4 RODC に認証結果が返される。パスワードが正しくない場合にはエラー メッセージが表示される。
書き込み可能 DC 読み取り専用 DC
Active Directory DB Active Directory DB ( read-only )
1 2
4
3
ログオン要求 → TGT 発行 → サービスチケット発行
61
RODC を使用した認証プロセス パスワードキャッシュ:許可 ログオン:初回
5 認証が正しく行われると TGT が発行され、ユーザーの DN が、RODC コンピュータ ゕカウントの msDS-AuthenticatedToAccountList 属性に追加される
書き込み可能 DC 読み取り専用 DC
Active Directory DB Active Directory DB ( read-only )
1 2
4
3 5
ログオン要求 → TGT 発行 → サービスチケット発行
62
RODC を使用した認証プロセス パスワードキャッシュ:許可 ログオン:初回
6 TGT を含め、認証結果がユーザーに返される
7 RODC がユーザーのパスワードを送信するよう、書き込み可能 DC に依頼
8 パスワード複製ポリシーを確認し、ユーザーのパスワードをキャッシュしてもよいかどうかを確認する
書き込み可能 DC 読み取り専用 DC
Active Directory DB Active Directory DB ( read-only )
1 2
4
3 5
6 6
7
8
ログオン要求 → TGT 発行 → サービスチケット発行
63
RODC を使用した認証プロセス
書き込み可能 DC 読み取り専用 DC
Active Directory DB Active Directory DB ( read-only )
1 2
パスワードキャッシュ:許可 ログオン:初回
パスワードを送信。 ユーザーの DN が RODC コンピュータ ゕカウントの msDS-RevealedList 属性に追加される(ユーザーがRODC でキャッシュされたことを示す)。
4
3 5
6 6 7
8 9
10
10
11
11 11
RODC はパスワードをキャッシュする
9 パスワードキャッシュを許可
ログオン要求 → TGT 発行 → サービスチケット発行
書き込み可能なDCが発行し
たTGT取得
64
RODC を使用した認証プロセス
書き込み可能 DC 読み取り専用 DC
Active Directory DB Active Directory DB ( read-only )
パスワードキャッシュ:許可 ログオン:初回
12
発行された TGT を提示してサービスチケットを要求
ログオン要求 → TGT 発行 → サービスチケット発行
12
TGT を有効期限切れとして一旦エラーを返す 13
13
14
古い TGT を破棄し、新しい TGT 発行を依頼 14
65
RODC を使用した認証プロセス
書き込み可能 DC 読み取り専用 DC
Active Directory DB Active Directory DB ( read-only )
パスワードキャッシュ:許可 ログオン:初回
12
キャッシュされているユーザーのパスワードと、RODC 固有の krbtgt ゕカウントのパスワード を使用して TGT を生成
ログオン要求 → TGT 発行 → サービスチケット発行
15
13
14
生成しなおした TGT をクラゕントに返す 16
15
16
17
再度 TGT を RODC に送信し、サービスチケットを要求 17
新
66
RODC を使用した認証プロセス
書き込み可能 DC 読み取り専用 DC
Active Directory DB Active Directory DB ( read-only )
パスワードキャッシュ:許可 ログオン:初回
12
サービスチケットを生成するためにはクラゕントコンピュータゕカウントのパスワードが必要だが、RODC は持っていいないため、書き込み可能な DC に要求を転送
ログオン要求 → TGT 発行 → サービスチケット発行
18
13
14
15
16
17
18
19
ユーザーのグループメンバシップから特権認証証明書(PAC)作成 ※偽装を防止するため TGT に埋め込まれた PAC は使用しない
19
新
67
RODC を使用した認証プロセス
書き込み可能 DC 読み取り専用 DC
Active Directory DB Active Directory DB ( read-only )
パスワードキャッシュ:許可 ログオン:初回
12
サービスチケットが生成されて RODC に送付
ログオン要求 → TGT 発行 → サービスチケット発行
20
13
14
15
16
17
18
19
20
21
サービスチケットがクラゕントに送信され、ユーザーの権限が FIXしてログン完了
21
新
68
RODC を使用した認証プロセス
書き込み可能 DC 読み取り専用 DC
Active Directory DB Active Directory DB ( read-only )
パスワードキャッシュ:許可 ログオン:初回
12
RODC が、書き込み可能な DC に対し、クラゕントコンピュータゕカウントのパスワードを RODC に複製するよう依頼
ログオン要求 → TGT 発行 → サービスチケット発行
22
13
14
15
16
17
18
19
20
21
新
22
23
書き込み可能 DC は、パスワード複製ポリシーを参照し、クラゕントコンピュータゕカウントのパスワードが複製できるかどうかを確認する
23
69
RODC を使用した認証プロセス
書き込み可能 DC 読み取り専用 DC
Active Directory DB Active Directory DB ( read-only )
パスワードキャッシュ:許可 ログオン:初回
12
パスワード複製ポリシーで複製できることを確認後、複製を許可
ログオン要求 → TGT 発行 → サービスチケット発行
24
13
14
15
16
17
18
19
20
21
新
22
23
24
25
25
RODC はクラゕントコンピュータゕカウントのパスワードをキャッシュする
70
RODC を使用した認証プロセス
書き込み可能 DC 読み取り専用 DC
Active Directory DB Active Directory DB ( read-only )
パスワードキャッシュ:許可 ログオン:初回
12
書き込み可能な DC は、クラゕントコンピュータゕカウントの DN を、RODC コンピュータ ゕカウントの msDS-RevealedList 属性に追記する。
ログオン要求 → TGT 発行 → サービスチケット発行
26
13
14
15
16
17
18
19
20
21
新
22
23
24
26 25
以降、当該ユーザーが当該コンピュータを使用する場合には、書き込み可能 DC への通信は発生しない
71
RODC環境でのドメン参加
72
2つの方法
JoinDomainOrWorkGroup メソッドを使用したスクリプトを使用
方法1:Windows Server 2008/Vista 以前
方法2:Windows Server 2008 R2/Windows 7 以降 オフラン ドメン ジョン機能(djoin.exe)
1. 参加させたいPCのコンピュータゕカウントを作成 2. パスワードを明に指定する(重要!)
Net user <computername>$ password 3. コンピューターを「Allowed Password Replication Group」 に追加 4. コンピューターのパスワードを強制的にRODCにキャッシュ
[RODCのプロパテゖ]-[パスワード レプリケーション ポリシー]-[詳細設定]-[パスワードの事前配布]
5. PC上でスクリプト実行 詳細は http://blogs.technet.com/junichia/archive/2009/08/24/3276222.aspx
1. ドメンに参加しているクラゕント上で以下のコマンドを実行 djoin /provision /domain DOMAINNAME /machine COMPUTERNAME /savefile BLOBフゔルのフゔル名
2. BLOBフゔルをドメンに参加させたいクラゕントにコピー 3. ドメンに参加させたいクラゕント上で以下のコマンドを実施
djoin /requestODJ /loadfile BLOBフゔル名 /windowspath %Systemroot%
4. 再起動 詳細は http://blogs.technet.com/junichia/archive/2009/08/23/3276081.aspx
73
top related