Active Directory をInternetから使用するための4つのシナリオ

T6-303

マ゗クロソフト株式会社
エバンジェリスト
あんのうじゅんいち

安納順一
http://blogs.technet.com/junichia/

1

このセッションの目的
このセッションでは、

゗ンターネットからゕプリケーションサーバーへのゕクセスを
Active Directoryで認証することが、

どのようなメリットをもたらすのか
そしてそれは果たして可能なのか？
できるとしたら、トレードオフが発生するのか？
についてお話します。
もちろん、

「うーん、うちには適用できないな」

と言う結論に達する可能性もあります。
みなさんが抱えている案件を思い浮かべながらお聞きください。
2

想定しているシナリオ
ゕプリケーションを社内、社外両方から同様に使用する
利用者は社員または外部利用者（パートナー企業やパートタ゗マー）

Direct VPN
Access Reverse
Proxy

Remote
Desktop Federation
Service

いっそのこと
Hungry.. Cloud？

3

もっともシンプルなのは？
きまりです！
DMZにAD DS置いて認証!

理想的な構成
外からも使いたいゕプリケーションはDMZに設置し、必要な認証サーバーも
DMZ上に構築する。もちろんユーザーは全てDMZ上の認証サーバーに登録。

Internet DMZ INTRANET

DC DC

Active Directory Domain

4

そんなの怖くて....

5

Agenda

計画
どのような構成が考えられるのか
－ 4つの展開モデル
－ RODCについて

設計
RODCをDMZに展開するにあたり全体設計に影響する
7つの考察

6

略語一覧
略語
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

7

DMZにAD DS を展開するにあたり、
事前に何を考慮しなければならないのか

8

考慮事項

IDに要求されることは何か？

IDの集中管理が必要か？

SSOに対するニーズは？

個人情報の漏洩についてどの程度の対策が求められるか？

ゕプリケーションが使用する情報はAD DSに格納されるか？

9

４つの展開モデル

モデル１：AD DSを使わない
モデル２：分割フォレスト
モデル３：フォレスト間信頼
モデル４：拡張フォレスト

10


11

モデル１：AD DSを使用しない
DMZ上のゕプリケーションサーバーは独自に認証DBを持つ


ユーザー情報の格納庫：SAM、DB、ハードコーデゖング・・・・
構築の容易性：複数のデゖレクトリ

安全性： Appサーバーに依存。IDが分散するため、セ
キュリテゖポリシーの統一が困難。
管理性：ゕプリ個別に管理
ユーザーの利便性：独自のID/パスワード,SSO不可能

12

モデル１が合致する条件
特に無い。ゕプリの認証が行えればそれでよい

集中管理された管理が必要か？
ゕプリケーションサーバー数とユーザー数はさほど多くないので必要
ない

どんなSSOへのニーズがあるのか？
シングルサ゗ンオンの恩恵を受けるユーザーはいないので必要ない
独自のSSOの仕組みを構築している

情報漏洩についてどの程度の対策が求められるか？
ユーザーIDを含め社内データの一切の漏えいは認められないため、
DMZへの登録も禁止する

アプリケーションが使用する情報はAD DSに格納されるか？
AD DSを使用するゕプリケーションは存在しない
AD DSに対応させるための改修を行いたくない
13


14

゗ンターネットゕプリケーション用に新しいフォレストを構築
社内フォレストとの信頼関係は構築しない
DMZ内でゕプリサーバーの認証を統合することが可能
DC DC

ユーザー情報の格納庫： AD DS
構築の容易性： DMZで共通のデゖレクトリ。ゕプリ設計必要
安全性： DMZドメ゗ンへのゕタックによりAppサーバーが危険。

管理性：内部とは完全に個別管理するか、同期が必要

ユーザーの利便性： DMZ内は統一。内部と異なるID/パスワード
となる可能性がある 15

