active directory をinternetから使用するための4つのシナリオ

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

４つの展開モデル

モデル１：AD DSを使わない

モデル２：分割フォレスト

モデル３：フォレスト間信頼

モデル４：拡張フォレスト

11





12

DMZ

モデル１：AD DSを使用しない

DMZ上のゕプリケーションサーバーは独自に認証DBを持つ

INTRANET


Internet

ユーザー情報の格納庫：

ユーザーの利便性：

管理性：

安全性：

構築の容易性：

SAM、DB、ハードコーデゖング・・・・

独自のID/パスワード,SSO不可能

ゕプリ個別に管理

Appサーバーに依存。IDが分散するため、セキュリテゖポリシーの統一が困難。

複数のデゖレクトリ

13

モデル１が合致する条件

IDに要求されることは何か？特に無い。ゕプリの認証が行えればそれでよい

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

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

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

ユーザーIDを含め社内データの一切の漏えいは認められないため、

DMZへの登録も禁止する

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

14





15

DMZ INTRANET

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

安全性：

管理性：




DC DC

Internet

AD DS

DMZ内は統一。内部と異なるID/パスワードとなる可能性がある

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

DMZドメンへのゕタックによりAppサーバーが危険。

DMZで共通のデゖレクトリ。ゕプリ設計必要

16

モデル２が合致する条件

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





18

DMZ

DC

INTRANET

DC

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

Internet



安全性：

管理性：


信頼関係

AD DS

DMZで共通のデゖレクトリ。ユーザーIDの登録は必要ない

ユーザーIDは内部で一元管理可能

DMZドメンへのゕタックによりAppサーバーが危険にさらされる。

ユーザーは社内ドメンで

19

モデル３が合致する条件 IDに要求されることは何か？

ユーザーIDは完全に統合したい。


複数のAppサーバーがあるのでDMZ内で使用するIDの集中管理は必要

だし、今後サーバーが増えればGPでAppサーバーの制御も行いたい。

ただし、DMZと社内の管理は分かれても良い。


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


ユーザーIDを含め社内データの一切の漏えいは認められないため、

DMZへのユーザーIDの登録も禁止する。


Appサーバーの中にAD DSを使用するものがあり、AD DSへの書き込

みも発生する。内部ADに書き込みを許可するかどうかは要検討。

20





21

INTRANET DMZ

DMZと社内をまたいだ同一ドメンゕカウントは完全なる一元管理 DMZにはRODCを展開

モデル4：フォレスト拡張

RODC Internet



安全性：

管理性：


AD DS

考慮事項が多数あり

完全に同一IDとパスワードを使用可能。

覚えるべき操作はあるものの、社内と完全に統一された管理環境。

読み取り専用であってもセキュリテゖポリシーによっては情報漏洩の可能性は存在。改ざんは防衛可能。

RWDC 複製

22

モデル４が合致する条件 IDに要求されることは何か？

IDはコンピューターゕカウントを含め集中管理したい。


複数のAppサーバーがあるのでDMZ内で使用するIDの集中管理は必要。

管理コストを下げるために、ドメン数は極力減らしたい。


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


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


ゕプリケーションは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

展開モデル４のおさらい

DMZ INTRANET Internet

RODC RWDC


34

設計に影響する7つの事項＋１

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

モデル４を採用するにはRODCに関して考慮すべき事項が存在する

35

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

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

３．RODCの管理者

設計に影響するポイント

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

推奨

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

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

40

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

※PRPはRODC単位に設定定期的に PRP の監査を実施することを推奨

属性セットのフィルター機能（FAS）を使用する

各属性のsearchFlag プロパテゖに「既存の値」＋「0x281」を設定

４．慎重に扱うべき情報設計に影響するポイント

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

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

６．RODCの通信モデル

設計に影響するポイント 1. RODC と Appサーバー間の通信を安全に行う 2. RWDC から RODC への通信を安全に行う 3. RODC から RWDC への通信を安全に行う

3

1 2

45

経路１: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

経路２：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

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

８．Sysvol の整合性

