ドメイン参加するとなにが嬉しいのか? - チャットで頂いた質問への回答

皆さんこんにちは胡田です。今日は雨が降っていてちょっと残念な土曜日の午前です。30分ほど時間が空いたので少しブログエントリを更新します。 このサイトではフォーラムも設置していますが、投稿はほぼ皆無です。一方、1対1のチャットを設置してみたところ多数質問を頂いています。やはり皆さんプライベートなもののほうが質問しやすい、ということなのでしょうかね。 頂いた質問のうち複数人から質問されていて他の人にも有用そうなものをいくつかピックアップして、解説記事としても公開しておこうと思います。質問者が特定されないようにそのあたりはちょっと気を使って書いています。 ドメイン参加すると何が嬉しいのか? こちらの質問は姉妹サイトの「ドメイン参加 | Windowsインフラ管理者への道」エントリからの質問として多くいただきました。 ドメイン参加をすると何が嬉しいのかという事に関してはまた別エントリにして、ここでは、ドメイン参加時の設定の意味や良くあるトラブル等に関しての話をします。 と、書いておきながら10年近く記事を書いておらず申し訳ありません…。 ドメイン参加して何が嬉しいのか、ユーザーの立場と管理者の立場で簡単に解説したいと思います。これはActive Directoryのドメインに参加したときの話ですね。 ユーザーの立場からは - どのPCも同じIDとパスワードで利用できる という点が一番便利な点だと個人的に思います。例えばPCが複数台席に設置されていて、好きなところに座って使うような計算機室のような環境ですと、新しいPCを使うときには都度新しいアカウントをそのPCで作ってもらわないと使えない…というのは不便ですよね。このようなときにはPCをドメインに参加させてActive Directory上のユーザーアカウントを共通で利用できるようにしておくと大変便利です。 この時ファイルはどうするの?別のPCに入った時に前回の作業の続きをしたいときには?という疑問が出てくるかと思いますが、そのあたりも処理するために「移動プロファイル」というものもあります。個人の設定、個人のファイル(デスクトップ上のファイルやMyDocumentのファイル)もどのPCであっても使えるようにする仕組みがあります。 便利ですね。 実はこのあたりはもっと深い話が多数ありますが…今回はこの程度にとどめておきましょう。 一方管理者の立場からは - ドメイン参加したPCを一括で管理できる という嬉しい点があります。ユーザーアカウントのお話はすでに述べましたが、ユーザーを作成して、グループを作成して、グループのメンバシップを管理して…ということを個別のPCで1台づつ行うなんて悪夢ですよね。Active Directoryを使えばそれは一箇所で行えばドメイン参加した全てのPCで利用可能になります。 他にも、PCにたいして共通のセキュリティポリシーを一括で設定したいような時には「グループポリシー」という仕組みが使えます。 IDを一元管理できる。PCを一元管理できる。それがドメインに参加させることの大きなメリットです。 が、これって実はWindows NTドメイン~Active Directoryのお話です。今でももちろん現役であり多くの組織がここで書いた管理手法をとっているのですが、Microsoft 365時代にはこの常識は変化します。 Active Directoryを使わずに、Azure ADにWindows10を参加させ、Intuneでデバイスを管理し、Azure AD上のユーザーとグループを使わせながらIDもデバイスも守っていくことができます。クラウドネイティブなしくみでの管理ですね。クラウド時代にはこちらが主流になります。 これから勉強するならActive Directoryへのドメイン参加の概念は理解しつつも、是非クラウドサービスを使った管理手法を学んでいただくことを強くおすすめします。

September 15, 2018 · 1 min · 胡田昌彦

クラウド時代のマイクロソフト系インフラ管理者はまずAzure Active Directoryを理解し活用しましょう

オンプレミスのActive Directory クラウドのAzure Active Directory マイクロソフト系のインフラ管理者にとってオンプレミスの時代に特に重要だったのはActive Directory(以下AD)でした。拙著(Windowsインフラ管理者入門)でも触れたところです。Windowsのドメインという仕組みがあり、そのドメインの中でIDを司るADがあり、アプリケーションはADに対応し、ADに参加したWindowsクライアントからアプリケーションを利用していたのです。 クラウド時代においても依然としてADは重要です。ですが、様々なクラウドサービスを利用し、他の企業とも連携していく必要性が高まる中で、企業内ネットワークに閉じてADのIDのみを利用したシステムだけを利用していればよい時代はとっくに終わりました。 オンプレミスのADをActive Directory Federation Services(以下ADFS)を介して外部とフェデレーションで結ぶという形態での社外ネットワークへの対応もありますが、現在向かっている方向は明らかにAD + ADFSという構成ではなく、クラウド上のIDaaSであるAzure Active Directory(以下AAD)です。AADをID基盤として利用する形態を中心に進化しています。 AADはマイクロソフトが提供するクラウドサービス(Office 365, Azure, Dynamics 365等)のほぼ全てのID基盤となっています。マイクロソフトのクラウドサービスを使っているユーザーは特に意識していなくてもすでにAADを利用しており、クラウド上にIDを保持しています。しかもAADは基本料金無料で提供されています。 また、オンプレミスにADを持つ企業が簡単にAAD上にIDを保持できるように、IDを同期、連携する仕組みも完全に無料で提供されています。 マイクロソフト系のインフラ管理者にとってオンプレミス時代にはADを、クラウド時代にはAADを軸にIDを管理し、そのIDを軸に様々なアプリケーション利用をコントロールすることはほぼ必然であり、まずはじめに抑えておく必要がある部分です。 AADでサービス連携、企業関連系、コンシューマーID連携 AADにはSAML 2.0, WSFederation, OpenConnectID、OAuth 2.0等の業界標準のプロトコルも採用され、マイクロソフトが提供するクラウドサービスにとどまらずインターネット上の様々なサービスと業界標準のプロトコルで連携可能になっています。AzureAD B2B, AzureAD B2C等、企業間の連携やtwitter, facebook等のコンシューマー向けのIDとの連携機能も備えています。 過去、ADを中心としたIDシステムにおいて企業間、グループ企業間でシームレスに連携させることは非常に困難でした。単純にネットワーク的につながっていないものを接続する所から苦労は始まり、個別にシステム毎に連携方法を模索し、ロジックを作り込んでいるケースが多くありました。 クラウド時代には過去と同じような苦労をする必要はありません。IDはインターネット上に存在しており、自由に標準的なプロトコルで連携可能となるのです。 セキュリティ対策 クラウド上にIDシステムが存在することでセキュリティ面の心配をする人も多くいると思います。ですがそれは逆です。むしろクラウド上にIDを保持することの方がセキュリティ面で有利である時代になっています。 クラウドサービスを全く使わずにIDもシステムも完全に社内ネットワークで閉じている状況であれば確かに外部からの攻撃に対しては非常に強いでしょう。入り口も出口も無く、窓を全て締め切っていれば外界から攻撃する手段はありません。それは事実です。ですが、このようにインターネットと分離した環境であったはずの環境においても利便性を求めた結果本来の設計とは異なる構成となってしまい、大規模なセキュリティ事故が起きた実例があります。 このクラウド時代に外部から完全に閉ざした鎖国状態のシステムを作っても生産性高く活動を行えるはずがありません。そうなるとインターネットとの接続をどうしてももつ必要があります。その段階でクラウド上にIDをもつか、オンプレミス上にあるIDに対しての認証の窓口を開かなくてはいけません。 インターネット上に常に存在し、多数の攻撃にさらされながらそれに耐え、しっかりとした運用体制やセキュリティ対策の取られているクラウド上のIDaaSを利用するのと、オンプレミスで自分たちで面倒を見ているシステムとでどちらがセキュリティが高いでしょうか。クラウド上のIDaaSには大量のIDをさばきながら取得できる情報を活用した高付加価値のセキュリティ対策サービスが多数備わっているという現実もあります。ここは人によって意見が分かれる場所かもしれませんが、私見ではあきらかにクラウド上にIDをおいたほうがセキュリティが高くできる現実がすでにあり、今後もその傾向はどんどん強まっていくと考えられます。 むしろ積極的にクラウド上にIDを置き、IDaaSが継続的に進化し続ける機能を把握し、それを有効に活用すべき時代になっていると考えます。 まずAzure Active Directoryの活用から マイクロソフト系のインフラ管理者がクラウドに足を踏み出す際には、個人的なおすすめとして是非AADの活用から考えてもらいたいと思います。AD+ADFSではなく、他社のIDaaSサービスではなくAADを利用してほしいです。 AADはマイクロソフトのクラウドサービスの根幹となり、全てのシステム、全ての仕組みに関連するものだからです。 そして、AADは無料でありいくつでも作成できるものなのですが、「本番AAD」を1つ作成し、基本的に全てのものをそこに紐付ける形にすることをお勧めします。つまりそれはシステム毎にID、Passwordを別々に作成して分割する…ということをしないようにするということです。私のおすすめは全て、例外なくです。他社製のクラウドサービスを利用するときですらです。 この構成をお勧めするのには様々な理由があり簡単に言い表すことは難しいのですが「1つのIDを利用して全てのものを利用可能とするのが最も便利でセキュアで運用コストが低いから」です。この点はもっと説明が必要ですのでまた今後のブログエントリで解説していきたいと思います。