モデル２が合致する条件
DMZ上で使用するIDは完全に社内のIDと分断されていてほしい
複数のAppサーバーがあるのでDMZ内で使用するIDの集中管理は必要だ
し、今後サーバーが増えればGPでAppサーバーの制御も行いたい
社内ネットワークとのSSOは望ましくないが、DMZ上のAppサーバー間
でのSSOができると便利
ユーザーIDを含め社内データの一切の漏えいは認められないため、DMZ
への社内IDの登録を禁止する
Appサーバーの中にAD DSを使用するものがあり、AD DSへの書き込み
も発生する
16


17

モデル３：フォレスト信頼モデル
゗ンターネットゕプリケーション用に新しいフォレストを構築
社内フォレストとの信頼関係を構築し、社内からのゕクセスはSSOを実現
DMZ内でゕプリサーバーの認証を統合することが可能
DC 信頼関係 DC

構築の容易性： DMZで共通のデゖレクトリ。ユーザーIDの登
録は必要ない
安全性： DMZドメ゗ンへのゕタックによりAppサーバーが危険
にさらされる。
管理性：ユーザーIDは内部で一元管理可能
ユーザーの利便性：ユーザーは社内ドメ゗ンで
18

モデル３が合致する条件
ユーザーIDは完全に統合したい。
複数のAppサーバーがあるのでDMZ内で使用するIDの集中管理は必要
だし、今後サーバーが増えればGPでAppサーバーの制御も行いたい。
ただし、DMZと社内の管理は分かれても良い。
社内ネットワークとのSSO環境が望ましい
ユーザーIDを含め社内データの一切の漏えいは認められないため、
DMZへのユーザーIDの登録も禁止する。
Appサーバーの中にAD DSを使用するものがあり、AD DSへの書き込
みも発生する。内部ADに書き込みを許可するかどうかは要検討。

19


20

モデル4：フォレスト拡張
DMZと社内をまたいだ同一ドメ゗ン
ゕカウントは完全なる一元管理
DMZにはRODCを展開
DMZ INTRANET
Internet
RODC 複製 RWDC

構築の容易性：考慮事項が多数あり
安全性：読み取り専用であってもセキュリテゖポリシーに
よっては情報漏洩の可能性は存在。改ざんは防衛
可能。
管理性：覚えるべき操作はあるものの、社内と完全に統
一された管理環境。
ユーザーの利便性：完全に同一IDとパスワードを使用可能。 21

モデル４が合致する条件
IDはコンピューターゕカウントを含め集中管理したい。

複数のAppサーバーがあるのでDMZ内で使用するIDの集中管理は必要。
管理コストを下げるために、ドメ゗ン数は極力減らしたい。

社内ネットワークとのSSO環境が望ましい

社内AD DSの PII や HBI がDMZを介して社外に漏えいしない

ゕプリケーションはAD DSに格納された情報を使用するが、書き込み
は発生しない。また、RODC互換ゕプリである。

22

展開モデルのまとめ
モデル1 モデル2 モデル3 モデル4
No AD DS 分割ﾌｫﾚｽﾄﾌｫﾚｽﾄ間信頼拡張ﾌｫﾚｽﾄ

独自
ユーザー情報の格納庫： SAM 等
AD DS AD DS AD DS

構築の容易性：

安全性：

管理性：

ユーザーの利便性：

23

拡張フォレストモデルで使用されるRODCには
どのようなメリットと制限事項が存在するのか

24

RODC とは？
Windows Server 2008 から実装された読み取り専用のドメ゗ンコントローラ
RODCの優れた点
ドメ゗ンコントローラである
セキュリテゖ
読み取り専用である（AD,DNS,Sysvol）
一般ユーザーにRODC専用の管理を委任できる
RWDCから複製を受け取るだけである
RWDCからの複製を属性単位でフゖルタリング（FAS）
独自の krbtgt ゕカウント
パスワード複製ポリシー（PRP）
緊急時のパスワードリセット機能
RODCで認証したユーザーの捕捉
Server Core 上に構築可能
RODCの考慮事項
フォレストとドメ゗ンの機能レベル
スキーマ拡張
修正モジュールの適用（2003/XP/Vista）
ゕプリケーションとの互換性
PIIとHBI の漏洩防止
25

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 とする

