ActiveDirectory

もう2022年ですが、Windows 2000 Serverから登場したActive Directoryの入門動画をYoutubeにアップロードしました。 https://www.youtube.com/watch?v=lZ8Ps6U_kvY Windows 2000 Serverって2000年に出たわけですからもう20年以上前の技術ですね。それでも、今でも現役で非常に多くの企業で使われているわけですごいですよね。 もうActive Directoryに依存しない形態でクラウドオンリーで企業ユースでもバリバリに使えるサービス群がAzure Active Directoryを筆頭に多数出ているわけですが、まだまだ現役で使われ続けており、それを管理する人もこれから管理しなくてはいけない人も多くいますね。 そんなわけで、このタイミングでもまだ需要あるかなとおもって動画をサクッと撮ってみました。今回はキーワードを並べておいただけであとは全部その場のアドリブなので、話があまりまとまってなくてごめんなさいですが。 私が「Active Directoryに関して理解しておくべき項目」としてピックアップしたのは下記です。 構造フォレスト- ドメイン- コンテナ- OU- サイトサブネット- サイトリンク- DNSを利用ドメインツリー- Active Directory統合モード- SRVレコード- ディレクトリサービスユーザー, グループ, コンピューター等- LDAP- NTML認証 / Kerberos認証 / Cred SSP認証- グループポリシー- ドメイン参加ユーザープロファイル ADのデータベースドメインコントローラー- パーティション構成パーティション- スキーマパーティション- ドメインパーティション- グローバルカタログ- 複製ロジックマルチマスタ- ディレクトリ複製- Tombstone(破棄の有効期間属性)60日(2003)- 180日(2003 SP1以降)- スキーマ- FSMO(操作マスタ)スキーママスタ- ドメイン名前付けマスタ- RIDマスタ- PDCエミュレータ- インフラストラクチャマスタ- SYSVOL / FRS / D-FRS- 信頼関係- 災害対策ディレクトリサービス復元モード- 診断コマンド このくらいの項目に関してきちんと概念を把握できているときちんと全体像を把握して管理できるんじゃないかなと思います。ざっとでもいいのでわからない項目ありましたら、動画を覗いてみてやってください。(文章で書くのではなく動画に誘導するスタイル) https://www.youtube.com/watch?v=lZ8Ps6U_kvY

前回の記事「 Azure Portalにアクセスする際の動きをFiddlerで確認 – その１ クラウドIDを使った一番シンプルなパターン | Microsoft Cloud Administrators 」の続きです。 今度はクラウドIDが別AzureADテナントに招待されその別Azure ADテナントに紐付いているAzureサブスクリプションにアクセスする際の動きを確認してみます。 注意：このエントリの内容は「正確さ」に関しては保証しません。自分で実際に試してみて、挙動をみて、考えて、自分の既存の知識や経験、他のドキュメント等と照らし合わせた上で自分の現段階の考えを書いています。ご注意ください。 クラウドIDがテナントをまたいで招待されているパターン 今回は前回と同じwindowsadmin.onmicrosoft.comというAADに紐づくAzureサブスクリプションに対して別AzureADテナントwindowsadmin2.onmicrosoft.com上に存在するaccesstest2@windowsadmin2.onmicrosoft.comからアクセスをしたときの挙動を見てみます。 サブスクリプションは前回利用したものと同じです。紐付いているディレクトリはwindowsadmin.onmicrosoft.comです。 新規に別のAzure ADを作成しました。ディレクトリ名はwindowsadmin2.onmicrosoft.comです。 ユーザーとしてaccesstest2@windowsadmin2.onmicrosoft.comを作成しています。 accesstest2@windowsadmin2.onmicrosoft.comはwindowsadmin.onmicrosoft.comに招待してあります。 サブスクリプションへの権限も付与してあります。 実際の挙動 https://portal.azure.com/にアクセスします。 サインインを求められます。 アカウント名を入力します。 パスワードの入力を求められます。 サインインの状態を維持するかどうかを質問されます。 windowsadmin2.onmicrosoft.comディレクトリを利用してAzure管理ポータルにアクセスしました。サブスクリプションが該当ディレクトリには存在していないと表示されています。 ディレクトリをWindowsadmin.onmicrosoft.comに切り替えます。 Azure管理ポータルへのアクセスが完了しました。 Fiddlerに記録されたデータを含めた挙動 Fiddlerで動きを見ると、はじめの方の挙動は完全に同一になっています。その後、Azure管理ポータルにアクセスしたあとでAADテナントを明示した認証、認可が走っていることがわかります。 何度もAzure管理ポータル上でディレクトリの切り替えを行うと、そのたびにlogin.microsoftonline.comへのAADテナントを明示したアクセス(認証～トークン取得)が行われていることが確認できます。