April 22, 2018 · 1 min · 胡田昌彦

Azure Stack上ではAADを認証基盤につかいましょう!

日経SYSTEMSの2017年9月号のAzure Stackに関連する記事に私のコメントも掲載されています。 日本ビジネスシステムズの胡田氏は「Azure StackでID管理に用いるAzure Active Directoryは、ユーザー企業のオンプレミス環境で一般的なActive Directoryとは別物。混乱を招く恐れがある」と指摘する。私も、Web上や雑誌上でも記事を書いたり、インタビューを受けてコメントが掲載されたりなどかなり露出がふえており、大変ありがたいことです。私は人生の生存戦略において、外部露出を増やす戦略でやっていますので実名でこのように雑誌記事にコメントがのるのは大変ありがたいことでして、是非インタビューでもなんでもお声がけいただければと思います。 と、大変ありがたい話ではあるのですが、流石に短い紙面でこのコメントだけ掲載だと相当の誤解を産んでしまうのも致し方がないところだと思います。このコメントに関しては追加で補足をさせてもらおうと思います。 まず、Azure StackでID管理にAzure Active Directoryを用いるというのは半分正しく、半分正しくありません。Azure Stack自体へのアクセス、特に管理ポータルへのアクセス時に使うIDはAzure Active DirectoryとADFSのどちらかが選択可能です。推奨はAzure Active Directoryであり、つまりはクラウド上のIDですからインターネット接続が行えることが前提条件となります。Azure Active DirectoryのIDということはつまりはO365で利用しているIDとも共通とすることができるわけであり、Microsoftの戦略からするとクラウドIDの中心としてのAzure Active Directoryを軸に全てのクラウドサービスをコントロールしようとしていますので、Azure Stackもその1つということで何も違和感がありません。 ただ、一方で「インターネットには接続させない、クラウドサービスは利用できない」という環境ではAzure Active Directoryを使うことはできませんから、そのためのオプションとしてADFSおよびADFSと連携するActive DirectoryをIDとすることもAzure Stackでは可能となっています。この場合、「ユーザー企業のオンプレミス環境で一般的なActive Directory」のIDをそのまま利用可能となりますから、何も混乱なく利用可能となります。 さらにいうと、企業においてAzure Active Directoryを利用する場合にはそのIDはオンプレミスのActive DirectoryとAD Syncにて同期されているケースが非常員多いため、Azure Active DirectoryをIDとしている場合でも、それは事実上Active DirectoryのIDと統一であり、混乱を招くようなものではないケースが多いでしょう。 記事上では表現されていませんが、私が危惧している心配はAzure Stackのマネジメントポータル利用時のIDではなく、Azure Stack上に構築されるシステムへのアクセスに利用されるIDに関してなのです。 もちろんAzure Stack上にIaaSを利用してWindows Serverを展開し、そのWindows Serverを既存のネットワーク上のActive Directoryにドメイン参加させ、いつもと同じようにAD統合認証でシステムを作成する…、これはもちろんやろうと思えばできるのですが、これをやろうと思うと、オンプレミス同士にもかかわらずVPN接続が必要になってきます。これ、非常に違和感が出てしまうんじゃないかと思っています。 もちろんAzure StackはAzureそのものなのですから、VPNで接続するというのはAzureと同等であり、一貫性があります。 でも、同じ社内ネットワークに存在している「隣のサーバー」なのにVPNをはらないとネットワーク的につながらないというのはちょっと違和感を感じるひとが多いいんじゃないかと思うんです。 さらにAzure StackになるとInfrastructure as Codeも非常にやりやすくなります。コードにシステムを表現しておいて、それを展開して環境を作り出す…必要なくなったら消す…そんなことをバンバンするようになってくると…。既存環境へのVPN接続やドメイン参加をして…ということが非常に足かせになってしまいます。そもそも同じ環境を2つ作ろうとおもうと、コンピューターアカウントが重複して問題が発生してしまったりもしますしね。 つまり、Azure Stack上でAzure Stackらしい使い方をしようと思うと、今までのようにActive Directoryを使った認証にするのではなく、自然とAzure Active Directoryを使った認証システムを採用することになると思っています。 Azure Active Directoryに寄せることで色々とメリットも出てきます。Azure Active Directory Premiumの各種機能を使って認証を強化したり、セキュリティを強化したりできるが大きいでしょうか。 このあたりをきちんと理解してシステムを組んでいくようになるのがすぐ近い未来だと私は思っています。「社内であっても認証にActive DirectoryではなくAzure Active Directoryを使う」このあたりをきちんと理解し、システムを構築するようになるまでには、まだまだ結構色々とあちこちで苦労があるだろうなと思ってます。 雑誌のコメントにはこのようなバックグラウンドがあり、それが凝縮されてあのような表現になっているわけです。 Azure Stackを利用するなら、IaaSでVPNをつかって既存のシステムとネットワーク的にに連携してAD統合認証…ではなく、PaaSをつかって認証はAzure Active Directoryを使ったシステムをまず第一に考えて行きたいですね! ...

