Server」カテゴリーアーカイブ

グループポリシーのアーキテクチャ~その2~

ここでグループポリシーのまとめをします。

Windows Server 2008になってアーキテクチャが変更されたのは前回お話しいたしました。

そこで今回は疑問が生じるであろう内容をQ&A形式で書いてみます。

Q.もうadmテンプレートは必要ないのか?

A.はい、特に必要ありません。ただし、以前のカスタムadmファイルを使用することはできます。

Q.以前のカスタムadmテンプレートをVistaやw2008に適用できるの?

A.はい、できます。

Q.admxファイルで記載されている内容はXPでも使えるの?

A.はい、使えます。GPOの大原則として「テンプレートには依存しない!」ということです。

Q.admxファイルの編集ができるのはどのOS

A.Vistaとw2008です

ここで考えると、admテンプレートは過去のものとなりつつあります。理想は全てadmxにしてセントラルサイトを構築することになりますね~

では、今まで使用していたカスタムadmをadmxに自動的に変換できないのか?

回答としてはできないことはないとなります。

一応、マイクロソフトからADMX Migratorというツールが提供されています。

ということで、試しにマイクロソフトより提供されているOffice2003用のadmテンプレートを変換してみました。

Microsoft Office 2003 Service Pack 3 ADM、OPA、および説明文の更新プログラム

ん、エラーが出て変換がうまくいきません。

どうやらこのツールが想定する文法通りに記載されていないとうまくいかないようです。

admx

文字化けも結構ひどいかも~

グループポリシーのアーキテクチャ~その1~

Windows Server 2008になって、GPOのアーキテクチャの変更がありました。ではどのように変更したかというと、今まで管理用テンプレートはadmファイルとして提供していましたが、XMLベースのadmxファイルになりました。このadmxファイルは言語情報が記載されているadmlファイルと対になって提供されています。

この利点はベースの部分は同じ(admx)で、言語に依存する部分(adml)とわけることによって、言語ファイルを複数用意することにより多言語への対応が容易になります。

さらに次のようなこともあります。

今まではGPOを作成すると、ローカルのテンプレートファイルをGPOに組み込んでいました。これにより約4MのファイルがGPOごとにコピーされることになり、GPOの数が多いとsysvolフォルダの領域が大きくなり複製トラフィックの増大につながる原因になっていました。

GPO1

Windows Server 2008ではどうなったか?

基本的にGPOにはテンプレートファイルはコピーされなくなりました。それでは編集時にはどこからテンプレートファイルを参照するかというと編集しているコンピュータのローカル(c:WindowsPolicyDefinitionsフォルダ)から読み込むことになります。

参照:Windows Server 2008 リソースキット(グループポリシー編)p274

グループポリシー管理コンソール(GPMC)を使用する際、通常はPDC-EのDCに接続されますがテンプレートはローカルから。ただし、組織の要件(サイトを分けているなど)によっては必ずしもPDC-EのDCで編集するとは限りません。

このことから編集を行う全てのコンピューターのローカルに適用するadmxファイルがないと管理用テンプレートの不整合が発生する可能性があります。そこでこの問題を解決するのがセントラルサイトになります。セントラルサイトとは、sysvolにadmxファイルを保存する領域になり、これによってadmxファイルの一元管理が可能になります。

このセントラルサイトを作成すると、GPOは必ずセントラルサイトを参照することになるのでadmxファイルの不整合は起こらなくなります。特に追加のadmxファイルを入れたりするとその便利さは体感できます(Office 2007のadmxなど)

GPO2

ちなみにsysvolの複製方法としてはFRSもしくはDFSRが使用されます。DFSRの詳しい内容は安納さんのブログで紹介されています。

【Windows Server 2008】 Sysvol 複製を FRS から DFSR に移行するには Dfsrmig.exe コマンドを使用する

ではセントラルサイトの作成方法を確認します。

実はすごい簡単にできます。

通常、admxファイルは

c:WindowsPolicyDefinitions

配下にあります。

このフォルダ全部をそのまま、Sysvolホルダ配下(共有がされている方)のPoliciesホルダにコピーします

xcopy %systemroot%PolicyDefinitions* %logonserver%sysvol%userdnsdomain%PoliciesPolicyDefinitions

と入力します。

このPolicyDefinitions配下にadmlファイルが保存されている言語ごとのフォルダが入っています。日本語の場合はja-JPになります。

