いよいよTech・Edの夏が近づいてまいりました。
私の周囲も、ピリピリとした緊張感で満たされつつあります。
今年のTech・Edは 8月26日～28日の3日間と、従来よりも1日少なくなっています。が、そのぶん、内容は濃くなる予定です。
私はといえば、2つのセッションを担当する予定です。
Windows Server 2008 R2 であたらしく実装された Active Directory および グループポリシーの機能について詳しく解説します。おそらく、PowerShell によるデモンストレーションを多く含んだ内容になるかと思います。 私が最も注目している Active Directory Recycle Bin、そしてGroup Policy のPowerShellによる操作、いずれも、今後の運用管理にとって非常に重要な機能です。もう、いまから皆さんの前でお話するのが楽しみで仕方ありません。 …と言っておきながら、直前になると「あぁ、ひょんなことからキャンセルにならないかなぁ」とか思ったりします。
Windows Server 2008 R2 であたらしく実装された Active Directory および グループポリシーの機能について詳しく解説します。おそらく、PowerShell によるデモンストレーションを多く含んだ内容になるかと思います。
私が最も注目している Active Directory Recycle Bin、そしてGroup Policy のPowerShellによる操作、いずれも、今後の運用管理にとって非常に重要な機能です。もう、いまから皆さんの前でお話するのが楽しみで仕方ありません。
…と言っておきながら、直前になると「あぁ、ひょんなことからキャンセルにならないかなぁ」とか思ったりします。
Track6は、これまでになかったトラックです。ビジネスソリューショントラックと名付けられているとおり、ビジネスの現場で使える「ソリュ��ション」について解説するために用意されています。そこで、私はActive Directory をより広く活用していただきつつ、これまでの「エクスペリエンス」を継承できるソリューションとして「ADのインターネット利用シナリオ」について解説したいと思います。 ちなみに、ADのインターネットシナリオについては、以前、このBLOGでもご紹介しましたのでごらんになってみてください。TechEdに向けて、すこしずつ情報を発信していきたいと思いますので、当BLOGも、引き続きチェックをお願いします。
Track6は、これまでになかったトラックです。ビジネスソリューショントラックと名付けられているとおり、ビジネスの現場で使える「ソリュ��ション」について解説するために用意されています。そこで、私はActive Directory をより広く活用していただきつつ、これまでの「エクスペリエンス」を継承できるソリューションとして「ADのインターネット利用シナリオ」について解説したいと思います。
ちなみに、ADのインターネットシナリオについては、以前、このBLOGでもご紹介しましたのでごらんになってみてください。TechEdに向けて、すこしずつ情報を発信していきたいと思いますので、当BLOGも、引き続きチェックをお願いします。
実を申しますと、6月1日がセッション概要の提出締め切りで、7月31日がスライドの締め切りとなっています。ちょいと、いま、てんてこ舞っている最中です。
p.s. 昨年あまり話題にもならなかった「肩たたき券」は、今年も継続するかどうか思案中です…
お知らせです。
テックフィールダーズからPPT のクリップアート集が提供され始めました。
その名も テッキー 君。
上記のような orzな絵や、得意満面なヤツなど、全部で21種類のテッキー君に加え、以下のように顔を自由に書き込んで流用していただける気の利いたバージョンも用意されています。
是非ともみなさん流にアレンジして、プレゼンや勉強会で使い倒してください！
なぜか、耳の生えたこんなヤツもあります。
ダウンロードは以下から！
テッキー君 PPT素材集
● テッキーくん一覧 (PPT版): http://download.microsoft.com/download/6/8/0/6800CEAC-FABC-4E9C-ABDB-F890FBA93F42/Tekki-kun.pptx ●テッキーくん 画像データ: http://download.microsoft.com/download/6/8/0/6800CEAC-FABC-4E9C-ABDB-F890FBA93F42/Tekki-kun.zip
安納＠四国支店（高松）です。
本日17日から3日間、高松でテクニカルセッションを持ちます。
ひとまず今日はコミュニティ勉強会ということで、既にコミュニティの方々が集まって準備が進められています。
で、「あ、水も用意しておかないとね」と冷蔵庫をあけてみると…そこには…
み、みてはいけないものを見てしまった気がします。
高松支店の社員は、夜な夜なこいつで 何かを補給しているのでしょうか…。
支店長におそるおそる確認したところ、「コミュニティの皆さんに配ってください！」とのことですので、本日、高松支店にいらっしゃるみなさんはお楽しみに！
唐突にすみません。
5月18日に、同僚の田辺による Windowsクライアント 展開のセミナーがあります。
Tech Fielders セミナー 東京[MDT (Microsoft Deployment Toolkit) を使った Windows クライアント展開の自動化]
実は、システムのトラブルで、このセミナーだけお申し込みができない状態になっていたみたいでして・・・。
担当の田辺はこのとおり泣いております。
お申し込みをトライしてだめだったと言う方、ご迷惑をおかけしてしまい申し訳ございません。
是非ともリトライをお願いいたします！
ちょっと非日常的な光景だったのでつい。
携帯で恐縮ですが…
オペラシティの45Fからです。
こんなときに限って、一眼レフ持った人たちが出張なんですよね…。
まず、ちょっとだけ告知させてください。
以下のセミナーでLT登壇者を募集中です！
--------------------------------------------------------------------------------------
さて、先日以下の投稿をしました。
【IDM】Active Directory の DMZ シナリオがようやく登場！ーActive Directory Domain Services in the Perimeter Network http://blogs.technet.com/junichia/archive/2009/05/01/3233958.aspx
ざくっと読んでみたので、何回かに分けて投稿したいと思います。ちょいと今週来週とたてこんでいるので、間が空くかと思いますが…。
まずはじめに、このガイドの冒頭にこんなことが書かれています。
このガイドを読んだ後になって、「AD DSをDMZに展開することに何のベネフィットも無い」と感じるかもしれませんし、もしかすると他のソフトウェアを使って展開したほうがベネフィットが多いと感じる可能性もあります。そう思ったということは、あなたの環境におけるベストな選択肢は、「DMZにADを展開しない」ということになるかもしれません。
うーん。いきなりアレなかんじですが（笑）、要は、
技術的にできるからといって無理に適用すると帰って危険に鳴らす可能性がありますから気をつけましょう
ということです。決して弱気になっているわけではありません。
さて、さっそくはじめましょう。今回は「4つのAD DSモデル」についてお話します。
まず、大前提として以下の要件があることを確認しておいてください。
【要件】
インターネットからのユーザーに対してアプリケーションを公開したい ユーザーにはIDとパスワードで認証および承認を行いたい
これを実現するために、大きく分けて、以下に示す4つのモデルが考えられます。
【モデル１：AD DS を DMZ に展開しない】
第一の選択肢は、AD DSをDMZに展開せず、DMZ上のアプリケーションサーバー上にユーザーIDを作成して個別に管理するという方法です。 この方法のデメリットは、DMZ上のサーバー（たとえばWEBサーバー）のアカウント管理をサーバー個別に行わなければならないという点です。もちろん、この場合の認証はローカルのSAMとなるため、Kerberos認証を使用することはできません。 また、サーバー間でSAMを共有することはできないため、例えば図にある3台のサーバーで個別にアカウントを管理する必要があります。
第一の選択肢は、AD DSをDMZに展開せず、DMZ上のアプリケーションサーバー上にユーザーIDを作成して個別に管理するという方法です。
この方法のデメリットは、DMZ上のサーバー（たとえばWEBサーバー）のアカウント管理をサーバー個別に行わなければならないという点です。もちろん、この場合の認証はローカルのSAMとなるため、Kerberos認証を使用することはできません。
また、サーバー間でSAMを共有することはできないため、例えば図にある3台のサーバーで個別にアカウントを管理する必要があります。
【モデル2：AD DSを独立したフォレストで展開する】
AD DSをDMZに展開するのですが、社内（プライベートネットワーク）とは独立したフォレストで展開するモデルです。
このモデルの場合には、DMZ上のサーバーの認証を統合することができます。が、フォレストが分割されているため、基本的に社内のフォレストとは通信は行わないため、よって、社内ドメインとのWindows統合認証機能は使用できません。 Exchange Server など、AD DSを必須とするアプリケーションサーバーの場合には、最低限、このモデルを採用する必要があります。
このモデルの場合には、DMZ上のサーバーの認証を統合することができます。が、フォレストが分割されているため、基本的に社内のフォレストとは通信は行わないため、よって、社内ドメインとのWindows統合認証機能は使用できません。
Exchange Server など、AD DSを必須とするアプリケーションサーバーの場合には、最低限、このモデルを採用する必要があります。
【モデル3：社内のフォレストをDMZまで拡張】
ちょっと図がわかりずらくて恐縮ですが、青い三角形（フォレストを意味します）がDMZと社内ネットワークをカバーしているところに注目してください。 このモデルを採用すると、もともと存在する社内ドメインを使用することができるので、通常のドメインコントローラをDMZに展開することもできますし、なにより RODC（Read Only Domain Contoroller）を展開できるというメリットがあります。また、IDを一元管理できるため、社内で使用するIDと同じIDをインターネット上からも使用できます。もちろんパスワードも同じですし、ユーザーの権限も社内ドメインで制御できます。 RODCを採用する場合、RODC上にはパスワードを持たないようにすることができるため、従来のドメインコントローラと比較すると安全性が格段に上がります。また、Read Only と言うくらいで、書き込みも制限されています。RODC について詳しい情報はこちら（TechCenter ブランチオフィスソリューション)をご覧ください。また、RODCに関する過去の投稿はこちらです。 ただし…DMZ上のアプリケーションがドメインコントローラに何らかの書き込みをする必要がある場合には、RODCは残念ながら採用が難しくなるでしょう…。
ちょっと図がわかりずらくて恐縮ですが、青い三角形（フォレストを意味します）がDMZと社内ネットワークをカバーしているところに注目してください。
このモデルを採用すると、もともと存在する社内ドメインを使用することができるので、通常のドメインコントローラをDMZに展開することもできますし、なにより RODC（Read Only Domain Contoroller）を展開できるというメリットがあります。また、IDを一元管理できるため、社内で使用するIDと同じIDをインターネット上からも使用できます。もちろんパスワードも同じですし、ユーザーの権限も社内ドメインで制御できます。
RODCを採用する場合、RODC上にはパスワードを持たないようにすることができるため、従来のドメインコントローラと比較すると安全性が格段に上がります。また、Read Only と言うくらいで、書き込みも制限されています。RODC について詳しい情報はこちら（TechCenter ブランチオフィスソリューション)をご覧ください。また、RODCに関する過去の投稿はこちらです。
ただし…DMZ上のアプリケーションがドメインコントローラに何らかの書き込みをする必要がある場合には、RODCは残念ながら採用が難しくなるでしょう…。
【モデル4：フォレスト間の信頼関係を構築する】
モデル2と似ていますが、このモデルでは社内ドメインとの信頼関係を結んでいます。 このモデルでは、ID管理者社内ドメインで行い、信頼関係によって認証を行うため、社内のID情報をDMZにさらす必要がありません。上の図では双方向に信頼関係が結ばれていますが、DMZから社内への1方向の信頼でもOKです。 ただし、このモデルの難点は管理コストが確実に増えてしまうという点です。DMZドメインのメンテナンスをしなければなりませんし、DMZと社内間のFirewallの設定も複雑になります。 このモデルに似た構成として、AD FS（Active Directory フェデレーションサービス）があります。
モデル2と似ていますが、このモデルでは社内ドメインとの信頼関係を結んでいます。
このモデルでは、ID管理者社内ドメインで行い、信頼関係によって認証を行うため、社内のID情報をDMZにさらす必要がありません。上の図では双方向に信頼関係が結ばれていますが、DMZから社内への1方向の信頼でもOKです。
ただし、このモデルの難点は管理コストが確実に増えてしまうという点です。DMZドメインのメンテナンスをしなければなりませんし、DMZと社内間のFirewallの設定も複雑になります。
このモデルに似た構成として、AD FS（Active Directory フェデレーションサービス）があります。
ひとまず今回はここまでで失礼します。
マイPCを Windows 7 RC にアップグレード中で、ちょいと手持ち無沙汰な安納です。
さて、タイトルにあるとおり、Active Directory を インターネット上で使用するためのガイドが公開されました（英語ですいません）。ガイド内では Perimeter Network（境界ネットワーク）と書かれています。
Active Directory Domain Services in the Perimeter Network (Windows Server 2008) について http://technet.microsoft.com/ja-jp/library/dd728034(en-us).aspx ※WORD形式のドキュメントはこちらからダウンロードできます
Active Directory Domain Services in the Perimeter Network (Windows Server 2008) について http://technet.microsoft.com/ja-jp/library/dd728034(en-us).aspx
※WORD形式のドキュメントはこちらからダウンロードできます
さて、このガイドには以下について書かれています。
これだけ見てもワクワクしますね！
思い起こせば2年前のTech・Ed 2007。RODC（Read Only Domain Controller）の セッションを担当し、「今後インターネット上でのActive Directoryも夢でなくなりました」と発言したことが昨日のことのようです。
まだきちんと読んでいないので詳しくご紹介できなくてすみません。ひと段落つきましたら、実験してみたいと思います。
Tech・Ed 2009 が終わったら、コレをねたにセミナーでもやりたいなぁと漠然と考えております。
Windows 7 RCがようやく公開されましたね。
で、細かい話で恐縮なのですが…
XPから実装されている、Prnmngr.vbs をはじめとするプリンター関連スクリプトってお使いですか？
ローカルプリンターを作ったり、設定変更したり、ドライバーをインストールしたり、ジョブを確認したりできる高機能なスクリプト群です。大変使い勝手がよいスクリプト達で、当然Windows 7でも実装されているだろうなと思って確認したところ…
えぇぇえ、そんなばかなぁぁぁぁ。
これは、「グループポリシー基本設定を使え！」ということか？とイラっとしかけたところ…「あ、Vistaと同じか？」と思い当たりました。
案の錠、以下に置いてありました。
C:\Windows\System32\Printing_Admin_Scripts\ja-JP
もぉぉぉぉっ！こういうところが少し嫌いです。
XP から Vista をスキップして Windows 7 に移行を計画されているエンジニアのみなさん…よろしくお願いいたします。