SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

Archive for the ‘Active Directory’ Category

Active Directory のトレースログを取得 – Windows Server 2003 –

leave a comment

以前、AD の勉強をしていた時にクライアントから発行される AD の LDAP クエリはキャプチャできないのかな~と思い調べたことがあり、
パフォーマンスモニタのトレースログで AD の情報を取得することで、LDAP クエリがキャプチャできそうでした。
今週、このトレースを久しぶりに取得してみる機会があったので、せっかくなのでブログにも投稿を。
# この辺の情報があまり見つけられず、これであっているのかがいまいちわからないのですがそれらしい情報が取得できます。

私の検証環境に Windows Server 2003 / Windows Server 2008 の AD がありましたのでこれを使ってトレースログを
取得してみたいと思います。
今回は Windows Server 2003 で。

■Windows Server 2003 でトレースログを取得

トレースログはパフォーマンスモニタから取得することができます。

  1. パフォーマンスモニタは [管理ツール] の [パフォーマンス] または、[ファイル名を指定して実行] から [perfmon.exe] を実行します。
    image
    image 
    パフォーマンスモニタの [パフォーマンス ログと警告] の中に [トレース ログ] があります。
    このトレース ログを使用することで AD のクエリ情報を取得できそうです。
    image 
  2. トレース ログを右クリックして、[新しいログの設定] をクリックします。
    image
  3. ログの名前を入力して、[OK] をクリックします。
    image
  4. ここでシステム外のプロバイダの [追加] をクリックし、[Active Directory: Core] を追加します。
    image image
  5. デフォルトの設定では、作成したと同時に開始されてしまいますので、スケジュールを [手動] にしておきます。
    image
  6. [OK] を押して準備完了です。
    image 

    ログの出力先のディレクトリが存在していない場合は、警告メッセージが表示されるので [はい] をクリックして、
    ディレクトリを作成します。
    image

  7. 作成したトレース ログを開始すると取得が始まります。
    image

取得したファイルは出力先のディレクトリに、[etl] ファイルとして出力されます。
image

ここで、クライアント端末からログインをしてみます。
image

ログインが終わったらログの取得を停止します。
image

■ログの成形

取得したログはバイナリ形式ですのでそのままでは内容を確認できません。

以前、WSFC のログについて で投稿した、[tracerpt] コマンドを使ってログを成形することができます。
以下はコマンドの例になります。

C:perflogs>tracerpt "Active Directory Trace_000001.etl" -o log.txt

入力
—————-
ファイル:
     Active Directory Trace_000001.etl

100.00%

出力
—————-
テキスト (CSV):         log.txt

コマンドは、正しく完了しました。

このログファイルの中で [DsDirSearch] となっている個所が、LDAP のクエリ検索に使用された情報になるようですので、
[FIND] コマンドでこの行だけを切り出します。

find log.txt “DsDirSearch” > report.txt

切り出した内容がこちらです。
クライアントのログイン処理に関連しそうな情報を貼り付けてみました。
[10.2.0.2] はクライアントに割り当てている IP になります。

Event Name,       Type,        TID,           Clock-Time, Kernel(ms),   User(ms), User Data

DsDirSearch,      Start, 0x000001EC,   129103742780181356,        180,       1200, "DS", 3, 3, 1141178432,        0, "NTDSAPI", "deep", "DC=exchange,DC=local", "0, 0
DsDirSearch,        End, 0x000001EC,   129103742780181356,        180,       1200, "DS", 3, 5, 1157955648,        0, "0", " (sAMAccountName=user_2010)", "idx_sAMAccountName:1:N;", "1", "1", "0, 0

DsDirSearch,      Start, 0x000001EC,   129103742780337608,        180,       1200, "DS", 3, 3, 1141178432,        0, "NTDSAPI", "deep", "DC=exchange,DC=local", "0, 0
DsDirSearch,        End, 0x000001EC,   129103742780337608,        180,       1200, "DS", 3, 5, 1157955648,        0, "0", " (sAMAccountName=user_2010)", "idx_sAMAccountName:1:N;", "1", "1", "0, 0

DsDirSearch,      Start, 0x00000A40,   129103742780493860,         15,        105, "DS", 3, 3, 1141178432, 1075970048, "10.2.0.2", "deep", "DC=exchange,DC=local", "0, 0
DsDirSearch,        End, 0x00000A40,   129103742780493860,         15,        105, "DS", 3, 5, 1157955648, 1075970048, "0", " (distinguishedName=DC=exchange,DC=local)", "idx_distinguishedName:1:N;", "1", "1", "・0, 0

DsDirSearch,      Start, 0x000003F4,   129103742780650112,        510,       5895, "DS", 3, 3, 1141178432, 1612840960, "10.2.0.2", "base", "CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=exchange,DC=local0, 0
DsDirSearch,        End, 0x000003F4,   129103742780650112,        510,       5895, "DS", 3, 5, 1157955648, 1612840960, "0", "[]", "[]", "1", "1", "0, 0

DsDirSearch,      Start, 0x00000A40,   129103742780806364,         15,        105, "DS", 3, 3, 1141178432, 1075970048, "10.2.0.2", "deep", "cn=policies,cn=system,DC=exchange,DC=local", "0, 0
DsDirSearch,        End, 0x00000A40,   129103742780806364,         15,        105, "DS", 3, 5, 1157955648, 1075970048, "0", " (distinguishedName=CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=exchange,DC=local) 0, 0

Start と End で1 ブロックのようです。Start と End は同一の TID となるようですね。
ログインに使用したユーザー名の情報が出力されています。
また、IP アドレスが記載されているものもありますね。