ですので追加の管理用テンプレートをセントラルサイトに保存するときはadmxとadmlの場所を間違えないように気お付ける必要があります。

この作業はPDC-Eで行うのが推奨となります。

FSMOを確認するには

netdom query fsmo

で確認できます。

きめ細かいパスワードポリシー(PSO)の実装~その4~

シャドーグループを使用する方法

はい、そろそろこのテーマもこれで終わりです。

そこで今回はシャドーグループを使用したPSOの使用方法のご紹介をします。

そもそも、シャドーグループとはなんなのか?から説明が必要ですね。

PSOを使って、あるOU内の全ユーザーに対して特に厳しいパスワードポリシーを適用したい・・・

というようなニーズがあった場合にどのように対応するのか?

PSOはユーザーとグローバルグループには割り当てられるがOUには割り当てられません。

そこで、どうするか?シャドーグループの登場です。

シャドーグループというのは、そういう特別なオブジェクトがあるわけではなく、PSOを適用するためにOU に論理的にマップされるただのグローバルグループのことです

シャドーグループ

シャドーグループの使用例

SalesOUに複数のユーザーがいるとき、

  • UsersコンテナなどにSalesというような名前のグローバルグループを作り、
  • Sales用のPSOを、Salesグローバルグループに割り当てておく。
  • 下記のコマンドをタスクスケジューラで、たとえば20分間隔とかで実行する。

dsquery user ou=Sales,dc=contoso,dc=com | dsmod group “CN=Sales,CN=Users,DC=contoso,DC=com” –chmbr

そうすると、SalesOUに新規にユーザーをほうりこむだけで、自動的にSalesというグローバルグループのメンバーになってくれます。

(上記コマンドのポイントは、-addmbrではなく-chmbrを使っているところ。このオプションはリプレースなので、追加だけではなく、OUから抜けたユーザーをメンバーから削除するのにも対応できます)

これによって、あたかもSales用のPSOをSalesOUに割り当てたかのような感じで運用することができます。

・・・こんな使い方をするグローバルグループをシャドーグループと呼ぶようです。

 

きめ細かいパスワードポリシー(PSO)の実装~その3~

きめ細かいパスワードポリシー(PSO)の実装をすることによってドメイン配下の「Default Domain Policy」によって制御されていたパスワードポリシーがPSOの制御にシフトされます。

ではPSOによって制御されないユーザーおよびグループはどうなるのでしょうか?

そこでパスワードポリシーの優先順位をまとめます。

  1. PSOのユーザー
  2. PSOのグループ
  3. ドメイン配下のGPO(Default Domain Policy)

ユーザーに対するPSOが最も優先されることになります。ここで重要なことはユーザーに対して設定されるパスワードポリシーとして適用できるPSOは1つだけです。

適用するPSOが複数ある場合は優先順位の設定(msDS-PasswordSettingsPrecedence)の値が最も小さいものが優先されます。もし優先順位が同じ場合はGUIDが最も小さいPSOが適用されます。

このことから考えると、優先順位の計画はしっかりと行う必要性があります。そしてPSOの優先順位の値は10単位で設定するのが、わかりやすくていいかな?

ここであるシナリオを考えます。

ABC社のセキュリティポリシーではすべてのユーザーは8文字以上で複雑性の要件を満たすパスワードにしなくてはいけません。さらに管理者であるITadminsグループのメンバーは10文字以上のパスワードを要求することになっています。また組織全体の管理を行っているEnterprise Adminsグループのメンバーは一週間ごとにパスワード変更を行わなくてはいけません。

Don HallはITadminsのメンバーでもありEnterprise Adminsのメンバーでもあります。

この場合の実装方法としては

  • 一般ユーザーにはドメイン配下のGPOで対応する
  • ITadminsグループ用にPSOを作成する
  • Enterprise Adminsグループ用にPSOを作成して、ITadminsグループ用のPSOの優先順位の設定値よりも小さい値にするアプローチと、Don Hallユーザー用のPSOを作成する方法があります

では実際に各ユーザーにどのPSOが適用されているかの確認方法としては次の通り

  • 「Actice Directory ユーザーとコンピューター」より、「表示」の「拡張機能」が有効になっていることを確認してから、ユーザーの「プロパティ」>「属性エディタ」タブの[msDS-ResultantPSO]属性を確認する方法。[msDS-ResultantPSO]属性が見つからない場合は、「フィルタ」の「読み取り専用属性の表示」の「構成済み」オプションを有効にする必要があります。
    PSO4
  • コマンドによる確認
    dsget user <ユーザーの識別名> –effectivepso
    PSO5