2008 RWDC
RODC

2003 RWDC

26

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を含んだサ゗
トの自動サ゗トカバレッジを実施してしまう
27

RODCの考慮事項 ③
アプリケーションとの互換性
■大原則：RODCには書き込めない！

読み取り操作が非効率的になったり失敗する
4
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

28

RODCに書き込みが発生した場合の動作
ゕプリケーションサーバーとRWDCの通信が可能でなければならない

DMZ INTRANET
③RWDC
RODC から複製 RWDC
①RWDC
を照会

②RWDCと
直接通信

29

（参考）RODCによる書き込みのForward
RODCは一部の属性の書き込み要求をRWDCにForwardする
パスワード変更
Service Principal Name（SPN）の更新
Netlogonサービスによるクラ゗ゕント属性の変更
client name
DnsHostName
OsVersionInfo
OsName
Supported Encryption Types
LastLogonTimeStamp
DMZ INTRANET

書き込み
RODC RWDC
書き込み依頼

30

RODCの考慮事項 ④
PII と HBI の漏洩防止
※PII： Personally identifiable information
※HBI：High business impact
FAS（Filtered Attribute Set）の適用

DMZ 複製を
INTRANET
フゖルター
RWDC ユーザーID
RODC
氏名
F 住所
ユーザーID A 性別
S 電話番号
所属
健康保険番号....

31

RODCが設計に及ぼす影響

32

展開モデル４のおさらい


RODC RWDC


33

設計に影響する7つの事項＋１
モデル４を採用するにはRODCに関して考慮すべき事項が存在する

1. RODC への昇格
2. DNS の更新
3. RODC の管理者
4. 慎重に扱うべき情報
5. RODC と RWDC の複製トポロジ
6. RODC の通信モデル
7. Appサーバーのドメ゗ンへの参加
＋
8. SYSVOLの整合性

34

１．RODCへの昇格
設計に影響するポイント

どちらのネットワーク（DMZ or 内部）で昇格させるか
昇格の際に発生するRODC－RWDC間の通信を確保
昇格時にDNSに登録されるレコード

昇格の手順
通常の昇格手順では管理者IDが必要となるが、
2ステージ゗ンストールでは管理者権限は要求されない

推奨
2ステージ゗ンストール方式を使用してDMZ内から昇格

Server Core を使用する

※通信については「4.RODCの通信モデル」参照

35

（参考）2ステージ゗ンストール
事前に RODC ゕカウントを作成しておき、DMZ専用の管理者ID（Domain
Adminsである必要はない）に゗ンストールを委任することが可能
ゕカウント作成時にウゖザードを使用して必要情報を事前指定
DMZでの゗ンストールはほぼ自動的に完了

Stage2 Stage1
作成したゕカウントにゕタッチ RWDC上にRODCのコンピュータゕカ
Dcpromo /UseExistingAccount:Attach ウントを作成する
レプリケーション元の指定
管理ゕカウントを指定 [ Active Directory ユーザーとコンピュータ ]
RODC コンピュータゕカウントを選択の [ Domain Controllers ] OU を右クリック
その他は従来の Active Directory と同様の情報
を指定

RODC RWDC

DMZ INTRANET
36

２．DNSの更新
RODCは書き込み可能なAD統合ゾーンを保持していない
DNSクラ゗ゕントからの更新を受け付けられない
SOA（start of authority）クエリーに対しRWDCを返す
手動更新か動的更新か
動的な場合クラ゗ゕントはRWDCと直接通信しなければならない
どの名前空間を公開すべきか
選択肢
DNSを使用しない（HOSTSフゔ゗ルで名前解決）
手動で管理する（Appサーバーが少ない場合には最適）
Appサーバー－RWDC 間のポートをオープンして
DHCPサーバーに動的更新を行わせる
DHCPサービスのゕカウントを
DMZ INTRANET
明に設定すること
MACゕドレスでリース予約 RODC DHCP RWDC
すること
事前に以下のグループを作成
しておくこと
DHCP Administrators
DHCP Users
37