試しに [0x00000A40] の情報を使って AD に問い合わせをしてみたいと思います。
問い合わせには、[dsquery] コマンドを使用します。

dsquery * -filter " (distinguishedName=CN={31B2F340-016D-11D2-945F-C04FB984F9},CN=Policies,
CN=System,DC=exchange,DC=local) " -attr *

objectClass: top
objectClass: container
objectClass: groupPolicyContainer
cn: {31B2F340-016D-11D2-945F-00C04FB984F9}
distinguishedName: CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=exchange,DC=local
instanceType: 4
whenCreated: 01/17/2010 11:06:20
whenChanged: 02/11/2010 11:53:57
displayName: Default Domain Policy
uSNCreated: 17776
uSNChanged: 17776
showInAdvancedViewOnly: TRUE
name: {31B2F340-016D-11D2-945F-00C04FB984F9}
objectGUID: {37E0FE6E-DFA9-47FE-8BCA-E5AC7FFA57FA}
flags: 0
versionNumber: 65539
systemFlags: -1946157056
objectCategory: CN=Group-Policy-Container,CN=Schema,CN=Configuration,DC=exchange,DC=local
isCriticalSystemObject: TRUE
gPCFunctionalityVersion: 2
gPCFileSysPath: exchange.localsysvolexchange.localPolicies{31B2F340-016D-11D2-945F-00C04FB984F9}
gPCMachineExtensionNames: [{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{53D6AB1B-2488-11D1-A28C-00C04FB94F17}][{827D319E-6EAC-11D2-A4EA-00C04F79F83A}{803E14A0-B4FB-11
D0-A0D0-00A0C90F574B}][{B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A}{53D6AB1B-2488-11D1-A28C-00C04FB94F17}]
gPCUserExtensionNames: [{3060E8D0-7020-11D2-842D-00C04FA372D4}{3060E8CE-7020-11D2-842D-00C04FA372D4}]
ADsPath: LDAP://EXCHANGE-AD-02.exchange.local/CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=exchange,DC=local

この情報はグループポリシーのために発行したクエリのようですね。

トレースは、dsquery の LDAP フィルタの式のサンプルとしても利用することが可能です。
クライアント PC 起動時に AD 側でトレースを取得しているとコンピュータアカウントで発行されたクエリが取得できます。

次回は Windows Server 2008 で同様の作業を実施してみます。
こちらは、クライアント PC 起動時の情報を取得するシナリオを実施したいと思います。

Written by Masayuki.Ozawa

2月 11th, 2010 at 3:50 pm

Posted in Active Directory

Active Directory のトレースログを取得 ? Windows Server 2003 –

leave a comment

以前、AD の勉強をしていた時にクライアントから発行される AD の LDAP クエリはキャプチャできないのかな~と思い調べたことがあり、
パフォーマンスモニタのトレースログで AD の情報を取得することで、LDAP クエリがキャプチャできそうでした。
今週、このトレースを久しぶりに取得してみる機会があったので、せっかくなのでブログにも投稿を。
# この辺の情報があまり見つけられず、これであっているのかがいまいちわからないのですがそれらしい情報が取得できます。

私の検証環境に Windows Server 2003 / Windows Server 2008 の AD がありましたのでこれを使ってトレースログを
取得してみたいと思います。
今回は Windows Server 2003 で。

■Windows Server 2003 でトレースログを取得

トレースログはパフォーマンスモニタから取得することができます。

  1. パフォーマンスモニタは [管理ツール] の [パフォーマンス] または、[ファイル名を指定して実行] から [perfmon.exe] を実行します。
    image
    image?
    パフォーマンスモニタの [パフォーマンス ログと警告] の中に [トレース ログ] があります。
    このトレース ログを使用することで AD のクエリ情報を取得できそうです。
    image?
  2. トレース ログを右クリックして、[新しいログの設定] をクリックします。
    image
  3. ログの名前を入力して、[OK] をクリックします。
    image
  4. ここでシステム外のプロバイダの [追加] をクリックし、[Active Directory: Core] を追加します。
    image image
  5. デフォルトの設定では、作成したと同時に開始されてしまいますので、スケジュールを [手動] にしておきます。
    image
  6. [OK] を押して準備完了です。
    image?

    ログの出力先のディレクトリが存在していない場合は、警告メッセージが表示されるので [はい] をクリックして、
    ディレクトリを作成します。
    image

  7. 作成したトレース ログを開始すると取得が始まります。
    image

取得したファイルは出力先のディレクトリに、[etl] ファイルとして出力されます。
image

ここで、クライアント端末からログインをしてみます。
image

ログインが終わったらログの取得を停止します。
image

■ログの成形

取得したログはバイナリ形式ですのでそのままでは内容を確認できません。

以前、WSFC のログについて で投稿した、[tracerpt] コマンドを使ってログを成形することができます。
以下はコマンドの例になります。

C:perflogs>tracerpt "Active Directory Trace_000001.etl" -o log.txt

入力
—————-
ファイル:
???? Active Directory Trace_000001.etl

100.00%

出力
—————-
テキスト (CSV):???????? log.txt

コマンドは、正しく完了しました。

このログファイルの中で [DsDirSearch] となっている個所が、LDAP のクエリ検索に使用された情報になるようですので、
[FIND] コマンドでこの行だけを切り出します。

find log.txt “DsDirSearch” > report.txt

切り出した内容がこちらです。
クライアントのログイン処理に関連しそうな情報を貼り付けてみました。
[10.2.0.2] はクライアントに割り当てている IP になります。

Event Name,?????? Type,??????? TID,?????????? Clock-Time, Kernel(ms),?? User(ms), User Data

DsDirSearch,????? Start, 0x000001EC,?? 129103742780181356,??????? 180,?????? 1200, "DS", 3, 3, 1141178432,??????? 0, "NTDSAPI", "deep", "DC=exchange,DC=local", "0, 0
DsDirSearch,??????? End, 0x000001EC,?? 129103742780181356,??????? 180,?????? 1200, "DS", 3, 5, 1157955648,??????? 0, "0", " (sAMAccountName=user_2010)", "idx_sAMAccountName:1:N;", "1", "1", "0, 0

DsDirSearch,????? Start, 0x000001EC,?? 129103742780337608,??????? 180,?????? 1200, "DS", 3, 3, 1141178432,??????? 0, "NTDSAPI", "deep", "DC=exchange,DC=local", "0, 0
DsDirSearch,??????? End, 0x000001EC,?? 129103742780337608,??????? 180,?????? 1200, "DS", 3, 5, 1157955648,??????? 0, "0", " (sAMAccountName=user_2010)", "idx_sAMAccountName:1:N;", "1", "1", "0, 0

DsDirSearch,????? Start, 0x00000A40,?? 129103742780493860,???????? 15,??????? 105, "DS", 3, 3, 1141178432, 1075970048, "10.2.0.2", "deep", "DC=exchange,DC=local", "0, 0
DsDirSearch,??????? End, 0x00000A40,?? 129103742780493860,???????? 15,??????? 105, "DS", 3, 5, 1157955648, 1075970048, "0", " (distinguishedName=DC=exchange,DC=local)", "idx_distinguishedName:1:N;", "1", "1", "・0, 0

DsDirSearch,????? Start, 0x000003F4,?? 129103742780650112,??????? 510,?????? 5895, "DS", 3, 3, 1141178432, 1612840960, "10.2.0.2", "base", "CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=exchange,DC=local0, 0
DsDirSearch,??????? End, 0x000003F4,?? 129103742780650112,??????? 510,?????? 5895, "DS", 3, 5, 1157955648, 1612840960, "0", "[]", "[]", "1", "1", "0, 0

DsDirSearch,????? Start, 0x00000A40,?? 129103742780806364,???????? 15,??????? 105, "DS", 3, 3, 1141178432, 1075970048, "10.2.0.2", "deep", "cn=policies,cn=system,DC=exchange,DC=local", "0, 0
DsDirSearch,??????? End, 0x00000A40,?? 129103742780806364,???????? 15,??????? 105, "DS", 3, 5, 1157955648, 1075970048, "0", " (distinguishedName=CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=exchange,DC=local) 0, 0

Start と End で1 ブロックのようです。Start と End は同一の TID となるようですね。
ログインに使用したユーザー名の情報が出力されています。
また、IP アドレスが記載されているものもありますね。

試しに [0x00000A40] の情報を使って AD に問い合わせをしてみたいと思います。
問い合わせには、[dsquery] コマンドを使用します。

dsquery * -filter " (distinguishedName=CN={31B2F340-016D-11D2-945F-C04FB984F9},CN=Policies,
CN=System,DC=exchange,DC=local) " -attr *