これにより確認ができます。

[msDS-ResultantPSO]属性が「未構成」の場合はPSOが適用されていないことになりますので、この場合は通常「Default Domain Policy」に設定されているパスワードポリシーが適用されるということになります。

きめ細かいパスワードポリシー(PSO)の実装~その2~

ADSI Edit を使用して PSO を作成するには

  1. [スタート] ボタン、[ファイル名を指定して実行] の順にクリックし、「adsiedit.msc」と入力して、[OK] をクリックします。
  2. ADSI Edit スナップインで [ADSI Edit] を右クリックし、[接続先] をクリックします。
  3. [名前] で、PSO を作成するドメインの完全修飾ドメイン名 (FQDN) を入力し、[OK] をクリックします。
  4. ドメインをダブルクリックします。
  5. [DC=<ドメイン名>] をダブルクリックします。
  6. [CN=System] をダブルクリックします。
  7. [CN=Password Settings Container] をクリックします。
  8. 選択したドメインで作成された、すべての PSO オブジェクトが表示されます。
  9. [CN=Password Settings Container] を右クリックし、[新規] をクリックして [オブジェクト] をクリックします。
  10. [オブジェクトの作成] ダイアログ ボックスの [クラスを選択] で、[msDS-PasswordSettings] をクリックし、[次へ] をクリックします。
    PSO1
  11. [] に、新しい PSO の名前を入力し、[次へ] をクリックします。
    PSO2
  12. ウィザードの手順を続行し、すべての mustHave 属性に適切な値を設定します。

ウィザードによる入力が完了すると右ペインにPSOオブジェクトが作成されるので、作成されたオブジェクトを選択して、右クリック>プロパティを選択します。そして「msDS-PSOAppliesTo」属性に対してPSO を適用するユーザーまたはグローバル セキュリティ グループの識別名を追加します。

PSO3

以上でPSOの設定が完了しました。

きめ細かいパスワードポリシー(PSO)の実装~その1~

PSO実装時の考慮点

  • PSO設定に専用ツールはないので、ADSIエディタまたはLDIFDEを使用する
  • PSOはユーザーまたはグローバルグループにのみ適用できる
  • ドメイン機能レベルがWindows Server 2008でなくてはいけない

(参考)細かい設定が可能なパスワードおよびアカウント ロックアウトのポリシー設定

あらかじめこれから作成するPSOの内容を決めておくことをお勧めします。決めておかなくてはならない項目は次の通り

PSOには既定のドメイン ポリシーで定義可能なすべての設定の属性が備わっています (Kerberos 設定は除く)。

この設定には、次のパスワード設定の属性があります。

  • パスワードの履歴を記録する (msDS-PasswordHistoryLength)
    0~1024
  • パスワードの有効期間 (msDS-MaximumPasswordAge)
    msDS-MinimumPasswordAge値~
    なし
  • パスワードの変更禁止期間 (msDS-MinimumPasswordAge)
    00:00:00:00(日:時:分:秒)
    なし
  • パスワードの長さ (msDS-MinimumPasswordLength)
    0~255
  • パスワードは、複雑さの要件を満たす必要がある (msDS-Password-ComplexityEnabled)
    FALSE/TRUE(推奨値:TRUE)
  • 暗号化を元に戻せる状態でパスワードを保存する (msDS-PasswordReversibleEncryptionEnabled)
    FALSE/TRUE(推奨値:FALSE)

これらの設定には、次のアカウント ロックアウト設定の属性も含まれます。

  • ロックアウト期間 (msDS-LockoutDuration)
    msDS-LockoutObservationWindow値~
    なし
  • アカウントのロックアウトのしきい値 (msDS-LockoutThreshold)
    アカウント ロックアウトのポリシーを無効にするには、msDS-LockoutThreshold 属性に値 0 を指定します
    0~65535
  • ロックアウト カウンタのリセット (msDS-LockoutObservationWindow)
    00:00:00:01~msDS-LockoutDuration値
    なし

2010/03/09 追記

*なし の項目は(なし)と入力する必要があります<半角のかっこ”(”と、日本語の”なし”と半角のかっこ”)”>ただし、インターフェイスは日本語入力ができないのでメモ帳で入力し、コピー&ペーストで張り付ける必要があります。

