SAMBA 3からActiveDirectoryへのドメイン移行（ダウンタイムのないドメイン移行エクスペリエンス）

TerAnYuは最近の記事で、 SambaからActive Directoryにドメインを移行する方法を説明しました 。 私の意見では、この方法は非常に興味深いものが選択されましたが、残念なことに、小さなドメインを移行するとき（著者は記事の本文で約70人のオフィスユーザーに言及しています）、多くの興味深い問題が舞台裏に残っています。

次に、ユーザースクリプトのダンプ/復元を無視し、発生した問題の説明と解決に集中します。 おそらく、説明した経験は、誰かが移行の準備に関わる労力を軽減するのに役立つでしょう。



そして、もちろん、私はcでした-それは簡単ですが、最も最小限です。

Sambaを放棄した理由

Sambaに関するその他の質問をすべて警告するために、私は答えます。

最初は、Sambaドメインのアーキテクチャ（開発者ではなく、インストールによって私たちが行ったもの）には、ドメインのスケーリング時に現れる誤算がいくつかありました。 長所と短所を考慮して、ドメインの完全な再構築が必要になったとき、管理者はSambaを再編成する代わりにActive Directoryに移行することを決定しました。

さらに、この質問は終了したと考えます。

コンセプト

移行の概念について簡単に説明します。

1. ドメインを使用するすべてのサービスのリストがコンパイルされます（承認のため、または他の情報のリポジトリとして）
2. これらのサービスがActive Directoryと連携するための新しい構成セットが準備されています。
3. Sambaソースドメインデータはダンプに保存されます。
4. 新しいドメインの最初のコントローラーはWindows 2003サーバー上で準備されています（移行後、新しいOSを使用してコントローラーにドメインを簡単に移行できますが、次の手順は2003rdサーバーでのみ機能します）。 新しいサーバーは、newsidユーティリティを使用してSambaのドメインのSIDを設定します（役割が増えると、このSIDはActive DirectoryドメインのSIDになります）
5. 構成されたDNS。
6. セキュリティオブジェクト（ユーザー/グループ/コンピューター）は、RIDの昇順で作成されたドメインで開始されます。 単一のDCを持つドメインでは、RIDは厳密に順番に割り当てられます（多数のテストインポートの実行に対して、反対のことを証明する単一のケースはありませんでした）
7. ユーザーのパスワードは、古いドメインから新しいドメインに同期されます。
8. ワークステーションとサーバーは新しいドメインに転送されています。
9. ドメインを使用するサービスでは、構成は事前準備およびテスト済みに変更されます。

次に、各ステップを順番に検討します。

ドメインを使用しているサービスのリスト。

このリストは、どこかに移行するかどうかにすべて依存する必要があります。 ドメインの使用者と使用方法を知ることは常に重要です。 リストには次に関する情報が含まれている必要があります。

1. サービスが実行されているホスト。
2. ドメインに接続するときに使用されるプロトコルと認証方法について。
3. ドメインでサービスが許可される資格情報について。
4. LDAPに保存されるサービスデータの形式について（サービスがデータをLDAPに保存する場合）

サービスを再構成するときにこのリストが必要になります。

新しい構成キット

これらは必須であり、事前に準備する必要があります（ビジネスをアイドル状態にしたくない！）。

何が変わるのでしょうか？ 移動後も、必要な多数のLinuxシステムが残っていることは論理的です

新しいドメインに統合されます（これらのシステムのほとんどを取り除くつもりはないでしょう）

1. サービスは、LDAPに保存されているハッシュを使用してハッシュをチェックすることにより、ユーザーのパスワードを検証できなくなります。LDAPからハッシュを受信しなくなります。 LDAPバインドを使用してパスワードを確認するには、すべてをやり直す必要があります（Kerberosで動作しないサービスを意味します）。 できる限り認証にケルベロスを使用することを強くお勧めします。これにより、ユーザーの作業が楽になり、ドメインコントローラーの負荷が軽減されます。
2. ドメインにネストされたグループがある場合があるため、グループ内のユーザーのメンバーシップを確認するときは、グループがネストされている可能性を考慮する必要があります。
3. サービスをkerberosの使用に移行するのは理にかなっています（これが以前に行われていない場合）。
4. LDAPに保存されているデータについては、他の属性を探すか、Active Directoryスキーマの拡張に取り組む必要があります（適切な形式になった最初の属性を使用することは強くお勧めしません-ソリューションが将来どうなるかを考えてみてください）。 Active Directoryの属性を設定することの利点は十分に文書化されています。文書の調査に時間を費やすのを怠らないようにしましょう。