objectClass: top
objectClass: container
objectClass: groupPolicyContainer
cn: {31B2F340-016D-11D2-945F-00C04FB984F9}
distinguishedName: CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=exchange,DC=local
instanceType: 4
whenCreated: 01/17/2010 11:06:20
whenChanged: 02/11/2010 11:53:57
displayName: Default Domain Policy
uSNCreated: 17776
uSNChanged: 17776
showInAdvancedViewOnly: TRUE
name: {31B2F340-016D-11D2-945F-00C04FB984F9}
objectGUID: {37E0FE6E-DFA9-47FE-8BCA-E5AC7FFA57FA}
flags: 0
versionNumber: 65539
systemFlags: -1946157056
objectCategory: CN=Group-Policy-Container,CN=Schema,CN=Configuration,DC=exchange,DC=local
isCriticalSystemObject: TRUE
gPCFunctionalityVersion: 2
gPCFileSysPath: exchange.localsysvolexchange.localPolicies{31B2F340-016D-11D2-945F-00C04FB984F9}
gPCMachineExtensionNames: [{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{53D6AB1B-2488-11D1-A28C-00C04FB94F17}][{827D319E-6EAC-11D2-A4EA-00C04F79F83A}{803E14A0-B4FB-11
D0-A0D0-00A0C90F574B}][{B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A}{53D6AB1B-2488-11D1-A28C-00C04FB94F17}]
gPCUserExtensionNames: [{3060E8D0-7020-11D2-842D-00C04FA372D4}{3060E8CE-7020-11D2-842D-00C04FA372D4}]
ADsPath: LDAP://EXCHANGE-AD-02.exchange.local/CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=exchange,DC=local

この情報はグループポリシーのために発行したクエリのようですね。

トレースは、dsquery の LDAP フィルタの式のサンプルとしても利用することが可能です。
クライアント PC 起動時に AD 側でトレースを取得しているとコンピュータアカウントで発行されたクエリが取得できます。

次回は Windows Server 2008 で同様の作業を実施してみます。
こちらは、クライアント PC 起動時の情報を取得するシナリオを実施したいと思います。

Written by Masayuki.Ozawa

2月 11th, 2010 at 3:50 pm

Posted in Active Directory

2008 R2 Active Directory に移行 ? AD DS の降格 –

leave a comment

一通り、AD の移行が終わりましたので、今まで使用していた 2008 AD DS を撤去したいと思います。

[AD の降格]

AD の撤去は [dcpromo] から実施します。
AD CS 等、AD 関連の役割がインストールされている場合は事前に役割から削除しておく必要があります。

  1. [ファイル名を指定して実行] から [dcpromo] を実行します。
    image
  2. [次へ] をクリックします。
    image
  3. [OK] をクリックします。
    image
  4. [次へ] をクリックします。
    image
  5. [このサーバーを指している DNS 委任を削除する] のチェックをはずして、[次へ] をクリックします。
    image
  6. パスワードを設定して、[次へ] をクリックします。
    image
  7. [次へ] をクリックします。
    image
  8. [完了時に再起動する] を有効にして、削除が終わるまで待ちます。
    image

以上で既存ドメインコントローラーの降格は終了です。

この状態で Exchange Server 2010 RC に影響が出ないか確認をしてみたところ、以下のエラーが発生しました。
image

ひとまず、構成ドメイン コントローラーを変更してみました。

image
image

メールボックスの一覧等は表示できるようになったのですが、エラーが出る状況は変わらず。
どこかにドメインコントローラーの情報が残ってしまっているようです。

Exchange 2007 では正常に認識ができているのですが、2010 では NG です…。
仕方ないので、Exchange 2010 を再インストールしみたのですが状態は変わらず。

アンインストールしようとしたところいろいろと問題が発生して、以下の情報を参考にする必要がありました。
# メールボックスの削除とパブリックフォルダの削除がうまくできませんでした。

Exchange 2007 をコンピュータから削除する方法
Exchange 2010 – What is an arbitration mailbox?
Uninstall Exchange 2010

Exchange 2010 の RTM ももうじき TechNet からダウンロードできるようになると思いますので、
ダウロードできるようになったら RTM でも同様の現象が発生するのか試してみたいと思います。

Written by Masayuki.Ozawa

11月 1st, 2009 at 1:22 pm

Posted in Active Directory

2008 R2 Active Directory に移行 ? AD DS / DNS の移行 –

leave a comment

検証環境のインフラ整備をそろそろしないといけないと思い、まずは AD の移行から着手してみました。
私の検証環境の AD は 2008 SP2 で構築してあるのですが、これを 2008 R2 に移行してみます。

ワークグループ環境の DNS として設定しているものもあるため、移行の方針としては

  1. コンピュータ名は新規のもの
  2. IP アドレスは最終的に現行の AD のアドレスに変更

で作業したいと思います。

[フォレストとドメインの準備]

2008 R2 を 2008 ドメインのドメインコントローラーとして追加するために、フォレストとドメインの準備をします。
下の画像は、フォレストの準備をする前 / 後 スキーマのバージョンになります。
# 左がコマンド実行前、右がコマンド実行後です。
[objectVersion] が [44] から [47] に変更されています。
image?image

  1. 2008 のドメインコントローラーに Windows Server 2008 R2 のインストールメディアを挿入します。
  2. 以下のコマンドを実行します。
    RODCPREP は以前実行していたか覚えていなかったので改めて実行しています。

    >DVD ドライブ
    >cd supportadprep
    >adprep.exe /forestprep
    >adprep.exe /domainprep /gpprep
    > adprep.exe /rodcprep

    実行例)
    >D:
    >cd supportadrep
    >adprep.exe /forestprep

    ADPREP の警告:

    adprep を実行する前に、フォレスト内のすべての Windows 2000 Active Directory ドメイン コントローラーを Windows 2000 Service Pack 4 (SP4) 以降にアップグレードする必要があります。

    [ユーザーによる操作]
    既存の Windows 2000 Active Directory ドメイン コントローラーのすべてがこの要件を満たす場合は、C キーを押してから Enter キーを押して続行してください。中止するには、その他のキーを押してから Enter キーを押してください。

    c

    xxxxxx への接続を開始しました
    SSPI 結合に成功しました
    現在のスキーマのバージョン 44
    スキーマをバージョン 47 にアップグレードしています
    ファイルの署名を検証しています
    "xxxxxx" に接続しています
    SSPI を使って現在のユーザーとしてログインしています
    ファイル "C:Windowssystem32sch45.ldf" からディレクトリをインポートしています
    エントリを読み込んでいます…………………………………………………………
    66 個のエントリを正しく修正しました。

    コマンドが正しく完了しました
    ファイルの署名を検証しています
    "xxxxxxx" に接続しています
    SSPI を使って現在のユーザーとしてログインしています
    ファイル "C:Windowssystem32sch46.ldf" からディレクトリをインポートしています
    エントリを読み込んでいます….
    3 個のエントリを正しく修正しました。

    コマンドが正しく完了しました
    ファイルの署名を検証しています
    "xxxxxx" に接続しています
    SSPI を使って現在のユーザーとしてログインしています
    ファイル "C:Windowssystem32sch47.ldf" からディレクトリをインポートしています
    エントリを読み込んでいます…..
    4 個のエントリを正しく修正しました。

    コマンドが正しく完了しました
    "xxxxxx" に接続しています
    SSPI を使って現在のユーザーとしてログインしています
    ファイル "C:Windowssystem32PAS.ldf" からディレクトリをインポートしています
    エントリを読み込んでいます…………..
    13 個のエントリを正しく修正しました。

    コマンドが正しく完了しました
    …………………………………………………………………….
    Adprep はフォレスト全体の情報を正しく更新しました。

    >adprep.exe /domainprep /gpprep

    Domainprep を実行中…

    Adprep はドメイン全体の情報を正しく更新しました。

    更新が必要なグループ ポリシー オブジェクト (GPO) はありません。または、GPO 情報は既に更新されています。
    [状態/結果]
    Adprep はこの操作を再試行しませんでした。

    >adprep.exe /rodcprep

    Adprep はドメイン FSMO に接続しました: xxxxxx。

    Adprep は、パーティション DC=ForestDnsZones,DC=xxxxxx,DC=xxxxxに対して操作が実行されたことを検出しました。スキップして、次のパーティションに進みます。
    ===========================================================

    Adprep は、パーティション DC=DomainDnsZones,DC=xxxxxx,DC=xxxxxx に対して操作が実行されたことを検出しました。スキップして、次のパーティションに進みます。
    ===========================================================

    ===========================================================
    Adprep はパーティション DC=xxxx,DC=xxxx を検出しました。アクセス許可を更新しようとしています。

    Adprep はインフラストラクチャ FSMO に接続しました: xxxxxx。

    パーティション DC=xxxxx,DC=xxxxxx に対する操作は成功しました。
    ======================================================

    Adprep は問題なく完了しました。すべてのパーティションが更新されました。詳細については、C:Windowsdebugadpreplogs20091031130646 ディレクトリの ADPrep.log を確認してください。