（参考）RSO Operation RSO : Replicate Single Object
更新されたオブジェクトのみを受け取るための内部動作

クラ゗ゕントからの動的更新要求に対して、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）

38

３．RODCの管理者

RODC の管理には特別なゕカウントを使用したい
特定のサービスゕカウント
タスクスケジューラー
対面ログオン

推奨

RODC 管理者ゕカウントを使用するように徹底する
RODC管理者をドメ゗ンユーザーに委任可能
RODCではドメ゗ン管理者を使用する必要が無い

※RODC昇格時に専用の管理者ゕカウントを指定することができる

39

４．慎重に扱うべき情報

DMZ上のRODCに複製したくない情報がある
パスワード
個人を特定できる属性情報

推奨

パスワード複製ポリシー（PRP）によるキャッシュの抑止
規定では複製されない
DMZ専用の許可/拒否グループを作成して管理
Appサーバーにはキャッシュを許可する必要がある
RODC が複数存在する場合には同じPRPを設定する
※PRPはRODC単位に設定
定期的に PRP の監査を実施することを推奨

属性セットのフィルター機能（FAS）を使用する
各属性のsearchFlag プロパテゖに「既存の値」＋「0x281」を
設定
40

（参考）パスワードの複製ポリシー
規定ではキャッシュは無効（複製可能なユーザーが定義されていない）
最初のログオン時に複製される（ユーザー単位）
パスワード変更後の最初のログオン時に複製される
パスワード複製ポリシーで複製ルールを定義可能
複製許可リスト
（RODC の msDS-RevealOnDemandGroup 属性）
複製拒否リスト
（RODC の msDS-NeverRevealGroup 属性）
履歴を保持
RODC でログオンしたことがあるユーザー一覧
（RODC の msDS-AuthenticatedToAccountList 属性）
RODC にパスワードが複製されているユーザー一覧
（RODC の msDS-RevealedList 属性）
複製されたパスワードは一括でリセット可能
キャッシュのクリゕはできない

41

（参考）パスワード複製の判断プロセス
パスワード複製の可否は、パスワード複製ポリシーの
「許可リスト」「拒否リスト」で判断される

RODC がパスワードの複製を要求

ゕカウントが拒否 YES
複製エラー
リストにあるか？

NO

ゕカウントが許可 YES 複製が許可される。
リストにあるか？パスワードが複製され
たユーザーは msDS-
NO RevealedList 属性に
追加される。
複製エラー

42

５．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

43

６．RODCの通信モデル
1. RODC と Appサーバー間の通信を安全に行う
2. RWDC から RODC への通信を安全に行う
3. RODC から RWDC への通信を安全に行う

DMZ INTRANET

3

1 2

44

経路１:Appサーバー → RODC
以下のポートはRODCの「送信ポート」としても公開されている必要がある
受信ポート Type
TCP 135 EPM
TCP
389 LDAP/C-LDAP（Connection‐less-LDAP）
UDP

TCP 445 DFS, LsaRpc, NbtSS, NetLogonR, SamR, SMB, SrvSvc

TCP
53 DNS
UDP
TCP 88 Kerberos
TCP/UDP 49152
DNS, DRSUAPI, NetLogonR, SamR
Dynamic ～65535
UDP 67 DHCP/Bootp

45