October 21, 2017 · 1 min · 胡田昌彦

Active DirectoryとDNSについて その2

前回の記と事を書いて、「続きはその2で」…と言いながら4年以上の月日が流れてしまいました。4年…あまりにも長い月日なので、結局当時のことはもう通用せず意味が失われ……てはまったくいないのが現在です。 今でもきちんとActive Directoryを理解することは難しいですし、そのなかでDNSの扱いの理解が難しいことも変わりません。そもそもちょっとたったら知識が陳腐化してしまうようなことはどうでもいいことですしね。 というわけで、4年以上の歳月をあけて「その2」です。 でも、随分間が空いてしまったので自分でも何をその2で書こうとしていたのかよく覚えておりませんが…、とりあえず前回予告したとおりいくつか典型的なパターンを挙げてみましょう。 社内のActive Directoryにはインターネットには絶対に存在しないドメイン名をわりあて、社外(インターネット)の名前解決はそもそも行わせないパターン まずはこのパターンから見ていきましょう。これは「Active Directoryが使うDNS」と「インターネットの世界のDNS」が完全に分離されているパターンです。 この場合には具体例としては「test.local」というようなドメイン名がActive Directoryの使うドメイン名として割り当てられることになります。 xxx.localというドメインはインターネット上には絶対に存在し得ないドメイン名です。なぜならトップレベルドメインにlocalというのは存在しないからです。今後追加される可能性がゼロでは無いものの、その場合にも「local」が選択される可能性はほぼ0と言ってよいでしょう。 そして、社外の名前解決はクライアントに対して行わせないパターンですので、社内のネットワークは全てインターネットの世界とはつながらず、切り離して考えることが出来ます。 つまり、社内のDNSの世界は完全にActive Directory用として切り離されています。そのなかでドメインコントローラーを探したり、同じドメイン内の他のホストを探したりという動きにはActive DirectoryのDNSが使われることになります。 技術的にはインターネット上のDNSと同じ技術が使われているが、社内の閉じた世界、Active Directoryの閉じた世界でのみ使用されているため混乱する要素がありません。 しいて言うならば、この場合にどうやってインターネットにアクセスできるのか?ということが疑問としてでるかなと思います。 これにかんしては、このような構成をあえてとっている場合には「インターネットには管理対象のクライアントは完全にアクセスさせない」という構成にする、というのがまず一つあります。 インターネットに繋がることが当たり前の今日においてこれは違和感があるかもしれませんが、セキュリティ対策を完全に行おうと思えばインターネットへのアクセスがどのような形であれ行えてしまえばもうなんでもありの世界ですから、インターネットへのアクセス自体を完全にブロックさせるというのは一つの考え方としてはありなわけです。 このケースにおいては、Active Directoryでは技術的にDNSを使っているけれども、ただ単に技術的に同じものが使われているだけであって、完全に切り離されている。ということで理解してもらえればと思います。 社内のActive Directoryにはインターネットには絶対に存在しないドメイン名をわりあて、社外(インターネット)の名前解決はそもそも行わせない…けれども、Web閲覧は許可する インターネットへのアクセスはセキュリティ面を考慮してさせたくない…けれども、やはり完全に隔離するのも不便すぎるので、Web閲覧のみは許可する、というパターンがあります。 この場合には、ブラウザの設定として、Proxyサーバーを設定し、Web閲覧のみProxyを経由することでインターネットにアクセス可能とします。もう少し正確に書くと、「Proxyサーバーに閲覧したいWebサイトのアドレスを伝えて、コンテンツを代わりに取ってきてもらい、結果のみProxyサーバーから受け取る」という事になります。 この場合、DNSを用いたインターネット上の名前解決を行っているのはProxyサーバーのみであり、クライアント自身はDNSを用いてインターネット上の名前解決をする必要はありません。 ですから、クライアントが参照しているのはローカルのActive Directoryのドメインコントローラーが持つDNSであり、Proxyサーバーが参照しているのはインターネットホスト名が解決できる(Active DirectoryのDNSではない)DNSということになります。 内部の(Active Directoryの)名前解決ができるDNSと外部の(インターネットの)名前解決ができるDNSを完全に分離してしまい、そこは連携させず、クライアント自体は内部のDNSを参照させて、インターネットの世界からは分離させ、ブラウザでWebサイトを見る時だけProxyにお願いすることで(直接クライアント自身ではインターネットにアクセスしないことで)このような構成を可能としています。 うーん。まだまだパターンはありますね。続きは「その3」で…。(いつになることやら。)

June 11, 2016 · 1 min · 胡田昌彦

AD上で表示名が同じオブジェクトを見つける

必要があってちょっとだけ簡単なPowerShellスクリプトを書きました。 AD上で表示名が同じスクリプトを見つけるスクリプト…と言いながら、以下の実装としては「displayNamePrintable」が同じオブジェクトを見つけるスクリプトです。 表示名で探すようにするのは単純にif文の中の属性を変更するのみです。 https://gist.github.com/ebibibi/16dbd44cd27ea7e0c0be

August 24, 2015 · 1 min · 胡田昌彦

Remove User from Groupアクティビティの1501ユーザー以上が存在するグループに対しての処理に失敗する問題に対しての回避方法