[固定 IP と DNS の設定]

まずは、追加のドメインコントローラとして設定するために、既存の AD を参照先 DNS として設定して、
固定 IP を割り当てます。

最終的に、現行の AD の IP アドレスに変更するつもりですので、設定している IP は仮の IP になりますね。

image

では次に追加のドメインコントローラーとして設定します。

[ドメインコントローラーの追加]

  1. [ファイル名を指定して実行] から [dcpromo] を実行します。
    image
    サーバーマネージャで事前に、役割を追加していなくても dcpromo 実行時に自動でインストールをしてくれます。
    image
  2. [詳細モード インストールを使用する] を有効にして、[次へ] をクリックします。
    詳細モードは必ず有効にする必要があるわけではないですが、設定を確認したかったので今回は有効にしています。
    image
  3. [次へ] をクリックします。
    image
  4. [既存のフォレスト] [既存のドメインにドメイン コントローラーを追加する] を選択し、[次へ] をクリックします。
    image
  5. ドメイン名と追加のドメインコントローラーに設定するために使用するドメインアカウントの情報を入力し、
    [次へ] をクリックします。
    今回はワークグループの状態からドメインコントローラーとして追加しています。
    image
  6. 追加するドメインを選択し、[次へ] をクリックします。
    image
  7. 追加するサイトを選択して [次へ] をクリックします。
    image
  8. DNS と GC はデフォルトで有効になっているようです。
    今回は置き換えを目的としているので両方必要となります。
    デフォルト状態で [次へ] をクリックします。
    image
  9. [はい] をクリックします。
    image
  10. [次へ] をクリックします。
    image
  11. [次へ] をクリックします。
    image
  12. [次へ] をクリックします。
    image
  13. ディレクトリ復元モードのパスワードを設定し、[次へ] をクリックします。
    image
  14. [次へ] をクリックします。
    image
  15. [完了時に再起動する] を有効にしてインストールが完了するまで待ちます。
    image