経路２：RWDC → RODC
以下のポートはRODCの「送信ポート」としても定義する
受信ポートタイプ
TCP 135 RPC EPM(End Point Mapper)
TCP aaaaa RPC AD Replication
詳細後述
TCP bbbbb RPC FRS(FRSを使用する場合）
TCP 389 LDAP
5985 WinRM(HTTP/HTTPS)（ADユーザーとコンピュータ等で使用）
TCP
5986 ※RODC側で WinRm quickconfig を実施する必要あり
TCP 9389 ADWS（AD管理センター等）
Winrm のリスナーに
運用管理に必要! IPフゖルタを設定。
GPでも設定可能。

46

経路3：RODC → RWDC
以下のポートは RWDC の「送信ポート」としても定義する
受信ポートタイプ
TCP 57344 DRSUAPI,LsaRpc,NetLogonR
TCP xxxxx RPC AD Replication
詳細後述
TCP yyyyy RPC FRS(FRSを使用する場合）
TCP 135 EPM（Endpoint Mapper）
TCP
389 LDAP/C-LDAP（Connection‐less-LDAP）
UDP
TCP 3268 GC,LDAP
TCP 445 DFS, LsaRpc, NbtSS, NetLogonR, SamR, SMB, SrvSvc
TCP
53 DNS
UDP
TCP 88 Kerberos
UDP 123 NTP
TCP
464 Kerberos Change/Set Password
UDP
TCP 5722 DFSR
ICPM ICMP
47

RODC RWDC
Firewall
Any 57334
Any xxxxx
Any yyyyy
Any 135
Any 389
Any 3268
Any 445
Any 53
Any 88
Any 123
Any 464
Any 5722
135 Any
aaaaa Any
bbbbb Any
389 Any
5985 Any
5986 Any
9389 Any

48

（参考）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進数）
49

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）集中管理可能

機能の無効化ちょっと面倒比較的簡単

送受信間でのポリシーの同期必要必要なし

管理コスト比較的高いさほどでもない

50

７．Appサーバーのドメ゗ンへの参加

従来方式でドメ゗ンに参加するにはAppサーバーとRWDCとの通
信経路が必要

推奨（詳しくは Appendix2 を参照）
「専用手順」による “Read-Only Domain Join” の実施
コンピューターゕカウントを作成
コンピューターゕカウントのパスワードを明に設定
コンピュータゕカウントのパスワード複製許可
RODCへパスワードをキャッシュ
JoinDomainOrWorkgrouopメソッドによるドメ゗ン参加
Windows 7 or Windows Server 2008 R2 ではこうなる！

オフラインドメインジョイン
ドメ゗ンへの参加時に通信を行わない
Windows Server 2008 R2 または Windows 7 クラ゗ゕントのみ
djoin.exe コマンドを使用
51

８．Sysvol の整合性
SYSVOL複製は FRS か DFSR を使用することができる
管理者は RODC 上の SYSVOLを編集することが出来る
RODC から RWDC への複製は行われない
FRS を使用する場合
SYSVOLはRWDC側で変更が発生しないとRODCに複製されない
Appサーバーが、整合性の無いSYSVOLを使用する可能性がある
グループポリシー
ログオン/ログオフ/スタートゕップ/シャットダウンスクリプト

DFSRを使用する場合
RODC は最終複製時の状態を保持しようとする
SYSVOLに加えられた変更は自動的に復元される

Windows Server 2008 R2 ではこうなる！

管理者であっても RODC のSYSVOLを変更することはできない！

52

まとめ

RODCによりDMZ上でのAD認証が現実的に！

社内ドメ゗ンをDMZに拡張可能
設計がシンプル
社内ドメ゗ンの安全性を確保
管理コストを低く抑えられる

ただし以下の注意が必要
ユーザー情報漏えいを防止する対策の徹底
ドメ゗ン参加のオペレーションに難あり

54

リソース
http://blogs.technet.com/junichia/

57

RODCを使用した認証プロセス

58

RODC を使用した認証プロセス
パスワードキャッシュ：許可
ログオン要求 → TGT 発行 → サービスチケット発行
ログオン：初回

書き込み可能 DC 読み取り専用 DC

2 １

Active Directory DB Active Directory DB
（ read-only ）

１ KDC として動作している RODC に対し TGT 要求を送信
2 RODC が TGT 要求を受け取り RODC 内にパスワードをキャッシュし
ているかどうか確認。キャッシュしていないため TGT を作成すること
はできず、書き込み可能な DC にTGT 要求を転送。 59



2 １
4

3

（ read-only ）

3 書き込み可能な DC が要求を認証
4 RODC に認証結果が返される。パスワードが正しくない場合にはエラー
メッセージが表示される。
60



2 １
4

3 5

（ read-only ）

5 認証が正しく行われると TGT が発行され、ユーザーの DN が、RODC コン
ピュータゕカウントの msDS-AuthenticatedToAccountList 属性に追加さ
れる

61



2 １
4
6 6
7

3 5 8

（ read-only ）

6 TGT を含め、認証結果がユーザーに返される
7 RODC がユーザーのパスワードを送信するよう、書き込み可能 DC に依頼
8 パスワード複製ポリシーを確認し、ユーザーのパスワードをキャッシュして
もよいかどうかを確認する 62



2 １
4
6 6
7
9 書き込み可能
3 5 8 10 11
11 なDCが発行し
たTGT取得

（ read-only ）
9 パスワードキャッシュを許可
10 パスワードを送信。
ユーザーの DN が RODC コンピュータゕカウントの msDS-RevealedList 属
性に追加される（ユーザーがRODC でキャッシュされたことを示す）。
11 RODC はパスワードをキャッシュする 63



12
13
14

（ read-only ）
12 発行された TGT を提示してサービスチケットを要求
13 TGT を有効期限切れとして一旦エラーを返す
14 古い TGT を破棄し、新しい TGT 発行を依頼

64



12
13
14
新
16
15 17

（ read-only ）
15 キャッシュされているユーザーのパスワードと、RODC 固有の
krbtgt ゕカウントのパスワードを使用して TGT を生成
16 生成しなおした TGT をクラ゗ゕントに返す
17 再度 TGT を RODC に送信し、サービスチケットを要求 65



18 12
13
14
新
16
19 15 17

（ read-only ）
18 サービスチケットを生成するためにはクラ゗ゕントコンピュータゕ
カウントのパスワードが必要だが、RODC は持っていいないため、
書き込み可能な DC に要求を転送
19 ユーザーのグループメンバシップから特権認証証明書（PAC）作成
※偽装を防止するため TGT に埋め込まれた PAC は使用しない 66



18 12
20 13
14
新
16
19 15 17
21

（ read-only ）
20 サービスチケットが生成されて RODC に送付
21 サービスチケットがクラ゗ゕントに送信され、ユーザーの権限が
FIXしてログ゗ン完了

67



18 12
20 13
22 14
新
16
19 23 15 17
21

（ read-only ）
22 RODC が、書き込み可能な DC に対し、クラ゗ゕントコンピュータ
ゕカウントのパスワードを RODC に複製するよう依頼
23 書き込み可能 DC は、パスワード複製ポリシーを参照し、クラ゗ゕ
ントコンピュータゕカウントのパスワードが複製できるかどうかを
確認する 68



18 12
20 13
22 14
24 新
16
19 23 15 25 17
21

（ read-only ）
24 パスワード複製ポリシーで複製できることを確認後、複製を許可
25 RODC はクラ゗ゕントコンピュータゕカウントのパスワードをキャッ
シュする

69



18 12
20 13
22 14
24 新
16
19 23 26 15 25 17
21

（ read-only ）
26 書き込み可能な DC は、クラ゗ゕントコンピュータゕカウントの
DN を、RODC コンピュータゕカウントの msDS-RevealedList 属
性に追記する。
以降、当該ユーザーが当該コンピュータを使用する場合には、書き込み
可能 DC への通信は発生しない 70

RODC環境でのドメ゗ン参加

71

2つの方法
方法１：Windows Server 2008/Vista 以前
JoinDomainOrWorkGroup メソッドを使用したスクリプトを使用
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
方法２：Windows Server 2008 R2/Windows 7 以降
オフラ゗ンドメ゗ンジョ゗ン機能（djoin.exe）
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 72

Active Directory をInternetから使用するための4つのシナリオ

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Active Directory をInternetから使用するための4つのシナリオ

Ähnlich wie Active Directory をInternetから使用するための4つのシナリオ (20)

Mehr von junichi anno

Mehr von junichi anno (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (11)

Active Directory をInternetから使用するための4つのシナリオ