以下のスクリプトでuser1~1600ユーザーを作成し、user1501をSCOの「Remove User From Group」アクティビティで削除しようとするとエラーが発生してしまいます。 > New-ADGroup -Name “scogroup” -GroupScope Universal for($i=1; $i -lt 1601; $i++) { New-ADUser -Name (“user” + $i) } for($i=1; $i -lt 1601; $i++) { $user = Get-ADUser (“user” + $i) Add-ADGroupMember -Identity “scogroup” -Members $user } エラーメッセージは以下です。 > The group member ‘CN=user1501,CN=Users,DC=ebsjsc,DC=local’ was not found. Exception: AdGroupMemberNotFoundException Target site: LdapGroup.RemoveMember Stack trace: 場所 Microsoft.Accelerators.ActiveDirectoryCore.LdapGroup.RemoveMember(DistinguishedName memberDistinguishedName) 場所 Microsoft.SystemCenter.IntegrationPack.ActiveDirectory.Execution.RemoveUserFromGroupExecutor.DoAction(Object executionItem) 場所 Microsoft.SystemCenter.IntegrationPack.ActiveDirectory.Execution.AExecutor.ExecuteNonGetAction(Object executionObject) 場所 Microsoft.SystemCenter.IntegrationPack.ActiveDirectory.Execution.AExecutor.Execute() 場所 Microsoft.SystemCenter.IntegrationPack.ActiveDirectory.Execution.ActiveDirectoryProgram.ExecuteProxy(ExecutionProxy proxy) 場所 Microsoft.SystemCenter.IntegrationPack.ActiveDirectory.AActiveDirectoryActivity.Execute(IActivityRequest request, IActivityResponse response) 明らかにアクティビティの実装ミスだと思われます。 1500以上のユーザー数を扱う場合にはPageSizeを適切に設定してオペレーションをしないといけない…というのはAD系のプログラムを書いている人なら多くの人が知っていることかなと思います。 - DirectorySearcher.PageSize Property (System.DirectoryServices) しかたがないので、とりあえず問題を回避するには以下のようにPowerShellスクリプトを書くことが出来ます。 > $group = “"$member = ““Import-Module ActiveDirectoryRemove-ADGroupMember -Identity $group -Members $member -confirm:$false これでよし…と思ったのですが、これではRemove-ADGroupMemberコマンドレットが見つからないと言われてエラーになってしまいました。 残念ながら呼び出されるPowerShellのバージョンが低いようです。 Windows Server 2012 and Orchestrator Run.NET Script Activity in PowerShell - Execution Policy? 対処として以下のレジストリを作成しました。 hklm\software\wow6432node\microsoft.netframework\OnlyUseLatestCLR 種類はDWORDで値は1です。 情報元は以下のブログです。 - hklm\software\wow6432node\microsoft.netframework\OnlyUseLatestCLR これで常に最新のバージョンのPowerShellが立ち上がるようになり、うまく動作させることができました。 ...

July 5, 2015 · 1 min · 胡田昌彦

MVAのお勧めコンテンツの紹介