これでドメインコントローラーと DNS の追加が完了しました。

[FSMO の移行]

追加したドメインコントローラーに FSMO を移行します。
作業は追加したドメインコントローラー上で実行しています。

  1. ドメイン名前付けマスターの移行
    1. [Active Directory ドメインと信頼関係] を実行します。
      image
    2. [Active Directory ドメインと信頼関係] を右クリックして、[Active Directory ドメイン コントローラーの変更] を
      クリックします。
      image
    3. 追加したドメインコントローラーを選択します。
      image
    4. 再度右クリックして、[操作マスター] をクリックします。
    5. [変更] をクリックします。
      image
    6. [はい] をクリックします。
      image
    7. [OK] をクリックします。
      image
    8. [閉じる] をクリックします。
  2. RID / PDC / インフラストラクチャマスターの移行
    1. [Active Directory ユーザーとコンピューター] を実行します。
      image
    2. ドメイン名を右クリックして、[操作マスター] をクリックします。
      image
    3. [RID] タブを選択して、[変更] をクリックします。
      image
    4. [はい] をクリックします。
      image
    5. [OK] をクリックします。
      image
    6. [PDC] タブを選択して、[変更] をクリックします。
      image
    7. [はい] をクリックします。
    8. [OK] をクリックします。
    9. [インフラストラクチャ] を選択して、[変更] をクリックします。
      image
    10. [はい] をクリックします。
    11. [OK] をクリックします。
  3. スキーママスタの移行
    1. [ファイル名を指定して実行] で [regsvr32 schmmgmt.dll] を実行して、[OK] をクリックします。
      image
    2. [mmc] を実行します。
    3. [ファイル] → [スナップインの追加と削除] をクリックします。
      image
    4. [Active Directory スキーマ] を選択して、[追加] をクリックし、[OK] をクリックします。
      ?image
    5. 右クリックして、 [Active Directory ドメイン コントローラーの変更] をクリックします。
      image
    6. 追加したドメインコントローラーを選択して、[OK] をクリックします。
      image
    7. [OK] をクリックします。
    8. [Active Directory スキーマ] を展開してから右クリックして、[操作マスター] をクリックします。
      image
    9. [変更] をクリックします。
      image
    10. [はい] をクリックします。
    11. [OK] をクリックします。
    12. [閉じる] をクリックします。