さらに、PSO には次の 2 つの新しい属性があります。

  • PSO リンク (msDS-PSOAppliesTo)
    ユーザー オブジェクトまたはグループ オブジェクトにリンクされる複数値属性です。
  • 優先順位 (msDS-PasswordSettingsPrecedence)
    ユーザーオブジェクト またはグループ オブジェクトに複数の PSO が適用されている場合に、競合を解決するために使用される整数値です。

msDS-PSOAppliesTo を除くすべての属性は、mustHave 属性です。つまり、各属性に値を指定する必要があります。異なる PSO の設定を結合することはできません。

ADの論理構造設計

Windows Server 2008になり以前のOSからADの論理構造設計に関してはあまり大きな変化はありませんが、唯一変わったことがあります。それについて考えてみます。

そもそも根本的な考え方である設計の指針があります。それは

シングルフォレスト・シングルツリー・シングルドメイン

にならないかを、まず第一に考えるということです。

シングルフォレストだと次のような要件が出てきます。

  • 別ドメインのリソースを利用者が検索・利用可能
  • ADの制御情報(スキーマ、構成)の共有
  • フォレスト全体を管理可能な管理者が存在する(Enterprise Admins)

これらの要件がセキュリティ的にそぐわない場合はマルチフォレストになります。

それでは、マルチドメインの選択基準としては次のようになります。

  • 大規模環境で、ADデータベースサイズや複製トラフィックを最適化したい
  • 分散管理
  • 法的規制
  • 組織ごとのパスワードポリシー

ここでWindows Server 2008のドメイン機能レベルをWindows Server 2008にすることにより新機能であるPSO「Windows Server 2008 のきめ細かなパスワードポリシー」が使用できますので「組織ごとのパスワードポリシー」を考慮しなくてもよくなりました。

今までは、パスワード設定とアカウントロックアウト設定はドメインに限られていて、ドメインごとに1 つの設定しか適用できませんでした。異なるパスワードポリシーを必要とする場合は、ドメインを複数展開する必要があったんですが、Windows Sever 2008ではユーザーやグループごとに複数のパスワード設定とアカウントロックアウト設定を構成できるようになったんです。

次回はWindows Server 2008の新機能であるPSOについて考えてみたいと思います。

DHCPの冗長構成を考える~その4~

セキュリティで保護された動的更新

DNSの動的更新のセキュリティは3つあります

  • なし
  • 非セキュリティ保護およびセキュリティ保護
  • セキュリティ保護のみ

ここで通常はセキュリティ保護のみに設定します。こうすれば、ADに登録されたオブジェクトからしか動的更新を受け付けることはありません。

最も端的な例としては、外部のユーザーがドメインネットワーク接続しても動的更新によってDNSにアドレスの登録は行うことができないということです。

では動的更新のセキュリティ設定が「セキュリティ保護のみ」に設定されていてDHCPの冗長構成を考えます。ふ~、やっと本題に入れます。

DNS-DHCP

同一セグメントに複数台のDHCPがあると仮定します。ここではDHCP1とDHCP2があります。そしてDHCPの動的更新も行います。ここでDHCP1で登録されたクライアントのレコードがあります。これをClient1とします。このClient1はDHCP1によって登録されたので、このレコードの所有者はDHCP1ということになります。ここで、DHCP1がダウンしてDHCP2のみでの運用となります。ここでClient1が更新を行います。DHCP2はDNSに登録されているClient1の更新をかけますが、所有者がDHCP1のためエラーとなります。

これは問題ですね~

まあ、通常ではDHCPが登録するのはPTRレコードになるので気にすることはないかもしれませんが、DHCPがA,PTRレコード両方を登録する設定になっていたらこれは大問題になります。

そこでADのグループには「DNSUpdateProxy」というグループが用意されています。

この「DNSUpdateProxy」に各DHCPサーバーのコンピューターオブジェクトを登録することにより所有者の問題は解決されます。が、DNSの設定で動的更新のセキュリティ設定が「セキュリティ保護のみ」だと登録がうまくいきません

それはDHCP サーバーが DnsUpdateProxy グループのメンバである場合、DHCP サーバーによって登録される DNS ドメイン名はセキュリティで保護されないからです。

そのためにはどうするか?

DNSの動的更新専用アカウントを作成して、DHCPサーバーに設定すれば解決できます。

DNS-詳細設定タブ

このページの資格情報をクリックして設定します。

まとめ