Sambaドメインダンプ

ここから面白い瞬間が始まります。

SambaはSIDの一意性を制御しません。 したがって、大規模な分散ドメインでは、同じSIDを持つ複数のセキュリティオブジェクトを取得できます。 原則として、これは管理者エラーの結果であり、このエラーはすぐに修正する必要があります！ 同じSIDを持つ複数のセキュリティオブジェクトの存在は受け入れられません（ただし、残念ながら、Sambaドメインではこの現象に何度も遭遇しました）。

一般的な（インターネットのマニュアルに記載されている）Samba RIDのインストールは、1000から発行され始めます。残念ながら、上記の方法では、RIDが約1034未満のセキュリティオブジェクトを移行できません（私は告白します-正確な番号を忘れましたが、簡単に把握できます-きれいな新しいコントローラーを設置しますドメインと最新のRIDを参照してください）。 Active Directoryドメインを作成すると、多くのサービスセキュリティオブジェクトが作成され、これらの最初のRIDを「占有」します

説明されているこれら2つのケースでは、解決策は1つです。

結局、事前にSambaにドメインダンプをアップロードして分析しましたか？ Xはまだ遠いですか？ そのため、すべての競合状況をゆっくりと整理し、ビジネスのダウンタイムを最小限に抑えて修正する時間があります。

新しいドメインの最初のコントローラーを準備する

まず、ロールが増加する前に、サーバー上に無関係なローカルグループとユーザーがいないことを確認してください（そうしないと、最初に占有されるRIDの数が増加します）-これは、一般的なサーバーイメージを使用する場合に発生する可能性があります。

次に、newsidを取得する必要があります。 公式ウェブサイトでは削除されましたが、彼らが言うように、インターネット上にあるものは...

はい、既存のドメインの横に新しいドメインを準備できます（強くお勧めします）。古いNETBIOSドメイン名を保持するつもりはありませんか？！

DNSセットアップ

PCを新しいドメインに転送するとき（およびパスワードを同期するとき）、インフラストラクチャ内のコンピューターで両方のドメインの名前が正しく解決されることを確認する必要があります。 両方のドメインにサービスを提供するDNSサーバーで条件付き転送を構成することは理にかなっています。

新しいドメインでセキュリティオブジェクトを再作成します。

インポート時間

RIDでソートされたドメインダンプを用意しておくと便利です。

ダンプをインポートする手段の選択はあなた次第です。 最初はVBScriptでスクリプトをスケッチしましたが、最終的にはすべてをC＃で書き直さなければなりませんでした-そうでなければ、非常にゆっくりと判明しました（X時間前に、潜在的な問題を特定するために複数回テスト移行を行いました）。 私は約半日ですべてのデータをインポートしました（これにはいくつかのトリックがあります-それらについては後で詳しく説明します）。

ドメインが古く、ドメインが大きい場合、RIDプールが断片化される可能性が高くなります（RIDでソートされたドメインダンプに大きな欠落がある場合があります：ユーザー/グループ/コンピューターが起動されてから削除されました）-論理的な解決策は次のとおりです：

ユーザーを作成し、RIDを取得して、ユーザーを削除します。 RID-1がダンプの次のユーザーのRIDと等しい場合、ユーザーをダンプから開始します。そうでない場合は、RIDの「チート」サイクルを繰り返します。

決定は論理的ですが、 非常に破滅的なほど遅いです。

デフォルトのRIDプールサイズは500です。サーバーがRIDマスターからの新しいプールを要求することを強制する、素晴らしいinvalidateRidPoolメカニズムがあります。

invalidateRidPoolを使用すると、RIDを「スクロール」する時間を大幅に短縮でき、次の問題も緩和されました。

「ゴミ」のクリーニング