以上で FSMO の移行は完了です。

[IP アドレスの変更]

最初の AD の IP を変更して、追加した AD に割り当てられるようにしてみました。

  1. 現行の AD の IP アドレスを変更します。
  2. 現行の AD の 参照先 DNS を上で設定した IP に変更します。
  3. 代替 DNS に変更前の IP を設定します。
    # このあと、追加した AD に変更前の IP を設定するため。
  4. コマンドプロンプトで [ipconfig /registerdns] を実行します。

続いて追加した AD の IP を変更します。

  1. 追加した AD の IP アドレスを、現行の AD の IP アドレスに変更します。
  2. 追加
    した AD の参照先 DNS を上で設定した IP に変更します。

  3. 代替 DNS に現行の AD の IP を設定します。
  4. コマンドプロンプトで [ipconfig /registerdns] を実行します。

再起動後も AD DS のサービスは正常に動いているので、ひとまず変更は完了のようです。

Written by Masayuki.Ozawa

10月 31st, 2009 at 8:49 am

Posted in Active Directory

Windows NT 4.0 DC を 2000 AD にアップグレードする際の DNS サフィックスの注意点

leave a comment

あまり需要があるネタではないかもしれませんがメモとして。
# なにせ NT ネタですので…。

NT のドメインコントローラーを AD にアップグレードする前に [TCP/IP] のプロパティで、DNS のサフィックスを
設定している場合の注意点です。

NT の状態で、ドメイン名として [DOMAIN]、DNS のサフィックスとして [test.net] を設定しています。
image image

この状態で NT を Windows 2000 Server へアップグレードします。

image image

NT ドメインコントローラーをアップグレードすると自動的に Active Directory のインストール ウィザードが起動します。

image

ドメイン名は [domain.local] として設定してみます。

image

AD のインストール後のコンピュータ名が以下の画像になります。

image

通常、ドメインコントローラーのフルコンピュータ名のサフィックスには、ドメイン名が使用されるのですが、
NT の段階で DNS のサフィックスを指定しているとその設定が引き継がれます。
メンバサーバーであれば変更することができるのですが、画像を見てもらえると分かりますように、
ドメインコントローラーの場合は、ボタンがグレーアウトして変更することができません。

サフィックスは DNS の登録されるゾーンにも影響が出ますので、新規にゾーンを作成しないと AD の挙動にも
影響が出る可能性があります。

DNS サフィックスの変更方法は以下の KB に記載されています。

ドメイン コントローラの DNS サフィックスがドメイン名と一致しない

レジストリエディタで以下のレジストリを変更します。

[HKLMSYSTEMCurrentControlSetServicesTcpipParametersNV Domain]

image?image

上記の画像では [test.net] から [domain.local] に値を変更しています。
変更後、再起動をすると設定が反映されます。

image

?

NT → 2003 R2 へのアップグレードではどうなるか試してみました。

image image

Windows Server 2003 R2 のインストールが終了すると、Active Directory のインストール ウィザードが開始されます。
image

ここで、[新しいドメインの完全な DNS 名] を [domain.local] として設定します。
image

2003 R2 の場合は、ドメイン名が使われるようですね。

image

ブログの下書きにずっと入っていた内容をようやく投稿できました。

Written by Masayuki.Ozawa

10月 11th, 2009 at 10:23 am

Posted in Active Directory

コンピュータアカウントのパスワード、変更されたのは何時?

leave a comment

クライアントのコンピュータアカウントのパスワード格納場所

の続きとして投稿しようと思っていたのですが本日まで手付かずでした。
記憶も薄れつつあるのでここでまとめておきたいと思います。

以前の投稿で記載しましたがコンピュータアカウントのパスワードは

– [HKEY_LOCAL_MACHINESECURITYPolicySecrets$MACHINE.ACC]

に格納されているようです。

この中には [CupdTime] / [OupdTime] という 2 種類のキーがあり、この値に変更された日付が入っていそうです。
# 具体的なドキュメントは見つかっていないので [ここかな~] というレベルです。違っているかも・・・。

image

上記の画像が、キーの値を表示したものになります。

4a 30 31 af 44 30 ca 01

という値が入っていますがこのままでは何のことやらさっぱりです。

この値を日付に変換するためには [nltest.exe] を使用します。
[nltest.exe] は Windows 2000 Server / Windows Server 2003 のサポートツールに含まれています。

Windows 2000 SP4 サポート ツール
Windows Server 2003 Service Pack 2 32-bit Support Tools

Windows 7 / Windows Server 2008 R2 では標準で含まれていそうです。

このコマンドとレジストリの値を使用すると日付に変換することができます。
以下がコマンドの実行結果です。

nltest /time:af31304a 01ca3044
af31304a 01ca3044 = 9/8/2009 14:24:48
コマンドは正常に完了しました

レジストリに設定されている値を以下の順で変換します。

  1. 値を 8 桁 + 8 桁にします。
    4a 30 31 af 44 30 ca 01
  2. 値を 2 桁一組として逆から並べ替えます
    af31304a 01ca3044

この値を使用して nltest を実行すると日付が取得できます。
# 最初のブロックと最後のブロックの間には半角スペースを入れます。
今回の値だと [2009/9/8 14:24:48] になりますね。

このタイミングでドメインに参加をさせていますので、コンピュータアカウントのパスワード変更日付の
設定値としては有効かなと思います。

ADSI エディットを使用して、コンピュータアカウントの [pwdLastSet] を確認すると以下の値が設定されています。