今回はActive DirectoryとDNSについての話をしてみようと思います。Windowsネットワークを構築する上ではある程度の規模以上ではActive Directoryの構築、理解は事実上必須となり、Active Directoryを構築する上ではDNSの利用が必須になります。そしてDNS周りの設計が一番技術的に難易度が高く理解が難しいところです。ひとつずつ解説してみたいと思います。 Active DirectoryにはなぜDNSが必要なのか Active DirectoryにはDNSが必須です。DNSがないときちんと動きません。これはなぜかというと、端的には「DNSをつかってドメインコントローラーを探すから」ということになります。ただ、「DNSを使ってドメインコントローラーを探す」と言われてもピンと来ないかもしれません。イメージを持ってもらうために実際のDNSレコードを覗いてみましょう。 以下はad.localというシングルフォレストシングルドメイン環境に、dc01.test.local, dc02.test.localという2台のDCが存在している状況です。バージョンはWindows Server 2022ですが、Windows Server 2003以降であれば基本的に同じ構造になっているはずです。 _msdcs.ad.localというゾーンにdc01, dc02のGUIDがCNAMEで登録されています。 展開していくと、サイト名にひもづくようなレコードがありSRVレコードにdc01, dc02の値が見えます。 違う場所にも同じようなレコードがあります。 以下同様にまだまだたくさんあります。 pdcのところにはdc01だけしか無かったりします。これはPDCエミュレーターというFSMOの役割を持っているのは(この場合はdc01という)単一のサーバーだけだからです。 _msdcs.test.localゾーンではないtest.localゾーンにも同じようなレコードがあることが確認できます。 本筋からずれてしまうので、ここで個々のレコードの意味を説明することはしませんが、見てもらったようにDNSの中に一定のルールに従ってSRVレコードが作成されていることがわかります。クライアントはこれらのレコードを参照しながらActiveDirectory環境で動作します。そしてドメインコントローラー同士もDNSのレコードを参照してお互いに通信したりします。DNSがないとドメインに参加もできないし、ドメインにログオンもできないほどDNSはActiveDirectory内で大切なサービスです。 インターネットのDNSとActiveDirectoryのDNSの関係について ところでDNSと言えばまず思いつくのはActiveDirectory用のDNS…よりも先にインターネットで使われているDNSが思いつくと思います。世界中にある無数のホストの名前解決を行ってくれている階層、分散管理のシステムです。 Domain Name System - Wikipedia このDNSとActiveDirectoryで使われるDNSとは同じものなのか、違うものなのか?このあたりは中々複雑な状況があります。 ActiveDirectoryが登場する前からインターネットは存在し、そのなかでDNSは使われていました。- ActiveDirectoryは名前解決の仕組みとしてインターネットという大規模システムで使われてもうまく動作しているDNSという仕組みを採用しました。- マイクロソフト実装のDNS(以降MSDNSと書きます)をインターネット上のDNSとして構成することも(やれば)できます。- インターネット上のDNSとして多く使われているBINDをActiveDirectory用のDNSとして構成することも(やれば)できます。 ここまではまぁよいかと思います。MSも独自のDNS実装を作ったけれども、BINDであろうとMSDNSであろうとDNSはDNSなのでどのような用途にも構成すれば使えますよ、ということです。 難しくなってしまうのは以下のあたりの要素があるからです。 インターネット上のドメイン名と同じドメイン名(たとえばgoogle.comドメイン)をActiveDirectoryのドメイン名にすることができてしまいます。(ただし通常これはやらない方がいいです。)- インターネット上のDNSをそのままActiveDirectoryのドメイン名とし、インターネット上にすべて公開することができてしまいます。(ただし、これは絶対にやらない方がいいです。)- ActiveDirectoryのDNSはインターネットの世界とは完全に切り離して構成することが可能です。(これは推奨される構成です。)- ActiveDirectoryのDNSはインターネットの世界とは切り離して構成しつつ、それでもインターネット上のホストの名前解決をActiveDirectoryに参加しているクライアントにさせたい場合には、ActiveDirectoryのDNSがインターネット上のホストの名前解決を可能となるように構成可能です。(これはしばしば行われる構成です。) さらに混乱に拍車をかけるのは、ActiveDirectory以外にそもそも社内に独自のDNSの空間があって、そこに対してActiveDirectoryを追加するようなケースです。 既存DNSの名前解決をActiveDirectoryのDNSにもさせたい。- 既存DNSの名前解決をActiveDirectoryのDNSにはさせたくない。- 既存DNSの名前解決をActiveDirectoryのDNSにもさせつつ、インターネット上のホストの名前解決もできるようにしたい。- 既存DNSの名前解決をActiveDirectoryのDNSにはさせたくないが、インターネット上のホストの名前解決はできるようにしたい。- 既存DNSに問い合わせた場合にもActiveDirectory上のホストの名前解決はさせたい。- 既存DNSに問い合わせた場合にはActiveDirectory上のホストの名前解決はさせたくない。 まだまだバリエーションは増やそうと思えば増やせますね。 さらにここで社内の独自のDNSの名前空間がインターネット上のドメイン名と重複しているような場合…さらに混乱できる構成となってしまいます…。私も新人で、「DNSってインターネットの世界で名前解決に使うやつでしょ?」という認識だったころにこのあたりの話を聞いて大混乱したのをよく覚えています。ただ、実際のところ取りうる組み合わせは多数ありますが、実際にお勧めできる設計のパターンとしてはそんなに多くないのでそれらをこれから具体的に説明してみたいと思います。 長くなってしまったので、続きは「Active DirectoryとDNSについて その2」で。 Active DirectoryとDNSについて その2 | Windowsインフラ管理者への道 (ebisuda.net)