残念ながら、Active DirectoryでRIDを「ラップ」した後、多くの墓石が残っているため、ntds.ditは巨大なサイズを取り、リモートサイトへの複製は頭痛の種に見え始めます。 それらを取り除き、ntds.ditを促進する方法は？ 自然な方法でのみ。

tombstoneLifetimeは、Active Directoryのリモートオブジェクトの寿命を設定します（ごみ箱のオブジェクトと混同しないでください-これらは異なるものです）、設定できる最小値は2日間（デフォルト値は180日間）です。 2日以上経過した削除済みオブジェクトは、データベースから削除されます。 tombstoneLifetime = 2を設定して2日間待機した場合、最初の5000個のトゥームストーンのみが削除されます。 廃棄コレクションは、ガベージコレクションの手順の結果として削除されます。 この手順は12時間ごとに独立して開始され、一度に5000個以下のオブジェクトを削除します。 多数のトゥームストーンをクリアするには、ガベージコレクションを数回実行する必要があります。 起動間隔を短くするか、プロシージャを強制的に呼び出します。

その後、 必ず tombstoneLifetimeの値を返し、オフラインでの最適化を実行してくださいntds.dit

古いドメインのユーザーパスワードを新しいドメインに同期します。

いくつかの「これを行う方法」オプションがあります。

• Sambaでは、独自のパスワード複雑度テストスクリプトを設定できます。 残念ながら、ユーザーログインはスクリプトに渡されませんが、簡単に修正できます（これはオープンソースです！）
• SambaはNTおよびLM（14文字より短いパスワード用）パスワードハッシュを保存します-状況が許せば、 ユーザーのパスワードを見つける機会があります。
• ユーザーにデフォルトのパスワードを設定し、「次回ログイン時にパスワードの変更を要求する」チェックボックスを設定できます（これを行わないことを強くお勧めします）
• すべてのユーザーをバイパスできます

一般に、あなたが選択します。 私は最初のオプションを好みます。

実際に移行。

前のすべての手順は、ドメインの動作に影響しませんでした。 それは、ビジネスの仕事を妨げることなく、何ヶ月も実行できる準備でした。 残りの2つの段階は、ビジネスと合意した非アクティブ期間内に実行する必要があります。 適切な準備と必要な数のハンドの可用性があれば、単純なハンドを実際に数晩に短縮できます（ドメインのサイズに応じて、最大数時間かかる場合があります）。

ここでは、どのサービスとどのユーザーが重要で、どのユーザーが使いやすいかを知ることが重要です。一般に、会社のビジネスプロセスを知る必要があります。

新しいドメインの設定を再度確認します：IPサブネット、サイト、ポリシー、PDCエミュレーターの外部ソースからの時刻同期のセットアップ。

両方のドメインのDNS名がワークステーションから正しく展開されていることを確認してください。

ワークステーションとサーバーの新しいドメインへの転送

OCがXP / 2003ドメインメンバー以上にある場合-特に問題はありません-JoinDomainOrWorkgroupを使用して、新しいドメインにすぐに簡単に転送できます。

2000年代では、中間の再起動を行う必要があります（domain-reload-enterからドメインに移動します）

ここでは、利用可能な集中管理システムを使用するか、独自のスクリプトを作成できます（非常に簡単になります）。 PCをドメインからドメインに移すには、ドメインとPC自体の両方で適切な特権を持つアカウントが必要であることを忘れないでください。

はい、DHCPサーバーのセットアップでDNSアドレスを新しいものに変更することを忘れないでください（MS DNSのAD統合ゾーンを使用する予定ですよね？）DHCPサーバー自体をすぐに移行することはできません（多くの機能が失われます）後でMicrosoftの製品に置き換えます。

ドメインを使用したサービスの構成の変更。

新しい構成ファイル（移行の手順）を準備し、レイアウトの新しい設定をテストしたので、問題はないはずです。

結果。

準備に多くの時間を費やし、セキュリティオブジェクトをインポートするのに約3〜4日間、SambaからActive Directoryに会社を1〜数晩で移すことができます。



そのような移行について別のビジョン/経験がある場合は、それを共有してください-あなたの行動を分析し、何がより良くできるかを見つけることは非常に興味深いです。

当然のことながら、一般的な問題と特殊性のみに触れました。同一の会社は2つも存在せず、どこにでもユニークな障害があります。