[2009/9/8 14:24:49]

image

コンピュータのレジストリの値とほぼ同一の時刻が設定されています。

上記画像は Windows Server 2008 の ADSI エディットで表示したものですが、残念ながら 2008 より前の
ADSI エディットでは日付で表示されません。
下の画像は Windows 2000 Server の ADSI エディットを使用して [pwdLastSet] を取得したものです。

image

[128968610899088750]

このままだと何の値かわからないですよね・・・。
これも日付に変換することが可能です。

  1. 16 進数に変換できる電卓を実行します。
    # 2008 までは関数電卓 / R2, 7 ではプログラマ電卓で変換できます。
    ?image
  2. 10 進数の状態で、[pwdLastSet] の値を貼り付けます。
    image
  3. 16 進数に変換します。
    image?

    そうすると

    1CA3044AFD0D56E

    という値に変換ができます。これを [nltest.exe] で実行できる形式に変換します。

  4. 最初に [0] をつけます。
    01CA3044AFD0D56E
  5. 8 桁 + 8 桁に分割します。
    01CA3044 AFD0D56E
  6. 最初のブロックと最後のブロックを入れ替えます。
    AFD0D56E 01CA3044

これで値の変換は完了です。
変換した値を使用して [nltest.exe] を実行してみます。

nltest /time:AFD0D56E 01CA3044
afd0d56e 01ca3044 = 9/8/2009 14:24:49
コマンドは正常に完了しました

< p>2008 の ADSI エディットと同じ値が取得できました。

Mechanics of User Identification and Authenication: Fundamentals of Identity Management

という書籍にこの辺の内容が書かれていそうなのですが英語なのとお値段がそれなりにするので買えていません・・・。
面白そうな本なのでどこかで読んでみたいとは思っているのですが。

AD 関連では備忘録としていくつか残しておきたいことがあるので時間を見て少しずつ投稿していきたいと思います。

Written by Masayuki.Ozawa

9月 15th, 2009 at 1:59 pm

Posted in Active Directory

クライアントのコンピュータアカウントのパスワード格納場所

leave a comment

Active Directory とは依然として仲良しにはなれていないのですが、そうも言っていられない日々が続いています…。

今日はコンピュータアカウントのパスワードについて。

コンピュータアカウントのパスワードはセキュリティポリシーの
– [ドメイン メンバー: 最大コンピュータ アカウントのパスワード有効期間]
の設定値で定期的に変更され、ドメイン コントローラーでも保持しているパスワードと一致しない場合は、
セキュアチャネルの確立ができず、ドメイン ログオンに失敗する仕組みになっています。

image

パスワードは 1 世代前のものも保持されており、現在のパスワードと 1 世代前のパスワードの両方を使用して
セキュアチャネルが確立できないと NG になります。

Netdom.exe を使用して Windows 2000 ドメイン コントローラのコンピュータ アカウントのパスワードをリセットする方法

セキュアチャネルについては Microsoft の Network & AD サポートチームの以下の記事がとても参考になります。

ドメインにログオンできない ~ セキュア チャネルの破損 ~

パスワードを無期限にする方法に関しては Microsoft エバンジェリスト 安納さんがまとめてくださっています。

【Hyper-V】スナップショットとコンピュータアカウントパスワードの微妙な関係

ちなみに、パスワード不整合が起きたかどうかはドメイン コントローラで対象のコンピュータアカウントの
– [badPwdCount]
– [badPasswordTime]
を見るとわかります。
ドメインコントローラーのイベントビューアでイベント ID [5722] で見る方法も。

ドメインコントローラー側は Active Directory 上にパスワードを持っているとして、クライアント側の場合は
どこにパスワードを持っているのかというと [LSA (ローカル セキュリティ 機関)] に格納されています。

LSA の内容は以下のレジストリで内容を見ることができます。

– [HKEY_LOCAL_MACHINESECURITY]
image

デフォルトの状態ではこのレジストリには [SYSTEM] しか読み取りの権限がありませんので他のユーザーで内容を確認したい場合は、
[SECURITY] を右クリックして [アクセス許可] を選択し、読み取り権限を明示的に付与する必要があります。

  1. [アクセス許可] を選択
    image
  2. 操作しているユーザーに [読み取り] を追加
    image

Windows 2000 の場合は [regedit.exe] からはアクセス許可の設定ができないため、[regedt32.exe] を使用します。

アクセス許可を設定すると [SECURITY] が展開できるようになります。

image?

コンピュータアカウントの情報は以下の場所に格納されています。
– [HKEY_LOCAL_MACHINESECURITYPolicySecret.s$MACHINE.ACC]
image?
このレジストリキーを展開すると以下の階層が表示されます。
image

[CurVal] [OldVal] がコンピュータアカウントのパスワードの値になるようです。
# [CupdTime] [OupdTime] がそれぞれの値の変更されたタイミングになります。
 ただし、世代移動のタイミングで両方の値が更新されるようで、変更されたタイミングは同じ値が入っていました。

意図的にコンピュータアカウントのパスワード不整合を発生させたい場合は、[CurVal] [OldVal] を書き換えると現象を発生させることが可能です。
あまりにも変な値を入力するとログオンできないだけでなく、ドメインからはずせなくなりますのでご利用は計画的に。

次回は意図的にパスワード不整合を発生させ、ログオンできない状態にさせてみたいと思います。

Written by Masayuki.Ozawa

7月 2nd, 2009 at 11:08 pm

Posted in Active Directory