今回は「標準コマンドで楽をしよう」ということでcsvdeコマンドを取り上げます。大量のオブジェクトを属性付きでテキストに出力し一括で比較したい、あるいは大量のオブジェクトを一括で作成したい。しかし、スクリプトをかくスキルあるいは時間がない・・・。そんなときにcsvdeを知っていると非常に楽をすることができます。 csvdeとは csvdeはcsv data exportの略・・・だと思います（きっと）。ActiveDirectoryに対してcsv形式でデータを出力したり、入力したりできるコマンドラインツールです。CSV形式なので、Excelなどで簡単にデータを閲覧したり、作成したりできるので、非常に使い勝手がよいです。Windows 2000 Server以降のサーバーOSであれば基本的に使用できますが、バージョンによって微妙にコマンドラインオプションが異なったりしますので、つどヘルプを読むようにするのがいいと思います。ヘルプの読み方に関しては「コマンドラインヘルプの読み方」（※次に書く予定です。書いたらリンクを張ります。）を参考にしてください。 コマンドラインヘルプ 以下はWindows Server 2008 R2に標準で搭載されているcsvdeのヘルプです。 CSV Directory Exchange 汎用パラメーター -i インポート モードにします (既定ではエクスポート モードです) -f ファイル名 入力ファイル名または出力ファイル名 -s サーバー名 結合先のサーバー (既定ではコンピューターのドメインの DC) -v 詳細モードをオンにします -c FromDN ToDN FromDN を ToDN で置き換えます -j パス ログ ファイルの場所 -t ポート ポート番号 (既定値 = 389) -u Unicode 形式を使います -? ヘルプ エクスポート固有 -d RootDN LDAP search のルートです (既定では名前付けコンテキスト) -r Filter LDAP search のフィルターです (既定では “(objectClass=*)”) -p SearchScope 検索範囲 (Base/OneLevel/Subtree) -l list LDAP search で検索する属性の一覧 (コンマ区切り) -o list 入力から省略する属性の一覧 (コンマ区切り) -g ページされた検索を無効にします。 -m エクスポートで SAM ロジックを有効にします。 -n バイナリ値をエクスポートしません。 ...

