Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

16,591 views

Published on

TechEd2009で使用した資料です
Active DirectoryをDMZに展開するためのシナリオと具体的な展開方法について解説しています。

Published in: Technology
  • Dating direct: ♥♥♥ http://bit.ly/39pMlLF ♥♥♥
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Sex in your area is here: ❶❶❶ http://bit.ly/39pMlLF ❶❶❶
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • accessibility Books Library allowing access to top content, including thousands of title from favorite author, plus the ability to read or download a huge selection of books for your pc or smartphone within minutes.........ACCESS WEBSITE Over for All Ebooks ..... (Unlimited) ......................................................................................................................... Download FULL PDF EBOOK here { https://urlzs.com/UABbn } .........................................................................................................................
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • If you want to download or read this book, copy link or url below in the New tab ......................................................................................................................... DOWNLOAD FULL PDF EBOOK here { http://bit.ly/2m77EgH } ......................................................................................................................... Download EPUB Ebook here { http://bit.ly/2m77EgH } .........................................................................................................................
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • accessibility Books Library allowing access to top content, including thousands of title from favorite author, plus the ability to read or download a huge selection of books for your pc or smartphone within minutes.........ACCESS WEBSITE Over for All Ebooks ..... (Unlimited) ......................................................................................................................... Download FULL PDF EBOOK here { https://urlzs.com/UABbn } .........................................................................................................................
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

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

  1. 1. T6-303 マ゗クロソフト株式会社 エバンジェリスト あんのう じゅんいち 安納 順一 http://blogs.technet.com/junichia/ 1
  2. 2. このセッションの目的 このセッションでは、 ゗ンターネットからゕプリケーションサーバーへのゕクセスを Active Directoryで認証することが、 どのようなメリットをもたらすのか そしてそれは果たして可能なのか? できるとしたら、トレードオフが発生するのか? についてお話します。 もちろん、 「うーん、うちには適用できないな」 と言う結論に達する可能性もあります。 みなさんが抱えている案件を思い浮かべながら お聞きください。 2
  3. 3. 想定しているシナリオ ゕプリケーションを社内、社外両方から同様に使用する 利用者は社員または外部利用者(パートナー企業やパートタ゗マー) Direct VPN Access Reverse Proxy Remote Desktop Federation Service いっそのこと Hungry.. Cloud? 3
  4. 4. もっともシンプルなのは? きまりです! DMZにAD DS置いて認証! 理想的な構成 外からも使いたいゕプリケーションはDMZに設置し、必要な認証サーバーも DMZ上に構築する。もちろんユーザーは全てDMZ上の認証サーバーに登録。 Internet DMZ INTRANET DC DC Active Directory Domain 4
  5. 5. そんなの怖くて.... 5
  6. 6. Agenda 計画 どのような構成が考えられるのか - 4つの展開モデル - RODCについて 設計 RODCをDMZに展開するにあたり全体設計に影響する 7つの考察 6
  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 7
  8. 8. DMZにAD DS を展開するにあたり、 事前に何を考慮しなければならないのか 8
  9. 9. 考慮事項 IDに要求されることは何か? IDの集中管理が必要か? SSOに対するニーズは? 個人情報の漏洩についてどの程度の対策が求められるか? ゕプリケーションが使用する情報はAD DSに格納されるか? 9
  10. 10. 4つの展開モデル モデル1:AD DSを使わない モデル2:分割フォレスト モデル3:フォレスト間信頼 モデル4:拡張フォレスト 10
  11. 11. モデル1:AD DSを使わない モデル2:分割フォレスト モデル3:フォレスト間信頼 モデル4:拡張フォレスト 11
  12. 12. モデル1:AD DSを使用しない DMZ上のゕプリケーションサーバーは独自に認証DBを持つ Internet DMZ INTRANET Active Directory Domain ユーザー情報の格納庫:SAM、DB、ハードコーデゖング・・・・ 構築の容易性: 複数のデゖレクトリ 安全性: Appサーバーに依存。IDが分散するため、セ キュリテゖポリシーの統一が困難。 管理性: ゕプリ個別に管理 ユーザーの利便性: 独自のID/パスワード,SSO不可能 12
  13. 13. モデル1が合致する条件 IDに要求されることは何か? 特に無い。ゕプリの認証が行えればそれでよい 集中管理された管理が必要か? ゕプリケーションサーバー数とユーザー数はさほど多くないので必要 ない どんなSSOへのニーズがあるのか? シングルサ゗ンオンの恩恵を受けるユーザーはいないので必要ない 独自のSSOの仕組みを構築している 情報漏洩についてどの程度の対策が求められるか? ユーザーIDを含め社内データの一切の漏えいは認められないため、 DMZへの登録も禁止する アプリケーションが使用する情報はAD DSに格納されるか? AD DSを使用するゕプリケーションは存在しない AD DSに対応させるための改修を行いたくない 13
  14. 14. モデル1:AD DSを使わない モデル2:分割フォレスト モデル3:フォレスト間信頼 モデル4:拡張フォレスト 14
  15. 15. モデル2:分割フォレスト ゗ンターネットゕプリケーション用に新しいフォレストを構築 社内フォレストとの信頼関係は構築しない DMZ内でゕプリサーバーの認証を統合することが可能 Internet DMZ INTRANET DC DC ユーザー情報の格納庫: AD DS 構築の容易性: DMZで共通のデゖレクトリ。ゕプリ設計必要 安全性: DMZドメ゗ンへのゕタックによりAppサーバーが危険。 管理性: 内部とは完全に個別管理するか、同期が必要 ユーザーの利便性: DMZ内は統一。内部と異なるID/パスワード となる可能性がある 15
  16. 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への書き込み も発生する 16
  17. 17. モデル1:AD DSを使わない モデル2:分割フォレスト モデル3:フォレスト間信頼 モデル4:拡張フォレスト 17
  18. 18. モデル3:フォレスト信頼モデル ゗ンターネットゕプリケーション用に新しいフォレストを構築 社内フォレストとの信頼関係を構築し、社内からのゕクセスはSSOを実現 DMZ内でゕプリサーバーの認証を統合することが可能 Internet DMZ INTRANET DC 信頼関係 DC ユーザー情報の格納庫: AD DS 構築の容易性: DMZで共通のデゖレクトリ。ユーザーIDの登 録は必要ない 安全性: DMZドメ゗ンへのゕタックによりAppサーバーが危険 にさらされる。 管理性: ユーザーIDは内部で一元管理可能 ユーザーの利便性: ユーザーは社内ドメ゗ンで 18
  19. 19. モデル3が合致する条件 IDに要求されることは何か? ユーザーIDは完全に統合したい。 集中管理された管理が必要か? 複数のAppサーバーがあるのでDMZ内で使用するIDの集中管理は必要 だし、今後サーバーが増えればGPでAppサーバーの制御も行いたい。 ただし、DMZと社内の管理は分かれても良い。 どんなSSOへのニーズがあるのか? 社内ネットワークとのSSO環境が望ましい 情報漏洩についてどの程度の対策が求められるか? ユーザーIDを含め社内データの一切の漏えいは認められないため、 DMZへのユーザーIDの登録も禁止する。 アプリケーションが使用する情報はAD DSに格納されるか? Appサーバーの中にAD DSを使用するものがあり、AD DSへの書き込 みも発生する。内部ADに書き込みを許可するかどうかは要検討。 19
  20. 20. モデル1:AD DSを使わない モデル2:分割フォレスト モデル3:フォレスト間信頼 モデル4:拡張フォレスト 20
  21. 21. モデル4:フォレスト拡張 DMZと社内をまたいだ同一ドメ゗ン ゕカウントは完全なる一元管理 DMZにはRODCを展開 DMZ INTRANET Internet RODC 複製 RWDC ユーザー情報の格納庫: AD DS 構築の容易性: 考慮事項が多数あり 安全性: 読み取り専用であってもセキュリテゖポリシーに よっては情報漏洩の可能性は存在。改ざんは防衛 可能。 管理性: 覚えるべき操作はあるものの、社内と完全に統 一された管理環境。 ユーザーの利便性: 完全に同一IDとパスワードを使用可能。 21
  22. 22. モデル4が合致する条件 IDに要求されることは何か? IDはコンピューターゕカウントを含め集中管理したい。 集中管理された管理が必要か? 複数のAppサーバーがあるのでDMZ内で使用するIDの集中管理は必要。 管理コストを下げるために、ドメ゗ン数は極力減らしたい。 どんなSSOへのニーズがあるのか? 社内ネットワークとのSSO環境が望ましい 情報漏洩についてどの程度の対策が求められるか? 社内AD DSの PII や HBI がDMZを介して社外に漏えいしない アプリケーションが使用する情報はAD DSに格納されるか? ゕプリケーションはAD DSに格納された情報を使用するが、書き込み は発生しない。また、RODC互換ゕプリである。 22
  23. 23. 展開モデルのまとめ モデル1 モデル2 モデル3 モデル4 No AD DS 分割フォレスト フォレスト間信頼 拡張フォレスト 独自 ユーザー情報の格納庫: SAM 等 AD DS AD DS AD DS 構築の容易性: 安全性: 管理性: ユーザーの利便性: 23
  24. 24. 拡張フォレストモデルで使用されるRODCには どのようなメリットと制限事項が存在するのか 24
  25. 25. RODC とは? Windows Server 2008 から実装された読み取り専用のドメ゗ンコントローラ RODCの優れた点 ドメ゗ンコントローラである セキュリテゖ 読み取り専用である(AD,DNS,Sysvol) 一般ユーザーにRODC専用の管理を委任できる RWDCから複製を受け取るだけである RWDCからの複製を属性単位でフゖルタリング(FAS) 独自の krbtgt ゕカウント パスワード複製ポリシー(PRP) 緊急時のパスワードリセット機能 RODCで認証したユーザーの捕捉 Server Core 上に構築可能 RODCの考慮事項 フォレストとドメ゗ンの機能レベル スキーマ拡張 修正モジュールの適用(2003/XP/Vista) ゕプリケーションとの互換性 PIIとHBI の漏洩防止 25
  26. 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 とする 2008 RWDC RODC 2003 RWDC 26
  27. 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を含んだサ゗ トの自動サ゗トカバレッジを実施してしまう 27
  28. 28. 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
  29. 29. RODCに書き込みが発生した場合の動作 ゕプリケーションサーバーとRWDCの通信が可能でなければならない DMZ INTRANET ③RWDC RODC から複製 RWDC ①RWDC を照会 ②RWDCと 直接通信 29
  30. 30. (参考)RODCによる書き込みのForward RODCは一部の属性の書き込み要求をRWDCにForwardする パスワード変更 Service Principal Name(SPN)の更新 Netlogonサービスによるクラ゗ゕント属性の変更 client name DnsHostName OsVersionInfo OsName Supported Encryption Types LastLogonTimeStamp DMZ INTRANET 書き込み RODC RWDC 書き込み依頼 30
  31. 31. 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
  32. 32. RODCが設計に及ぼす影響 32
  33. 33. 展開モデル4のおさらい Internet DMZ INTRANET RODC RWDC Active Directory Domain 33
  34. 34. 設計に影響する7つの事項+1 モデル4を採用するにはRODCに関して考慮すべき事項が存在する 1. RODC への昇格 2. DNS の更新 3. RODC の管理者 4. 慎重に扱うべき情報 5. RODC と RWDC の複製トポロジ 6. RODC の通信モデル 7. Appサーバーのドメ゗ンへの参加 + 8. SYSVOLの整合性 34
  35. 35. 1.RODCへの昇格 設計に影響するポイント どちらのネットワーク(DMZ or 内部)で昇格させるか 昇格の際に発生するRODC-RWDC間の通信を確保 昇格時にDNSに登録されるレコード 昇格の手順 通常の昇格手順では管理者IDが必要となるが、 2ステージ゗ンストールでは管理者権限は要求されない 推奨 2ステージ゗ンストール方式を使用してDMZ内から昇格 Server Core を使用する ※通信については「4.RODCの通信モデル」参照 35
  36. 36. (参考)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
  37. 37. 2.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
  38. 38. (参考)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
  39. 39. 3.RODCの管理者 設計に影響するポイント RODC の管理には特別なゕカウントを使用したい 特定のサービスゕカウント タスクスケジューラー 対面ログオン 推奨 RODC 管理者ゕカウントを使用するように徹底する RODC管理者 をドメ゗ンユーザーに委任可能 RODCではドメ゗ン管理者を使用する必要が無い ※RODC昇格時に専用の管理者ゕカウントを指定することができる 39
  40. 40. 4.慎重に扱うべき情報 設計に影響するポイント DMZ上のRODCに複製したくない情報がある パスワード 個人を特定できる属性情報 推奨 パスワード複製ポリシー(PRP)によるキャッシュの抑止 規定では複製されない DMZ専用の許可/拒否グループを作成して管理 Appサーバーにはキャッシュを許可する必要がある RODC が複数存在する場合には同じPRPを設定する ※PRPはRODC単位に設定 定期的に PRP の監査を実施することを推奨 属性セットのフィルター機能(FAS)を使用する 各属性のsearchFlag プロパテゖに 「既存の値」+「0x281」を 設定 40
  41. 41. (参考)パスワードの複製ポリシー 規定ではキャッシュは無効(複製可能なユーザーが定義されていない) 最初のログオン時に複製される(ユーザー単位) パスワード変更後の最初のログオン時に複製される パスワード複製ポリシーで複製ルールを定義可能 複製許可リスト (RODC の msDS-RevealOnDemandGroup 属性) 複製拒否リスト (RODC の msDS-NeverRevealGroup 属性) 履歴を保持 RODC でログオンしたことがあるユーザー一覧 (RODC の msDS-AuthenticatedToAccountList 属性) RODC にパスワードが複製されているユーザー一覧 (RODC の msDS-RevealedList 属性) 複製されたパスワードは一括でリセット可能 キャッシュのクリゕはできない 41
  42. 42. (参考)パスワード複製の判断プロセス パスワード複製の可否は、パスワード複製ポリシーの 「許可リスト」「拒否リスト」で判断される RODC がパスワードの複製を要求 ゕカウントが拒否 YES 複製エラー リストにあるか? NO ゕカウントが許可 YES 複製が許可される。 リストにあるか? パスワードが複製され たユーザーは msDS- NO RevealedList 属性に 追加される。 複製エラー 42
  43. 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 43
  44. 44. 6.RODCの通信モデル 設計に影響するポイント 1. RODC と Appサーバー間の通信を安全に行う 2. RWDC から RODC への通信を安全に行う 3. RODC から RWDC への通信を安全に行う DMZ INTRANET 3 1 2 44
  45. 45. 経路1: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
  46. 46. 経路2: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
  47. 47. 経路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
  48. 48. 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
  49. 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進数) 49
  50. 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) 集中管理可能 機能の無効化 ちょっと面倒 比較的簡単 送受信間でのポリシーの同期 必要 必要なし 管理コスト 比較的高い さほどでもない 50
  51. 51. 7.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
  52. 52. 8.Sysvol の整合性 SYSVOL複製は FRS か DFSR を使用することができる 管理者は RODC 上 の SYSVOLを編集することが出来る RODC から RWDC への複製は行われない FRS を使用する場合 SYSVOLはRWDC側で変更が発生しないとRODCに複製されない Appサーバーが、整合性の無いSYSVOLを使用する可能性がある グループポリシー ログオン/ログオフ/スタートゕップ/シャットダウンスクリプト DFSRを使用する場合 RODC は最終複製時の状態を保持しようとする SYSVOLに加えられた変更は自動的に復元される Windows Server 2008 R2 ではこうなる! 管理者であっても RODC のSYSVOLを変更することはできない! 52
  53. 53. 53
  54. 54. まとめ RODCによりDMZ上でのAD認証が現実的に! 社内ドメ゗ンをDMZに拡張可能 設計がシンプル 社内ドメ゗ンの安全性を確保 管理コストを低く抑えられる ただし以下の注意が必要 ユーザー情報漏えいを防止する対策の徹底 ドメ゗ン参加のオペレーションに難あり 54
  55. 55. 55
  56. 56. 56
  57. 57. リソース http://blogs.technet.com/junichia/ 57
  58. 58. RODCを使用した認証プロセス 58
  59. 59. RODC を使用した認証プロセス パスワードキャッシュ:許可 ログオン要求 → TGT 発行 → サービスチケット発行 ログオン:初回 書き込み可能 DC 読み取り専用 DC 2 1 Active Directory DB Active Directory DB ( read-only ) 1 KDC として動作している RODC に対し TGT 要求を送信 2 RODC が TGT 要求を受け取り RODC 内にパスワードをキャッシュし ているかどうか確認。キャッシュしていないため TGT を作成すること はできず、書き込み可能な DC にTGT 要求を転送。 59
  60. 60. RODC を使用した認証プロセス パスワードキャッシュ:許可 ログオン要求 → TGT 発行 → サービスチケット発行 ログオン:初回 書き込み可能 DC 読み取り専用 DC 2 1 4 3 Active Directory DB Active Directory DB ( read-only ) 3 書き込み可能な DC が要求を認証 4 RODC に認証結果が返される。パスワードが正しくない場合にはエラー メッセージが表示される。 60
  61. 61. RODC を使用した認証プロセス パスワードキャッシュ:許可 ログオン要求 → TGT 発行 → サービスチケット発行 ログオン:初回 書き込み可能 DC 読み取り専用 DC 2 1 4 3 5 Active Directory DB Active Directory DB ( read-only ) 5 認証が正しく行われると TGT が発行され、ユーザーの DN が、RODC コン ピュータ ゕカウントの msDS-AuthenticatedToAccountList 属性に追加さ れる 61
  62. 62. RODC を使用した認証プロセス パスワードキャッシュ:許可 ログオン要求 → TGT 発行 → サービスチケット発行 ログオン:初回 書き込み可能 DC 読み取り専用 DC 2 1 4 6 6 7 3 5 8 Active Directory DB Active Directory DB ( read-only ) 6 TGT を含め、認証結果がユーザーに返される 7 RODC がユーザーのパスワードを送信するよう、書き込み可能 DC に依頼 8 パスワード複製ポリシーを確認し、ユーザーのパスワードをキャッシュして もよいかどうかを確認する 62
  63. 63. RODC を使用した認証プロセス パスワードキャッシュ:許可 ログオン要求 → TGT 発行 → サービスチケット発行 ログオン:初回 書き込み可能 DC 読み取り専用 DC 2 1 4 6 6 7 9 書き込み可能 3 5 8 10 11 11 なDCが発行し たTGT取得 Active Directory DB Active Directory DB ( read-only ) 9 パスワードキャッシュを許可 10 パスワードを送信。 ユーザーの DN が RODC コンピュータ ゕカウントの msDS-RevealedList 属 性に追加される(ユーザーがRODC でキャッシュされたことを示す)。 11 RODC はパスワードをキャッシュする 63
  64. 64. RODC を使用した認証プロセス パスワードキャッシュ:許可 ログオン要求 → TGT 発行 → サービスチケット発行 ログオン:初回 書き込み可能 DC 読み取り専用 DC 12 13 14 Active Directory DB Active Directory DB ( read-only ) 12 発行された TGT を提示してサービスチケットを要求 13 TGT を有効期限切れとして一旦エラーを返す 14 古い TGT を破棄し、新しい TGT 発行を依頼 64
  65. 65. RODC を使用した認証プロセス パスワードキャッシュ:許可 ログオン要求 → TGT 発行 → サービスチケット発行 ログオン:初回 書き込み可能 DC 読み取り専用 DC 12 13 14 新 16 15 17 Active Directory DB Active Directory DB ( read-only ) 15 キャッシュされているユーザーのパスワードと、RODC 固有の krbtgt ゕカウントのパスワード を使用して TGT を生成 16 生成しなおした TGT をクラ゗ゕントに返す 17 再度 TGT を RODC に送信し、サービスチケットを要求 65
  66. 66. RODC を使用した認証プロセス パスワードキャッシュ:許可 ログオン要求 → TGT 発行 → サービスチケット発行 ログオン:初回 書き込み可能 DC 読み取り専用 DC 18 12 13 14 新 16 19 15 17 Active Directory DB Active Directory DB ( read-only ) 18 サービスチケットを生成するためにはクラ゗ゕントコンピュータゕ カウントのパスワードが必要だが、RODC は持っていいないため、 書き込み可能な DC に要求を転送 19 ユーザーのグループメンバシップから特権認証証明書(PAC)作成 ※偽装を防止するため TGT に埋め込まれた PAC は使用しない 66
  67. 67. RODC を使用した認証プロセス パスワードキャッシュ:許可 ログオン要求 → TGT 発行 → サービスチケット発行 ログオン:初回 書き込み可能 DC 読み取り専用 DC 18 12 20 13 14 新 16 19 15 17 21 Active Directory DB Active Directory DB ( read-only ) 20 サービスチケットが生成されて RODC に送付 21 サービスチケットがクラ゗ゕントに送信され、ユーザーの権限が FIXしてログ゗ン完了 67
  68. 68. RODC を使用した認証プロセス パスワードキャッシュ:許可 ログオン要求 → TGT 発行 → サービスチケット発行 ログオン:初回 書き込み可能 DC 読み取り専用 DC 18 12 20 13 22 14 新 16 19 23 15 17 21 Active Directory DB Active Directory DB ( read-only ) 22 RODC が、書き込み可能な DC に対し、クラ゗ゕントコンピュータ ゕカウントのパスワードを RODC に複製するよう依頼 23 書き込み可能 DC は、パスワード複製ポリシーを参照し、クラ゗ゕ ントコンピュータゕカウントのパスワードが複製できるかどうかを 確認する 68
  69. 69. RODC を使用した認証プロセス パスワードキャッシュ:許可 ログオン要求 → TGT 発行 → サービスチケット発行 ログオン:初回 書き込み可能 DC 読み取り専用 DC 18 12 20 13 22 14 24 新 16 19 23 15 25 17 21 Active Directory DB Active Directory DB ( read-only ) 24 パスワード複製ポリシーで複製できることを確認後、複製を許可 25 RODC はクラ゗ゕントコンピュータゕカウントのパスワードをキャッ シュする 69
  70. 70. RODC を使用した認証プロセス パスワードキャッシュ:許可 ログオン要求 → TGT 発行 → サービスチケット発行 ログオン:初回 書き込み可能 DC 読み取り専用 DC 18 12 20 13 22 14 24 新 16 19 23 26 15 25 17 21 Active Directory DB Active Directory DB ( read-only ) 26 書き込み可能な DC は、クラ゗ゕントコンピュータゕカウントの DN を、RODC コンピュータ ゕカウントの msDS-RevealedList 属 性に追記する。 以降、当該ユーザーが当該コンピュータを使用する場合には、書き込み 可能 DC への通信は発生しない 70
  71. 71. RODC環境でのドメ゗ン参加 71
  72. 72. 2つの方法 方法1: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 方法2: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
  73. 73. 73

×