repadmin /syncall で別サイトの DC と同期

leave a comment

WIndows 2000 / 2003 のサポートツールに含まれている repadmin.exe を使用すると DC のレプリケートを
コマンドラインで実行することができます。

オプションを何も設定しないで実行すると同一サイト内の DC とのみレプリケートが実行されますので、
複数のサイトを作成している場合は /e オプションを指定する必要があります。

[自サイト内の DC とのみレプリケート]

repadmin /syncall

?

[他のサイトの DC も含めてレプリケート]

repadmin /syncall /e

?

[Active Directory サイトとサービス] を使用して [今すぐレプリケート] で同期をとる場合は
対象の接続オブジェクトを選択するので別サイトでも問題はありませんが、コマンドで実行する場合は
気をつけないといけないですね。

Written by Masayuki.Ozawa

6月 29th, 2009 at 11:36 pm

Posted in Active Directory

ダウンレベルクライアントに影響するグループポリシー

leave a comment

Windows Server 2003 のドメインコントローラーを使用している場合にダウレベルクライアントで
影響が出そうなグループポリシーをメモ
# グループポリシーに KB823659 へのリンクが表示されていたものです。

グループポリシー 設定値
Microsoft ネットワーク クライアント: 常に通信にデジタル署名を行う
  • 有効
  • 無効
Microsoft ネットワーク サーバー: 常に通信にデジタル署名を行う
  • 有効
  • 無効
ドメイン メンバ: 強力な (Windows 2000 かそれ以降のバージョン) セッション キーを必要とする
  • 有効
  • 無効
ドメイン メンバ: 常にセキュリティで保護されたチャネルのデータをデジタル的に暗号化または署名する
  • 有効
  • 無効
ネットワーク アクセス: SAM アカウントおよび共有の匿名の列挙を許可しない
  • 有効
  • 無効
ネットワーク アクセス: SAM アカウントの匿名の列挙を許可しない
  • 有効
  • 無効
ネットワーク アクセス: 匿名の SID と名前の変換を許可する
  • 有効
  • 無効
ネットワーク セキュリティ: LAN Manager 認証レベル
  • LM と NTLM 応答を送信する
  • LM と NTLM を送信する – ネゴシエーションの場合、NTLMv2 セッション セキュリティ
  • NTLM 応答のみ送信する
  • NTLMv2 応答のみ送信する
  • NTLMv2 応答のみ送信する (LM を拒否する)
  • NTLMv2 応答のみ送信する (LM と NTLM を拒否する)
ネットワーク セキュリティ: 必須の署名をしている LDAP クライアント
  • なし
  • ネゴシエーション署名
  • 必須署名
監査: セキュリティ監査のログを記録できない場合は直ちにシステムをシャットダウンする
  • 有効
  • 無効

セキュリティ的に問題ないかは別にして、これらの設定をドメインコントローラにしておけば、
95 / 98 / NT 4.0 SP3 以前がログインできないという現象は回避できそうです。

ダウンレベルクライアントがなくなったら設定を戻しましょうという但し書きをしたうえで設定しておこう。

Written by Masayuki.Ozawa

6月 23rd, 2009 at 11:25 am

Posted in Active Directory

CNAME を使用したファイル共有

leave a comment

Windows のファイルサーバーではないのですが DNS の Ailias (CNAME) で CIFS 共有にアクセスすると
認証が発生してしまうという社内の問い合わせがあったので少し調べてみました。

とりあえず Windows のファイルサーバーだとどうなるんだろうと思い調べてみたところ、事例がありました。

Windows 2000 ベースのサーバー上の SMB 共有へのエイリアス名による接続が機能しない
Windows2000/Server2003の共有フォルダをDNSのCNAMEレコードを使用して開けない
Windows Server 2003 Service Pack 1 のインストール後に FQDN または CNAME エイリアスを使用してサーバーにローカル アクセスしようとするとエラー メッセージ "アクセスが拒否されました" または "指定されたネットワーク パスはどのネットワーク プロバイダによっても受け付けられませんでした" が表示される
ログオン ウィンドウの表示 Windows Server 2003 Service Pack 1 NLB 仮想 NLB クラスタ名を参照するとき

以下のレジストリを設定すれば CNAME でアクセスできるようになります。

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesLanmanServerParameters

値の名前 : DisableStrictNameChecking
データの種類 : REG_DWORD
基数 : 10進
値 : 1

エラーの時は以下のようなメッセージが表示されます。

ネットワークに重複した名前があるため接続されませんでした。
コントロール パネルのシステムでコンピュータ名を変更して再実行してください。

image

CNAME だけでなく、A レコードで本来のコンピュータ名の IP を登録しても同様のエラーとなりました。

NLB で Kerberos 認証をする場合もいろいろと考慮点があるみたいですね。
# NLB の仮想ホスト名も CNAME みたいなものだと思いますので。

Windows Server 2003 NLB構成で Kerberos認証を有効にする
負荷分散アーキテクチャで Kerberos 経由の認証の委任は動作しません
Kerberos authentication for load balanced web sites
Enabling Kerberos Delegation on a NLB scenario

こちらはアプリケーションプールをドメインユーザーで起動して、 NLB で負荷分散に使用するホスト名と
アプリケーションプールの起動ユーザーで SPN を登録するのがポイントみたいです。

SQL Server の Kerberos 認証もそのうち試そうと思ってなかなか手が出せていないですね~。
まだまだ勉強することが沢山です。

Written by Masayuki.Ozawa

6月 22nd, 2009 at 2:17 pm

Posted in Active Directory