ActiveDirectoryというと、色々な要素があり、なかなかとらえずらいですが、まずはひとつの見方として、認証、アカウント管理の視点からその進化の過程を見ていこうと思います。(※あくまでもひとつの見方です。) スタンドアロンPC まず、スタンドアロンPCではローカルでユーザー管理、アクセス制御を行います。ローカルにユーザーを作成することが出来、NT系のOSではローカルにユーザーを複数つくり、それぞれプロファイルを切り替えて使うことで1台のパソコンを共有する仕組みが備わっています。その上で他の人に見られたくないファイルには自分だけがファイルにアクセスできるようにアクセス権を設定することが出来ます。1台のWindowsマシン上で、マシンの共有とリソース権限の確保が実現されています。 複数のPCがあると困ること 複数のWindowsPCが存在すると、ユーザーアカウントデータベースはそれぞれのPCに個別に保持されます。アカウントとパスワードの組み合わせを複数覚える必要があるので少々不便になります。同じIDとパスワードにしてしまうことも考えられますが、ユーザーの登録作業は必須です。また複数PC間でリソースの共有ができないので、不便です。 ワークグループでのリソース共有 リソースの共有(例えば共有フォルダや共有プリンタなど)を実現するために、WindowsPC同士をネットワークでつなぎます。具体的にはNetBEUI、TCP/IPなどのネットワークプロトコルを構成し、相互に通信可能な状態にします。そのうえで、複数のマシンがネットワークに参加します。これをWindowsネットワークでは「ワークグループ」と呼びます。ワークグループに参加してしまえば、マイネットワークからネットワーク上のコンピューターの一覧が表示でき、共有したいリソースを「共有」し、他のPCに見せることが出来ます。しかし、ここでアクセス制御をする上で少々こまったことが起きます。 ワークグループでのリソース共有で困ること リモートのPCで共有されているリソースにアクセスしようとすると、IDとパスワードを聞かれてしまいます。これは他のPCにアクセスするためにはそのPCで有効なIDパスワードを入力し、そのPCのユーザーとしてアクセスする必要があるからです。複数のパソコンにアカウントデータベースが存在し、連携されていないのですからこれは当たり前です。 複数のパソコンで複数のIDが管理されており、パスワードも一致していないとしたら・・・かなり混乱します。これを避けるために、同じIDを全てのWindowsPCに登録し、パスワードもそろえてしまうという運用方法があります。これなら他のPCのリソースにいちいちID/Passwordを入力しなくてもアクセスすることが出来ます。 しかし、ある程度大きな規模でこれを実現しようとすると、1人新しく人が加わっただけで全てのPCにユーザーを登録して回らなくてはいけません。さらにセキュリティ対策のために、定期的にパスワードを変更する必要がある・・・などとなったら面倒でやっていられません。 アカウントデータベースの一元管理(NTドメイン) そこでアカウントのデータベースを個別のWindowsPCに持つのではなくて、一括してどこかにまとめて管理してしまおうという発想が出てきます。これがWindowsドメイン(NTドメイン)です。 NTドメインによって、認証やネットワーク資源の一元管理を行うことが出来るようになりました。 ユーザーはドメインに登録し、コンピューターはドメインに参加することで、ドメインに管理をゆだねます。PCにログオンするときや別のPCにあるリソースを使用する際には、アカウントデータベースとしてNTドメイン上のアカウントデータベースを利用するわけです。これで、どのPCにでも誰でもログオンでき、別のPCにあるリソースにアクセスする際に、一々ID,パスワードを入力する必要がなくなりました。 (余談)ローカル管理から一元管理への流れ ホスト名の解決にしても、NETBIOS名の解決にしても、データベースにしても、たいていのものはローカルでの管理から始まって、ネットワーク上で共有する方向に向かっているように思われます。 NTドメインの問題点 こうしてNTドメインにアカウント情報が共有され、クライアントPCもドメインのリソースとして登録すれば、どのPCにでもログオンできるし、リソースの管理も一元化できます。しかし、以下の問題点が・・・。 扱えるオブジェクト数の限界 NTドメインでは単一のドメイン内で扱えるオブジェクト数がそれほど多くなく約4万が限界でした。そのため大規模な環境の場合、アカウントを登録するドメインとは別にリソースを登録するドメインを分ける・・・ということを余儀なくされることがありました。 管理者の権限 ドメイン内においてドメイン管理者は全てのオブジェクトに大しての権限を持つことになります。本来であればひとつの拠点や部署など小さな単位で管理権限を与えたい場合でも、一般ユーザーでない場合にはドメイン管理者にせざるを得ず、不必要に強い権限を与えなくてはいけませんでした。これを避けるためには、これまたドメインを分割する必要がありました。 信頼関係の管理 上記のような理由からにドメインを分割した場合には相互に連携するために、信頼関係を結ばなくてはいけません。この信頼関係はドメインが増えるたびに全て追加で個別に登録の必要があったため、維持、管理に問題がありました。 シングルマスタ NTドメインではアカウントの管理は一元化されたものの、大規模に展開するためには、そのデータベースを複数用意し、参照できる必要があります。そうしないとトラブル発生時に全ての情報が失われてしまい、機能がストップしてしまうことになります。NTドメインではこれはPDCがマスター、BDCがバックアップといった具合に実現されています。 しかし、データベースの更新処理自体はPDCにしか行えず、PDCのデータのコピーをBDCが保持するという形態になっていたため、運用上少々不便でした。例えば、PDCが無い拠点とのネットワーク経路に障害が発生したような場合には、PDCにアクセスできず、ユーザー情報の更新すらできなくなってしまいます。 ActiveDirectoryでの改善 ActiveDirectoyでは上記の問題点が解消されています。 扱えるオブジェクト数の限界 ActiveDirectoryでは単一のドメインで扱えるオブジェクトの数が100万オブジェクト以上となり、事実上オブジェクト数のみを問題としてドメインを分割する必要はなくなりました。 信頼関係の管理 ActiveDirectoryでは「ActiveDirectoryフォレスト」というものを形成し、自動的に推移的な信頼関係を構築するので、信頼関係の維持管理にかかるコストが減少しました。 同一フォレストに子ドメインを作成すれば、自動的に信頼関係を結んでくれるようになったのです。 管理者の権限 ActiveDirectoryでは単一のドメインの中にOUという管理組織を作成することができ、その中にオブジェクトを格納できます。その上でそのOUに対して管理の委任を行うことができ、「このアカウントにはこのOUの管理を任せる」ということが出来るようになりました。 これによってわざわざドメインを分割することなく、1つのドメインの中で管理の制御が行えるようになりました。 シングルマスタからマルチマスタへ ActiveDirectoryではドメインコントローラーが対等な立場として存在し、そのドメインコントローラーでも情報の更新が行えるマルチマスタモデルになりました。 ただし、全ての機能が対等に存在しているわけではなくて、5つの機能(フォレスト単位で2つ、ドメイン単位で3つ)に関しては単一のドメインコントローラーが保持しています、これはFSMO(フィズモ)の役割などと呼ばれます。FSMOに関しては別のところで述べます。 ActiveDirectoryのいけてないところ 色々改善されたActiveDirectoryですが、悪いところも多々あります。 データベース容量 扱えるオブジェクト数の限界は増えたものの、その分データベースにしわ寄せが来ている印象があります。データベースエンジンはMicrosoftおなじみのExtensible Storage Engine(ESE)です。それぞれのオブジェクトが消費するデータベースが結構大きく、削除済みのオブジェクトも規定で60日間、2003R2以降では180日間保持されます。なので、オブジェクトの絶対数はそれほどでもないけれども、毎日大量に削除～作成を行うようなシステムでは容量は要チェックです。 テストフェーズだからといって、大量にオブジェクトを生成、削除を繰り返していると、DBが肥大化してしまうことになりますので、気をつけましょう。 信頼関係の管理 フォレスト内での信頼関係はいいのですが、その他のNTドメインや別フォレストと信頼関係を結ぼうとすると、結局以前のNTドメインの際の問題に直面します。ある意味仕方ないのかもしれませんが・・・。 ※ただし、フォレスト間の信頼関係に関してはWindowsServer2003で改善されています。 - [Active Directory フォレスト間信頼機能](http://www.microsoft.com/japan/windowsserver2003/evaluation/demos/flash_animations/01forest.htm) OUへの効率的なリソース配置 OUを分けることで管理を委任できる・・・というところが売りなのですが、OUに対していかに効率的にリソースを移動、配置するかという点はあまりサポートされていません。たとえば、コンピューターオブジェクトは普通にドメイン参加するとComputersコンテナに作成されるので、そこから手動でOUに移動する必要があります。ドメイン参加の際にコンピューターオブジェクトが作成される規定の場所を変更することは可能ですが、それも別の1箇所に変更するのみであって、条件によって振り分けるようなことは出来ません たとえば、あるOU以下しか管理権限がない場合に、単純にドメイン参加すると、Computerオブジェクトが管理下にないOUに作成されてしまい、手も足も出なくなってしまいます。このような場合、先にコンピューターオブジェクトを管理下のOUにつくっておけば問題は回避できますが・・・。 OUへのオブジェクトの配置は今のところ独自にアプリケーションを開発するなどして管理してあげる必要があります。 シングルマスタ、マルチマスタ 複数のDCに書き込めることのメリットも確かに沢山あるのですが、複数に書き込めるようになった分だけその整合性を取るところでおかしなことが起きます。書き込んだつもりの情報があとから更新された情報によって上書きされたり、削除したはずのオブジェクトを再作成しようとすると、まだ削除の情報が全てのDCに伝わっていないためにエラーではじかれてしまったり。最悪なのはDC間の同期がおかしくなった場合です。この場合完全に全ての最新の情報を救うのは絶望的になります。DC間の同期の正常性の確保は非常に重要です！