DHCP ServerでMACアドレスフィルタリングを行う

コメントを残す

Windows Server 2008で提供されているDHCPサーバーではMACアドレスによるフィルタリングはサポートされていません。これはNTの時代から変わっていませんね。

実際問題、私がSEをしていた頃に登録したMACアドレスにしかIPアドレスの配布をしたくないというお客様がいて、サードパーティ製のDHCPサーバーを購入して対応した記憶があります。

先日Windows Server 使い倒し塾のブログを見ていたら、なんとフリーのツールを使用することによってWindows Server 2003以降（2008も含む）のDHCPサーバーでMACアドレスフィルタリングを使用できるようなんです。

そのツールとはCallout DLLというものです。Microsoft Windows DHCP Team Blogにて紹介がされています。

CallOutHP

そして、さらにリンクがあり、Connect The Worldをクリックします。

CallOutHP1

そして一番下にDownloadのリンクがありますのでそこからツールをダウンロードします。

そして32ビットと64ビット版がありますので使用する方をダウンロードしてDHCPサーバーに対してインストールします。見た目は全くかわりませんね～

変わる場所はレジストリになります。

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesDHCPServerParameters

この中のパラメータがCallOut DLLに影響を及ぼすようです。

  • CalloutDlls：ツールのパス
  • CalloutEnabled：1の場合は起動で、0にすればロードされません
  • CalloutErrorLogFile：ログファイルのパス
  • CalloutInfoLogFile：情報ファイルのパス
  • CalloutMACAddressListFile：これが肝のアクセス制御ファイルのパス

デフォルトではc:WindowsSystem32dhcp 配下に設定されていることがregeditから確認できます。

reg  File

そして実際の操作に関しては次の2通りがあります。

  • 許可リスト：DHCPを使用する全ての端末MACを登録する
  • 拒否リスト：DHCPを使用させない端末のMACを登録する

このリストの記載方法は次の通り

#MACList.txt
MAC_ACTION = {ALLOW / DENY}
#List of MAC Addresses:
000a0c0d1254 #lab-server1
000d0c4a6723 #lab-server2
…
…

これはREADMEに記載してあるものなんですが、先頭に＃があるのはコメントですね。そしてMAC_ACTIONに許可もしくは拒否を設定する。そこでちょっとはまったのが、その書き方なんです。これって

MAC_ACTION = ALLOW

でうまくいくと思ったんですが、何度やってもうまくいきませんでした。試しに

MAC_ACTION = {ALLOW}

としたらうまくいきました。

あとは、クライアントのMACアドレスを登録すればうまく動きます。いや～、これはこれで便利ですね。

まとめ

今までこのような機能のニーズはあったにも関わらず、マイクロソフトのDHCPではサポートしていませんでした。が、Windows Server 2008 R2 のDHCPサーバーはMACアドレスフィルターをサポートするようです。

グループポリシーのアーキテクチャ～その２～

コメントを残す

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

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

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

グループポリシーのアーキテクチャ～その１～

コメントを残す

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）の実装～その４～

コメントを残す

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

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

そこで今回はシャドーグループを使用した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）の実装～その３～

コメントを残す

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

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

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

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

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

適用する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）の実装～その２～

コメントを残す

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）の実装～その１～

コメントを残す

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 の設定を結合することはできません。

書籍の紹介

コメントを残す

最近購入した書籍の紹介をします。

Microsoft Windows Server 2008 リソースキット Active Directory編 (マイクロソフト公式解説書) (マイクロソフト公式解説書)

Microsoft Windows Server 2008 リソースキット グループポリシー編 (マイクロソフト公式解説書) (マイクロソフト公式解説書)

Microsoft Windows Server 2008 PKI & 認証セキュリティ大全 (マイクロソフトITプロフェッショナルシリーズ)

新版暗号技術入門 秘密の国のアリス

これらの本はかなり有用な書籍になります。

リソースキットはマイクロソフトOSでの構築を行うSEにとってはバイブルのようなものですね～

また新版の暗号技術入門は暗号化の基礎から応用まで解りやすく解説されているお勧めの良本になります。

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について考えてみたいと思います。