DHCPの冗長構成を行う場合は

  • DNSUpdateProxyというグループにDHCPのコンピューターオブジェクトを登録する
  • DNSの動的更新専用アカウントを作成して、DHCPサーバーに設定する

ということになりますね。

DHCPの冗長構成を考える~その3~

DHCPサーバーからDNSの動的更新を行う場合考慮しなくてはいけないポイントがあります。

まずは、DNSの動的更新とはどのような動作なのかを理解する必要があります。

以前はDNSのレコードは管理者が登録するものでした。しかし、昨今の環境ではクライアントの名前解決においてもDNSを使用することが一般的になることによって管理者がクライアントのレコードを登録するというのは難しくなってきました。またDHCPを使用している場合動的にIPアドレスが変更されるため尚更難しいということになります。

そこで考え出されたのがDNSの動的更新になります。

まず、クライアントの一般的な動作から考えます。

前提としてTCP/IPの詳細設定において「□この接続のアドレスをDNSに登録する」にチェックが入っていることになります。デフォルトではチェックが入っているので通常は気にしませんね。

tcpip詳細設定

ここで2つのパターンがあります。それは静的IPアドレスと動的IPアドレスの場合です。

静的IPアドレスの場合はクライアントが直接DNSサーバーにAレコードとPTRレコードの登録を行います。

動的IPアドレスの場合(DHCPからIPアドレスを取得した場合)

ここの動作はちょっと解説が必要になります。まず、前提としてDHCPのDNSタブの設定が絡んでくるんです。

DHCP-DNSタブ

デフォルトの状態では「以下の設定に基づいて、DNS動的更新を有効にする」にチェックが入っています。そして「DHCPクライアントから要求があったときのみDNSのAレコードおよびPTRレコードを動的に更新する」にチェックが入っています。

さて、ここでDHCPクライアントから要求~とありますがどういうことかというと、DHCP オプションであるクライアント FQDN オプション (オプション 81) を考慮する必要があるんです。

Windows Server 2003 で DNS 動的更新を構成する方法

以下参考リンクより抜粋~~

このオプションを使用すると、クライアントから FQDN を DHCPREQUEST パケットで DHCP サーバーに送信することができます。これで、クライアントは必要なサービス レベルを DHCP サーバーに通知できます。

FQDN オプションには、次の 6 つのフィールドがあります。

  • Code
    このオプションのコード (81) を指定します。
  • Len
    このオプションの長さ (4 以上) を指定します。
  • Flags
    サービスの種類を指定します。

    • 0
      クライアントが “A” (ホスト) レコードを登録します。
    • 1
      クライアントが DHCP に “A” (ホスト) レコードを登録させます。
    • 3
      クライアントの要求にかかわらず、DHCP が “A” (ホスト) レコードを登録します。
  • RCODE1
    サーバーがクライアントに送信する応答コードを指定します。
  • RCODE2
    RCODE1 の追加記述を指定します。
  • Domain Name
    クライアントの FQDN を指定します。

クライアントがリソース レコードを DNS に登録するよう要求した場合、クライアントは、RFC (Request for Comments) 2136 に従って、動的 UPDATE 要求を生成します。すると、DHCP サーバーが PTR (ポインタ) レコードを登録します。
このオプション 81 が、Windows Server 2003、Microsoft Windows 2000、または Microsoft Windows XP を実行する DHCP が利用できるコンピュータなどの有効な DHCP クライアントによって発行されたものであるとします。この場合、Windows Server 2003 ベースの DHCP サーバーによってオプションが処理および解釈されて、サーバーがクライアントのために更新をどのように開始するかが判断されます。

ここまで~~

ここで重要なのはクライアントからのオプション81のデフォルトはFlagsが0ということです。通常この設定を変えることはありません。

では話は戻って、DHCPサーバーの設定は「DHCPクライアントから要求があったときのみDNSのAレコードおよびPTRレコードを動的に更新する」になっています。そしてクライアントはFlagsが0なのでクライアントが “A” (ホスト) レコードを登録します。

ということで、デフォルトの動作ではクライアントがAレコード、DHCPサーバーがPTRレコードを登録するということになります。

そして、DHCPサーバーの設定を「DNSのAおよびPTRレコードを常に動的に更新する」にチェックを入れると、DHCPサーバーがクライアントのA、PTRレコードを登録するという動作になります。

ここで冗長構成の動作を考えると問題になることがあります。

それは次回に・・・