SYSVOL複製は FRS か DFSR を使用することができる管理者は RODC 上の SYSVOLを編集することが出来る RODC から RWDC への複製は行われない

FRS を使用する場合 SYSVOLはRWDC側で変更が発生しないとRODCに複製されない Appサーバーが、整合性の無いSYSVOLを使用する可能性がある

グループポリシーログオン/ログオフ/スタートゕップ/シャットダウンスクリプト

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

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

Windows Server 2008 R2 ではこうなる！

54

まとめ

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

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

ただし以下の注意が必要

ユーザー情報漏えいを防止する対策の徹底ドメン参加のオペレーションに難あり

57

リソース

http://blogs.technet.com/junichia/

58

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

59

RODC を使用した認証プロセスパスワードキャッシュ：許可ログオン：初回

１ KDC として動作している RODC に対し TGT 要求を送信

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

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

Active Directory DB Active Directory DB （ read-only ）

１ 2

ログオン要求 → TGT 発行 → サービスチケット発行

60


3 書き込み可能な DC が要求を認証

4 RODC に認証結果が返される。パスワードが正しくない場合にはエラーメッセージが表示される。



１ 2

4

3


61


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



１ 2

4

3 5


62


6 TGT を含め、認証結果がユーザーに返される

7 RODC がユーザーのパスワードを送信するよう、書き込み可能 DC に依頼

8 パスワード複製ポリシーを確認し、ユーザーのパスワードをキャッシュしてもよいかどうかを確認する



１ 2

4

3 5

6 6

7

8


63

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



１ 2

パスワードキャッシュ：許可ログオン：初回

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

4

3 5

6 6 7

8 9

10

10

11

11 11

RODC はパスワードをキャッシュする

9 パスワードキャッシュを許可


書き込み可能なDCが発行し

たTGT取得

64





12

発行された TGT を提示してサービスチケットを要求


12

TGT を有効期限切れとして一旦エラーを返す 13

13

14

古い TGT を破棄し、新しい TGT 発行を依頼 14

65





12

キャッシュされているユーザーのパスワードと、RODC 固有の krbtgt ゕカウントのパスワードを使用して TGT を生成


15

13

14

生成しなおした TGT をクラゕントに返す 16

15

16

17

再度 TGT を RODC に送信し、サービスチケットを要求 17

新

66





12

サービスチケットを生成するためにはクラゕントコンピュータゕカウントのパスワードが必要だが、RODC は持っていいないため、書き込み可能な DC に要求を転送


18

13

14

15

16

17

18

19

ユーザーのグループメンバシップから特権認証証明書（PAC）作成 ※偽装を防止するため TGT に埋め込まれた PAC は使用しない

19

新

67





12

サービスチケットが生成されて RODC に送付


20

13

14

15

16

17

18

19

20

21

サービスチケットがクラゕントに送信され、ユーザーの権限が FIXしてログン完了

21

新

68





12

RODC が、書き込み可能な DC に対し、クラゕントコンピュータゕカウントのパスワードを RODC に複製するよう依頼


22

13

14

15

16

17

18

19

20

21

新

22

23

書き込み可能 DC は、パスワード複製ポリシーを参照し、クラゕントコンピュータゕカウントのパスワードが複製できるかどうかを確認する

23

69





12

パスワード複製ポリシーで複製できることを確認後、複製を許可


24

13

14

15

16

17

18

19

20

21

新

22

23

24

25

25

RODC はクラゕントコンピュータゕカウントのパスワードをキャッシュする

70





12

書き込み可能な DC は、クラゕントコンピュータゕカウントの DN を、RODC コンピュータゕカウントの msDS-RevealedList 属性に追記する。


26

13

14

15

16

17

18

19

20

21

新

22

23

24

26 25

以降、当該ユーザーが当該コンピュータを使用する場合には、書き込み可能 DC への通信は発生しない

71

RODC環境でのドメン参加

72

2つの方法

JoinDomainOrWorkGroup メソッドを使用したスクリプトを使用

方法１：Windows Server 2008/Vista 以前

方法２：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

active directory をinternetから使用するための4つのシナリオ

Technology