Microsoft Virtual Academy(MVA)では無償で良質のコンテンツが多数提供されています。 今回はその中でも特にお勧めのコンテンツを紹介します。 ID管理 まずID関連で超お勧めなのは安納さんの「クラウド時代のActive Directory次の一手シリーズ」です。 - [クラウド時代の Active Directory 次の一手シリーズ ~ 第 1 回 Active Directory の位置づけ](http://bit.ly/1QjvAQu) - [クラウド時代の Active Directory 次の一手シリーズ ~ 第 2 回 Active Directory ドメイン サービスの新しい役割](http://bit.ly/1GPP3rl) - [クラウド時代の Active Direcrory 次の一手シリーズ ~ 第 3 回 Active Directory フェデレーション サービスの役割 解説編](http://bit.ly/1AHn4ZT) - [クラウド時代の Active Direcrory 次の一手シリーズ ~ 第 4 回 Active Directory フェデレーション サービスの役割 構築編](http://bit.ly/1M2dstR) - [クラウド時代の Active Directory 次の一手シリーズ ~ 第 5 回 認証のためのプロキシ Web Application Proxy](http://bit.ly/1FnQusO) - [クラウド時代の Active Directory 次の一手シリーズ ~ 第 6 回 Microsoft Azure Active Directory とは](http://bit.ly/1LVTTmv) 社内でActive Directoryで管理させていたWindows PCをつかってWindows統合認証をしていれば幸せになれる時代はとっくに終ってしまって、これからのクラウド時代で様々なSaaSを効果的に利用しながらID管理もシンプルに保ちつつ、セキュリティも担保していかなくてはいけないのが現在の状況です。ID管理はやっぱり肝です。これらのコンテンツで大きな流れを理解することが出来ます。「フェデレーションってよく聞くけどなんだか難しそう…」という人におすすめです。 ...

June 1, 2015 · 1 min · 胡田昌彦

Azure Active Directoryについて

金曜日の帰りの電車で座席に座れたので、Surfaceを取り出してこのブログを書いています。最近ブログ記事を全然書けていないので書きたいことがたくさんたまっております…。 さて、今回の話題はAzure Active Directory(AAD)です。オンプレミスのActive Directoryは知っていてもAzure上のActive Directoryの事を概念的に理解出来ている人はまだまだ少ないのが現状ではと思います。私が理解しているところをいくつか書いておこうと思います。一部正確ではない表現をあえて書いている部分がありますし、私の理解がそもそも間違っている部分があるかもしれません。ですが、まずはこういう理解から入ると良いだろうと思っています。 - オンプレミスのActive Directory Domain Service(ADDS)と似た名前がついてますし、機能的に同じ部分も一部ありますが、当初の理解のためには「名前は似てるけど現状は完全な別物」という捉え方をするのがよいだろうと思います。(将来的には同じような形に収束するのかもしれません。むしろクラウド上のみで完結する形になるのかもしれません。どういう方向に行くか、ワクワクしながらウオッチする感じです。) - AADはクラウド上にあって、インターネットに公開されていて、インターネット上での外のサービスとの連携を主眼に機能が用意されています。 - AADにはユーザーやグループ等が登録できます。 - O365のユーザー情報はAADに格納されています。例えばExchange OnlineはディレクトリとしてO365のテナント用に用意されたAADを利用しています。 - AADはAzure上のサービスとして存在しているので、いくつでもテナントを作成することができます。 - Microsoftアカウントはマイクロソフトが用意してくれていて全世界に公開されている1つのAADテナントです。 - AADのテナントは開かれているので、AADの1つのテナントに別のAADのテナントのユーザーを登録して権限を付与する…というようなことも可能です。 - AADとオンプレミスのADDSは「ディレクトリ同期ツール」にて同期することが可能です。 同期は基本的にADDSからAADの方向のみです。 - パスワードに関してはAADからADDS方向の同期も実装されてきました。今後も増えていくのかもしれません。 - AADの管理は複数の場所から行えるのですが、一番充実した管理が行えるのはAzureの管理ポータル画面からです。 - O365のAADも1つのAADなので、Azureの管理ポータル画面からO365で利用しているAADを「追加」して管理することができます。 - AADに機能を追加したAzure AD Premiumというサービスがあります。これはAzureの管理ポータルから管理します。O365の管理ポータルからは管理できません。 超簡単なまとめとしてはオンプレミスのID管理はAD DS。クラウドのID管理はAAD。間のID同期はディレクトリ同期ツール。というあたりで良いのかなと思います。 ADFSは?という声が聞こえてきそうですが、一旦ADFSを絡めずに理解するのが良いのではと思います。 ADDSの理解。AADの理解。ADFSの理解。これらを単体で理解した上で、この3つをつなげた時に行える世界の広がりを理解すると感動的だと思います。 もっとちゃんと時間をとって書きたいですね…。

February 20, 2015 · 1 min · 胡田昌彦

Windows Server, System Center, Azure, Active Directory, Lync, Exchange等のVisioステンシルリンク集

スライド作成、資料作成の際にVisioのステンシルがあると助かります。 以下みつけたいい感じのステンシルへのリンクを紹介します。他にも見つけたら追加しますね。他にもいいものを知っている方がいたら教えて下さい。 - [TechNet System Center 2012 R2 - Virtual Machine Manager (SCVMM) Visio Stencils](http://gallery.technet.microsoft.com/System-Center-2012-R2-7a5f1fcd) - [TechNet System Center 2012 R2 - Data Protection Manager (DPM) Visio Stencils](http://gallery.technet.microsoft.com/System-Center-2012-R2-Data-ef61aa5d) - [TechNet System Center 2012 R2 - Operations Manager (SCOM) Infrastructure Visio Stencils](http://gallery.technet.microsoft.com/System-Center-2012-R2-44552676) - [TechNet System Center 2012 R2 - Operations Manager (SCOM) Application Visio Stencils](http://gallery.technet.microsoft.com/System-Center-2012-R2-0608df9a) - [TechNet System Center 2012 R2-Operations Manager (SCOM) Network Monitoring Visio Stencil](http://gallery.technet.microsoft.com/System-Center-2012-R2-a159ebae) - [TechNet System Center 2012 R2 - Operations Manager (SCOM) APM Visio Stencils](http://gallery.technet.microsoft.com/System-Center-2012-R2-57f8418e) - [TechNet Windows Server 2012 Visio stencil](http://gallery.technet.microsoft.com/Windows-Server-2012-Visio-bcac9141) - [TechNet SCCM 2012 Visio Stencils](http://gallery.technet.microsoft.com/SCCM-2012-Visio-Stencils-166257b0) - [TechNet Hyper-V,SCVMM-Vision Stencil](http://gallery.technet.microsoft.com/Hyper-VSCVMM-Vision-Stencil-3dc18770) - [TechNet Windows Azure Pack & Windows Azure Visio Stencil](http://gallery.technet.microsoft.com/Windows-Azure-Pack-Windows-813d13a8) - [スクリプト Active Directory Visio Stencils 2013 - Directory Services Visio Stencils](http://gallery.technet.microsoft.com/scriptcenter/Active-Directory-Visio-136ad959) - [Visio Stencil 2013 : SharePoint - Lync - Exchange – Windows](http://gallery.technet.microsoft.com/office/Visio-Stencil-2013-1d09cb4d) - [Office Custom Lync Stencil](http://gallery.technet.microsoft.com/office/Custom-Lync-Stencil-f17a902f)

May 30, 2014 · 1 min · 胡田昌彦

ドメイン参加時にSIDの重複を指摘してくれるようになってました

検証環境を構築していて、うっかりsysprepを実行し忘れていました。その状態でドメインコントローラーとメンバーサーバーを複製して構築し(ドメインコントローラーとメンバサーバーのSIDが同一)、メンバサーバーをドメインに参加させようとした所、以下のようにSIDの重複を指摘してくれました。 いつからこのような挙動になったのか知りませんが、ちょっと親切になりましたね! photo credit: wallace39 " mud and glory “ via photopin cc

April 19, 2014 · 1 min · 胡田昌彦

SCCMサイト情報のActive Directoryへの発行

SCCMのサイト情報をクライアントに通知する方法は色々ありますが、一番良く使われるのはActive Directory及びそのDNSへの発行だそうです。この処理が行われていればDNSを参照しているクライアントが管理ポイントを発見して正常に接続することができます。 以下はその処理が成功していることの確認方法です。 [管理] – [概要] – [階層の構成] – [Active Directoryフォレスト]に、探索を有効にしているフォレストの一覧が出てきます。そこで[発行ステータス]が[成功]になっていればきちんとフォレストに対して管理ポイントの情報を発行することができています。 この操作でCN=System Management,CN=Systemへのオブジェクトの作成が行われています。(おそらく) DNSにもSRVレコードが作成されています。 この辺りは基本的に自動的になされる処理なのであまり気にしないはずなのですが、私はSystem Managementフォルダへのコンピューターアカウントのアクセス件の出し方に失敗(子オブジェクトへのアクセス権を許可しなかった)関係でフォレストへの発行がうまく行かず、その結果ワークグループ環境のコンピューターで何時までたってもエージェントがまともに動かないことでこの辺りに問題が発生していたことに気が付きました。自戒を込めて書き残しておきます。

February 18, 2013 · 1 min · 胡田昌彦

SCCMサイト情報のActive Directoryへの発行

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCCMサイト情報のActive Directoryへの発行 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/02/18/sccm%E3%82%B5%E3%82%A4%E3%83%88%E6%83%85%E5%A0%B1%E3%81%AEactive-directory%E3%81%B8%E3%81%AE%E7%99%BA%E8%A1%8C/)

February 18, 2013 · 1 min · 胡田昌彦

AUUPで良いのでは? / ActiveDirectoryのグループ設計はどうあるべきか。(AGDLP, AGUDLP, AUP, AU(U)P)

今回はActiveDirectoryのグループ設計について考えてみます。マイクロソフトの推奨設計としてAG(U)DLPという設計があります。しかし、私はこれに賛成できません。 AGUDLPはそれぞれ以下の意味になります。 - A - アカウント - G - グローバルグループ - U - ユニバーサルグループ - DL - ドメインローカルグループ - L - ローカルグループ(※AD上のグループではない) - P - パーミッション 私がこの考え方を知ったのは2008年に受けた講習でした。 - http://ebi.dyndns.biz/diary/20080318.html#p01 検索をするとWikipediaをはじめ多数ヒットします。日本語では、以下の記事が非常に分かりやすくまとまっています。 - [ASCII.jp:Active Directoryのアカウントとグループとは?|Windows Serverで学ぶサーバOS入門 ](http://ascii.jp/elem/000/000/504/504463/) - [ASCII.jp:「機能レベル」でActive Directoryの互換性を確保しよう|Windows Serverで学ぶサーバOS入門](http://ascii.jp/elem/000/000/505/505060/) 詳細は上記の記事を読んでいただくとして、コンセプトとしては以下のような感じです。 - AUP(小規模向け) ユーザーではなくグループにアクセス権を付与する。 - 別の人が権限を引き継ぐ際や別の人にも同じ権限を付与する場合に直接アクセス権をいじらずともメンバの変更だけで済む。 - AGLP(AD管理者とサーバー管理者が分離している場合に向け) アカウントをまとめるグループと権限を付与するグループ(役割)を分離する。 - サーバーのローカルグループはサーバー管理者権限が、ADの権限がなくても勝手に作成、メンバ変更ができるのでいい! - 欠点:ローカルグループはサーバー単位にしか存在しないので複数サーバーで同じ事をやろうとするとサーバー毎に設定が必要。 - 欠点:ドメインをまたがる権限設定ができない。 - AGDLP(AD管理者とサーバー管理者が同じ場合に向け) コンセプトはAGLPと一緒 - ドメインローカルグループであればAD上にあるので、全てのメンバサーバーで同じグループを使える。AGLPの欠点であるサーバー毎の作業が無くなる。 - 欠点:ドメインローカルグループはAD上のオブジェクトであり、ActiveDirectoryの管理者権限が必要となる。OUへの権限委任等で回避するケースあり。 - 欠点:ドメインをまたがる権限設定ができない。 - AGUDLP(マルチドメインの大規模環境に向け) コンセプトはAGLP, AGDLPと一緒 - ユニバーサルグループでグローバルグループをまとめる事によってドメインをまたがる権限設定を行えるようになる。 ……。という事なのですが、はっきりいって私はこれには賛成できません。ユニバーサルグループですきなようにやれば良いじゃないというのが私の考えです。あえて上記と同じように書くならば「AU(U)P」という感じでしょうか。以下でその理由を説明します。 ...

February 2, 2013 · 1 min · 胡田昌彦

Active Directory Domain Service管理パックがWindows Server 2012対応しました

Active Directory Domain Services管理パックが更新され、Windows Server 2012に対応しています。 Active Directory Domain Services Management Pack for System Center

January 24, 2013 · 1 min · 胡田昌彦

Active Directory Domain Service管理パックがWindows Server 2012対応しました

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [Active Directory Domain Service管理パックがWindows Server 2012対応しました | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/01/24/active-directory-domain-service%E7%AE%A1%E7%90%86%E3%83%91%E3%83%83%E3%82%AF%E3%81%8Cwindows-server-2012%E5%AF%BE%E5%BF%9C%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/)

January 24, 2013 · 1 min · 胡田昌彦

Exchange Server 2010を複数サイトに展開するときに把握しておくべき挙動について

最近はメールシステムが大容量化、重要化したり、Exchange Serverがソフトレベルで標準でDR(Disaster Recovery = 災害対策)の仕組みを備えているなどの事情があり、DRサイトを構築する機会が増えてきました。また、やはり震災の影響も大きいですね、本格的にDRサイトを構築するのが当たり前の時代になってきたように思います。 Exchange Server 2003のころは標準でDRの仕組みを持たなかったり、Exchange Serverが存在するサイトのGCをOutlookが使いだしてしまうこともあってExchange Server専用のサイトを作成し、その中にExchangeとExchange用のGC(DC)を配置することが多かったのですが、ずいぶんと時代は変わったものです。 さて、Exchange Server 2010でDRサイトを構築するとなるとたいていの場合Exchange ServerをActive Directoryの複数サイトにまたがって構築することになります。そうするとシングルサイトで構成していたときにはあまり考えなくても良かった考慮点が色々と出てきます。 その中から今回は2点取り上げて記録しておきたいと思います。(最近質問されて調べたのでまとめておきます) サイトをまたいだCAS ArrayとDAGの接続について CASはMBXを配置するサイト内に必ず1つは必要です。またCAS Arrayはサイト内に1つしか作成できません。なので本番サイトとDRサイトにそれぞれ1つずつCAS Arrayが作成されるのはほぼ自動的に決まります。 一方、DAGに関しては、素直に設計するなら本番サイトとDRサイトにまたがって構築されることが多いだろうと思います。データもコピーしたいし、フェールオーバーしたいですし。 この時、Outlookの接続しているCASのサイトと、DAGのアクティブノードが別サイトになったときにどのような挙動になるでしょうか?DAGのみ問題が起きてフェールオーバーした場合やクライアントが意図せず別サイトにアクセスしているケース、本番サイトからDRサイトへの切り替え、切り戻しの際の一時的な状況等で発生する可能性がある状況です。 調べたところ以下の事が分かりました。Exchange 2010 SP2 RU3で挙動が変更になっています。 Exchange 2010 SP2RU2及びそれ以前 CASは自分の存在するサイト、DAGのアクティブサーバーの存在するサイトを意識しません。 クライアントはちゃんとアクセスできていれば、Autodiscoverの値が変わってても無視します。 結果、CASとMBXの間がサイトまたぎのアクセスになってもそのままつながります。(つながっちゃいますの方が表現として正確かもしれません。) - Exchange 2010 SP2RU3以降 DAGのプロパティーのAllowCrossSiteRPCClientAccessが使えるようになります。規定の値は$falseです。 AllowCrossSiteRPCClientAccessが$trueの場合(あえて設定変更した場合)以前のバージョンと同じ動きになります。 AllowCrossSiteRPCClientAccessが$falseの場合、CASは違うサイトのMBXへのアクセスに関してはクライアントに「サイト間違ってるよ。正しいCASArrayはあっち」と教えます。 クライアントは教えられたらきちんとプロファイルを更新します。 このことやこの周辺のことは以下のブログで解説されています。 RPC Client Access Cross-Site Connectivity Changes - Exchange Team Blog - Site Home - TechNet Blogs ### ### ### ### サイトをまたいだOWAのアクセスについて OWAとMBXの関係についても同様に考慮が必要です。OWAの場合にはユーザーがサイトをまたいでメールボックスを移動したとき等に一番効率的なOWAを伝える必要等も発生するのでその点からも確認が必要です。 こちらもSP2で挙動が変化できるようになっています。 OWAに関してはExchangeのバージョンまたぎの問題や、External URLが指定されている、されていない、IISの仮想ディレクトリの認証モードによって挙動が異なるなど様々な要因によって挙動が変化します。詳細は以下のブログで解説されているので確認してみてください。 OWA Cross-Site Silent Redirection in Exchange 2010 SP2 - Exchange Team Blog - Site Home - TechNet Blogs私は単純化して以下のように理解しました。(はしょり過ぎかもしれませんが……) ...

December 9, 2012 · 1 min · 胡田昌彦

Exchange Server 2010を複数サイトに展開するときに把握しておくべき挙動について

最近はメールシステムが大容量化、重要化したり、Exchange Serverがソフトレベルで標準でDR(Disaster Recovery = 災害対策)の仕組みを備えているなどの事情があり、DRサイトを構築する機会が増えてきました。また、やはり震災の影響も大きいですね、本格的にDRサイトを構築するのが当たり前の時代になってきたように思います。 Exchange Server 2003のころは標準でDRの仕組みを持たなかったり、Exchange Serverが存在するサイトのGCをOutlookが使いだしてしまうこともあってExchange Server専用のサイトを作成し、その中にExchangeとExchange用のGC(DC)を配置することが多かったのですが、ずいぶんと時代は変わったものです。 さて、Exchange Server 2010でDRサイトを構築するとなるとたいていの場合Exchange ServerをActive Directoryの複数サイトにまたがって構築することになります。そうするとシングルサイトで構成していたときにはあまり考えなくても良かった考慮点が色々と出てきます。 その中から今回は2点取り上げて記録しておきたいと思います。(最近質問されて調べたのでまとめておきます) サイトをまたいだCAS ArrayとDAGの接続について CASはMBXを配置するサイト内に必ず1つは必要です。またCAS Arrayはサイト内に1つしか作成できません。なので本番サイトとDRサイトにそれぞれ1つずつCAS Arrayが作成されるのはほぼ自動的に決まります。 一方、DAGに関しては、素直に設計するなら本番サイトとDRサイトにまたがって構築されることが多いだろうと思います。データもコピーしたいし、フェールオーバーしたいですし。 この時、Outlookの接続しているCASのサイトと、DAGのアクティブノードが別サイトになったときにどのような挙動になるでしょうか?DAGのみ問題が起きてフェールオーバーした場合やクライアントが意図せず別サイトにアクセスしているケース、本番サイトからDRサイトへの切り替え、切り戻しの際の一時的な状況等で発生する可能性がある状況です。 調べたところ以下の事が分かりました。Exchange 2010 SP2 RU3で挙動が変更になっています。 - Exchange 2010 SP2RU2及びそれ以前 CASは自分の存在するサイト、DAGのアクティブサーバーの存在するサイトを意識しません。 - クライアントはちゃんとアクセスできていれば、Autodiscoverの値が変わってても無視します。 - 結果、CASとMBXの間がサイトまたぎのアクセスになってもそのままつながります。(つながっちゃいますの方が表現として正確かもしれません。) - Exchange 2010 SP2RU3以降 DAGのプロパティーのAllowCrossSiteRPCClientAccessが使えるようになります。規定の値は$falseです。 - AllowCrossSiteRPCClientAccessが$trueの場合(あえて設定変更した場合)以前のバージョンと同じ動きになります。 - AllowCrossSiteRPCClientAccessが$falseの場合、CASは違うサイトのMBXへのアクセスに関してはクライアントに「サイト間違ってるよ。正しいCASArrayはあっち」と教えます。 - クライアントは教えられたらきちんとプロファイルを更新します。 このことやこの周辺のことは以下のブログで解説されています。 RPC Client Access Cross-Site Connectivity Changes - Exchange Team Blog - Site Home - TechNet Blogs サイトをまたいだOWAのアクセスについて OWAとMBXの関係についても同様に考慮が必要です。OWAの場合にはユーザーがサイトをまたいでメールボックスを移動したとき等に一番効率的なOWAを伝える必要等も発生するのでその点からも確認が必要です。 ...

September 3, 2012 · 1 min · 胡田昌彦

管理者権限を持たないユーザーに管理者ユーザーのIDとパスワードを教えずに管理者権限を持たせる方法

ものすごく長いタイトルになってしまいましたが、今回は管理者権限を持たないユーザーにどのように管理者権限を持たせるか、というお話です。 実際の案件の中では以下のような状況が頻繁にあります。 - エンドユーザーの端末にソフトウェアをインストールさせたい、あるいは管理者権限が無いとできない設定変更をさせたい - でも、エンドユーザーのアカウントには管理者権限がない - エンドユーザーに操作をしてもらうことは可能だけど、管理者のID、パスワードは教えたくない(セキュリティ上の問題) やりたいことは簡単なんですけど、「エンドユーザーには教えずに」ということを実現させようと思うと中々大変です。 理想の状況 このようなことは頻繁にあるものなので、これらを簡単に実現するツールが全端末に仕込まれている状況が理想的です。これを実現する製品は多数存在しています。有名なところだと以下のようなものでしょうか。(私が仕事でよく扱っているものなので、偏ってるかもしれません。) - [System Center Configuration Manager : ホーム](http://www.microsoft.com/japan/systemcenter/configmgr/default.mspx) - [IT資産管理 ツール QND Plus | クオリティ](http://www.quality.co.jp/products/QND/) - [LanScope Cat6 トップページ](http://www.motex.co.jp/cat6/index.html) - [BigFix, Inc. | Faster, Smarter Systems Management](http://www.bigfix.com/) もっとも、これらの製品は総合的な管理ツールになっているので、今回話題にしていることだけをしたいような時に導入するようなものでもないです。お値段も結構しますし…、ということでこういった製品が導入されていない企業も数多くあります。特に日本企業には多い印象です。話で聞くところによると米国企業はほとんどなにかしら導入しているらしいですけれども。 Active Directoryのグループポリシーを使う方法 製品が導入されていない状況でこれを実現する方法として、まずADのGPOを使う方法があります。 ソフトウェアインストール 例えばソフトウェア配布なら「ソフトウェアインストール」を使うことができます。 ただ、これがなかなか曲者でして、以下の制限事項があります。 - インストールできるのはmsiパッケージのみ(setup.exeなどは無理) - 「コンピューターの構成」-「ソフトウェアインストール」で構成した場合ローカルのSYSTEM権限で実行される - 「ユーザーの構成」-「ソフトウェアインストール」で構成した場合ログオンユーザーの権限で実行される(今回の場合使えない) - インストールに成功したのか、失敗したのか、どの程度の進捗なのか等を管理者が把握できない 1.の制限により、そもそもこの機能では配布できないことが結構あります。2.の制限があるのでパッケージの置き場所はドメインユーザー以外もアクセス可能にしなくてはいけませんし、都合の悪いことにそもそもSYSTEM権限ではインストールが成功しないソフトウェアが結構存在します。そして、4の制限があるので、トラッキングができません。 というわけで、やってみてうまく動けばそれでいいのですが、結構なケースでこの方法が取れないことがあります。 スタートアップスクリプト 「ソフトウェアインストール」が使えない場合、あるいはそもそもソフトウェアインストールではない場合にはスタートアップスクリプトを使うこともできます。 これであれば自分でロジックを作り込めるのでsetup.exe等の実行ファイルであってもキックすることができます。また、成功、失敗等の把握はどうにでもできます。簡単にやるなら、例えばインストールログを共有フォルダに保存させるようなロジックにしてしまえばいいでしょう。 ですが、以下の制限事項は同じです。 - 「コンピューターの構成」-「ソフトウェアインストール」で構成した場合ローカルのSYSTEM権限で実行される - 「ユーザーの構成」-「ソフトウェアインストール」で構成した場合ログオンユーザーの権限で実行される(今回の場合使えない)コンピューターの構成に仕込んでみて、ローカルのSYSTEM権限のみでうまく行くことを祈ることになります。 このようにADを使う方法はどのパターンでも確実に成功するわけではありません。そして、そもそも論としてはADに参加しているクライアントでなければこの方法は取れないわけです。 その他の方法 他の方法としては以下のようなものがあります。どれも完全なソリューションではないですが・・・。 ...

October 21, 2010 · 3 min · 胡田昌彦

Active Directoryのパーティションとレプリケーションスコープ

Active Directoryを理解するためには、「パーティション」と「レプリケーションスコープ」の理解が欠かせません。簡単に解説してみたいと思います。 パーティション ActiveDirectoryのデータベースを保持しているのはドメインコントローラーです。そして、そのドメインコントローラーが持っているデータベースをより詳細に見ると、以下のように4つの大きなパーティションの種類があります。 パーティション名 格納されている情報 レプリケーションスコープ (複製範囲) Configuration Partition (構成パーティション) フォレスト、ドメインの構成情報 ActiveDirectory対応アプリケーションの構成情報 フォレストワイド Schema Partition (スキーマパーティション) ActiveDirectoryに存在するクラス、オブジェクトの設計情報 フォレストワイド Domain Partition (ドメインパーティション) ドメインに存在するオブジェクトの情報 ドメインワイド Application Partition (アプリケーションパーティション) ※2003から新規導入 ActiveDirectoryに情報を格納する用に設計されているアプリケーションの情報 色々 何かを操作するときに「この操作はどのパーティションに対しての操作なのか、情報はどこに保存されているのか」ということを意識できるようになるとActive Directoryのことがよくわかってきます。 特にアプリケーションパーティションを除く3つのパーティションは特に重要ですのでその用法含めてしっかり理解する必要があります。 具体的に見ていきましょう。 ADSIEdit 具体的にADの中を覗いていくためには、それ相応のツールが必要です。一番使えるのはADSIEditという、ADのデータベースを直接覗けるツールです。すべての情報が見え、すべての操作が行えるというある意味とても危険なツールです。 ADSIEditはSupport Toolsに含まれていますので、Support Toolsを導入しておきましょう。インストールCDやサービスパックCDにも含まれていますし、Webからダウンロードもできます。 - [ADSI Edit を使用した Active Directory 属性の編集](http://technet.microsoft.com/ja-jp/library/bb124152(EXCHG.65).aspx) - [Download details: Windows Server 2003 Service Pack 1 32-bit Support Tools](http://www.microsoft.com/downloads/details.aspx?FamilyId=6EC50B78-8BE1-4E81-B3BE-4E7AC4F0912D&displaylang=en) 起動方法としてはMMCを起動後、ADSIEditを組み込む方法もありますが、直接「ファイル名を指定して実行」から「adsiedit.msc」を起動してしまうのが楽だと思います。 このように起動すると、Domain, Configuration, Schemaの3つのパーティションに接続された状態でADSIEditが起動してきます。 以降の説明の中で"DC=test,DC=local"という記述が何度も出てきますが、これはこの画像を取得した環境のドメイン名(=フォレスト名)がtest.localであり、その名前が表れているものです。各自自分の環境の名前に読み替えてください。 Configuration Partition Configuration Partitionはその名の通り、構成情報が格納されています。Active Directory自身の構成情報や、Active Directory対応のアプリケーションの情報が入っています。 ...

March 16, 2009 · 1 min · 胡田昌彦

「イントラネットに繋がらない」 - ドメインサフィックス&Proxy編

今回は「インターネット」ではなくて、「イントラネット」に繋がらないというケースについて書いてみます。 今、Active Directoryで構成されたWindowsネットワーク(ドメイン名sample.lcoal)があるとして、そこにintraという名前のメンバサーバーがあり、そこでイントラサイトが稼働しているとしましょう。このときのURLは何になるでしょうか? - http://intra/ - http://intra.sample.local/ さて、どちらが正解でしょうか? 正解は、「どちらも正解」です。 「なんだ、それは」と思うかもしれませんが、これがなかなか奥深い話もあったりします。たとえば1のhttp://intra/というアドレスを使っている場合。クライアントの設定によってはつながったりつながらなかったりします。繋がる場合でも、名前解決の方法が異なったりします。ちょっと詳しく見てみましょう。 名前解決の手段は何か? まず、http://intra/というURLですが、実際にはintraというホストのIPアドレスを知らなくてはいけません。最終的にはTCP/IPで接続するわけですから。 名前解決の手段としては様々なものがある、という話は以前しました。 - 参考:[NETBIOS名とホスト名の違い](https://windowsadmin.ebisuda.net/2009/02/10/netbios%e5%90%8d%e3%81%a8%e3%83%9b%e3%82%b9%e3%83%88%e5%90%8d%e3%81%ae%e9%81%95%e3%81%84/) この場合intraを名前解決する方法は以下のパターンがあるわけです。 - hostsファイル(ホスト名) - DNS(ホスト名) - lmhostsファイル(NETBIOS名) - WINS(NETBIOS名) - ブロードキャスト(NETBIOS名) で、厄介なのが2に関してです。 ドメインサフィックス DNSとして考えたときに「intra.」なんていうホスト名はあり得ないわけです。本来は「intra.sample.local」です。なので「intra」を裏で「intra.sample.local」に変更してくれている仕組みが存在するわけです。 マイネットワーク→プロパティ→(対象NIC)→プロパティ→インターネットプロトコル(TCP/IP)→プロパティ→詳細設定→DNSタブ (なんてわかりづらい所にあるんでしょう…) - 「プライマリおよび接続専用のDNSサフィックスを追加する」 - 「プライマリDNSサフィックスの親サフィックスを追加する」 - 「以下のDNSサフィックスを順に追加する」 - 「この接続のDNSサフィックス」 そしてもう一か所あります。 マイコンピュータ→プロパティ→コンピュータ名タブ→変更→詳細 (なんてわかりづらい所にあるんでしょう…) - 「このコンピューターのプライマリDNSサフィックス」 - 「ドメインのメンバシップが変更されるときにプライマリDNSサフィックスを変更する」 これらの設定が"仕組み"になります。 勝手にドメインサフィックスが追加される理由 通常は以下のような流れで、勝手に適切なドメインサフィックスが追加されるようになっています。 - Active Directoryに参加する - 「ドメインのメンバシップが変更されるときにプライマリDNSサフィックスを変更する」が既定で有効であるため、ドメイン名(sample.local)が「このコンピューターのプライマリDNSサフィックス」として設定される - DNSを使った「intra」の名前解決の際に「プライマリおよび接続専用のDNSサフィックスを追加する」および「プライマリDNSサフィックスの親サフィックスを追加する」が有効であるので「intra.」だけではなくて「intra.sample.local」も検索される うまくいかないケース ここまでの説明が理解できれば、http://intra/ではアクセスできないケースがあることが理解できるのではないかと思います。 具体的なケースを示します。まず前提として以下のケースで、 - hostsファイルに記載されていない - lmhostsファイルに記載されていない - WINSが構成されていない - 対象サーバーと同一サブネットに無い(ブロードキャストでの名前解決はできない) これらすべてに加えて、以下のどれかの条件に当てはまる時です。 ...

March 11, 2009 · 1 min · 胡田昌彦

AI・テクノロジーの情報を発信しています

YouTube

AI・テクノロジーの最新トレンドを動画で配信中

note

技術コラム・深掘り記事を公開中