Ad

シリーズ記事の16個目です。M365フルクラウド環境を検証目的で構築しています。下記の記事も合わせてどうぞ！ Windows10をAzure ADに参加させる！【M365フルクラウド環境検証 その1】 | Microsoft Cloud Administrators- Azure ADにドメインを追加してユーザーIDをわかりやすくする！【M365フルクラウド環境検証 その2】 | Microsoft Cloud Administrators- M365 E5検証ライセンスを申し込む【M365フルクラウド環境検証 その3】 | Microsoft Cloud Administrators- Intuneへの登録を行う【M365フルクラウド環境検証 その4】 | Microsoft Cloud Administrators- Windows10のデバイス構成プロファイルを作成して割り当てる！BitLockerでディスク暗号化【M365フルクラウド環境検証 その5】 | Microsoft Cloud Administrators- コンプライアンスポリシーを作成して割り当てる！【M365フルクラウド環境検証 その6】 | Microsoft Cloud Administrators- 「条件付きアクセス」で「ベースラインポリシー」を設定する！【M365フルクラウド環境検証 その7】 | Microsoft Cloud Administrators- 条件付きアクセスポリシーを設定してMFAとポリシー準拠デバイスを必須とする！【M365フルクラウド環境検証 その8】 | Microsoft Cloud Administrators- Microsoft Defender ATPを実装する！【M365フルクラウド環境検証 その9】 | Microsoft Cloud Administrators- Office Pro PlusをIntuneから配布する！【M365フルクラウド検証環境 その10】 | Microsoft Cloud Administrators- Exchange Onlineのドメイン設定とメール配送の挙動【M365フルクラウド検証環境 その11】 | Microsoft Cloud Administrators- AutoPilotを構成する！【M365フルクラウド検証環境 その12】 | Microsoft Cloud Administrators- iOS用の接続構成を設定する！【M365フルクラウド環境検証 その13】 | Microsoft Cloud Administrators- Android用の接続構成を設定する！【M365フルクラウド環境検証 その14】 | Microsoft Cloud Administrators- Windowsストアアプリを強制配信する！【M365フルクラウド環境検証 その15】 | Microsoft Cloud Administrators 今回はセルフサービスパスワードリセットを構成します。 ...

オンプレミスの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を利用して全てのものを利用可能とするのが最も便利でセキュアで運用コストが低いから」です。この点はもっと説明が必要ですのでまた今後のブログエントリで解説していきたいと思います。

日経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を使ったシステムをまず第一に考えて行きたいですね！ ...

今日は桃の節句ですね。さて、今週のトピックスです。 - Announcing preview of Azure HDInsight 3.6 with Apache Spark 2.1 | Blog | Microsoft Azure 1 user Get credits that enable: 4 Windows or Linux Virtual Machines 24 x 7 for a month And much more… Learn more [azure.microsoft.com ](http://b.hatena.ne.jp/ebibibi/?url=https%3A%2F%2Fazure.microsoft.com%2F) - テクノロジー - あとで読む - [](http://b.hatena.ne.jp/ebibibi/)ebibibi w, b, azure 27 clicks 2017/03/03 - Azure Command Line 2.0 now generally available | Blog | Microsoft Azure 1 user Back in September, we announced Azure CLI 2.0 Preview . Today, we’re announcing the general availability of the vm , acs , storage an… ...

前回の記と事を書いて、「続きはその2で」…と言いながら４年以上の月日が流れてしまいました。4年…あまりにも長い月日なので、結局当時のことはもう通用せず意味が失われ……てはまったくいないのが現在です。 今でもきちんとActive Directoryを理解することは難しいですし、そのなかでDNSの扱いの理解が難しいことも変わりません。そもそもちょっとたったら知識が陳腐化してしまうようなことはどうでもいいことですしね。 というわけで、4年以上の歳月をあけて「その２」です。 でも、随分間が空いてしまったので自分でも何をその２で書こうとしていたのかよく覚えておりませんが…、とりあえず前回予告したとおりいくつか典型的なパターンを挙げてみましょう。 社内の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」で…。（いつになることやら。）

サービスロケータ、名前解決の仕組みからADを捉える 前回は認証、名前解決の視点からADを見てみましたが、今回はサービスロケータ、名前解決の視点からADを見ていこうと思います。 ※注意事項 以下の事項に関しては、ここで述べるには複雑すぎるので詳しくは述べません。 通信に利用するプロトコル(NetBEUI、TCP/IP） インターフェース（NETBIOS、NETBIOS over TCP/IP) NETBIOS名とホスト名 WINSサーバとDNSサーバーの違い Windowsブラウジングの仕組み スタンドアロンPCの場合 スタンドアロンPCの場合には、特にサービスロケーターや名前解決の仕組みは必要ありません。 複数PCの場合 複数PCの場合には、どのPCに何が入っているかなどに関しては全て個人の記憶なりで管理します。特にPCの仕組みとしては組み込む必然性はありません。 ワークグループの場合 ネットワークが利用できる環境では、通信をするために名前解決が必要ですし、共有リソースにアクセスする必要性も出てきます。 共有リソースの場所は記憶で管理し、名前解決はブロードキャスト(同一セグメントのみ)、ローカルファイル(hostsファイル、lmhostsファイル)を利用します。 どのPCがワークグループに参加しているか、という点に関しては、ブラウズリストを利用します。このブラウズリストに関しても、ブロードキャストやローカルファイルを利用して取得します。 NTドメイン NTドメインにおいては、アカウントデータベースも共有リソースとなります。つまり、ログオンする際にはドメインコントローラーを知り、通信を行う必要があります。 では、ドメインコントローラーの場所をどのようにしてクライアントは知ることが出来るのか? これは複数の方法があり、(同一セグメントであれば)ブロードキャスト、各PCのlmhostsファイルに記述するといった方法もありますが、本命はWINSを利用する方法になります。 WINSの場所自体は、各PCに静的に設定します。 WINSによって提供されるもの WINSの役割は複数ありますが、以下のものを提供します。 -ドメインコントローラーの場所 -NETBIOS名とIPアドレスの組(名前解決) -ブラウズリストの場所 WindowsNT時代にはWINSがサービスロケーター、名前解決の手段として一般的に利用されていました。 (余談)ちなみにNetBEUIプロトコルを利用しているかぎりにおいては、このあたりは全てブロードキャストで解決します。なぜならNetBEUIにはネットワークセグメントという概念はなく、全てのPCに対してブロードキャストが届くネットワークしか想定していないからです。 WINSサーバーの問題 WINSサーバーには以下の問題がありました。 オブジェクト数、データ構造 WINSのデータベースはフラットな構造であったので、必要なレコード、つまり全てのドメインの全てのレコードを保持する必要がありました。 (余談)WINSの場合、対象サーバーが保持しているレコードは名前解決できるし、保持していないレコードは名前解決できないという動きでした。自分が保持していないレコードだった場合には保持しているはずのWINSサーバーに問い合わせて、答えを返す・・・というようには動きません。 複製の管理 WINSサーバーが複数存在する環境では、WINSサーバー同士でレコードを明示的にPushしたり、Pullしたりする必要がありました。つまりWINSの複製のトポロジを管理者が管理しなくてはならず、しかも色々と複製にまつわるトラブルが多かったそうです。 ログオンするDCのコントロール NTドメインの時代にはログオンするDCはWINSサーバーから取得していたので、ログオンするDCが名前解決に依存してしまっていました。このため、最悪の場合には、近くにあるDCを利用せずに、ネットワーク的に非常に遠いDCを利用してしまうこともあったそうです。 公開できるリソースの種類 サービスロケーターとしてWINSを捉えた際にWINSが扱えるものはDCの場所とブラウズリストの場所に関するものだけだったので、たとえば共有プリンタの場所などは扱えず、UNCパスを利用しなくてはなりませんでした。 ADでの改善 ここまで見てきたWINSの問題点を改善するために、ADでは名前解決にDNS、サービスロケーターとしてもDNS,ADを利用するように変更されています。 オブジェクト数、データ構造 DNSを採用することで、ドメインごとに管理を分散できるようになりました。 複製の管理 名前解決に関してはDNSを採用したため、WINSの構成を行う必要がなくなりました。それに加えて、ADのDNSでは「AD統合ゾーン」という仕組みを採用し、DCのレプリケーションにDNSのレコードも含められるようになっています。(通常の標準プライマリ、標準セカンダリとしても構成可能) これによって、管理者は名前解決のための複製管理とDCの複製管理を分けて考える必要がなくなりました。 ログオンするDCのコントロール ADでは「サイト」という概念が導入されて、ログオンするDCはまずはサイト内を利用する・・・というように管理者が細かく管理できるようになりました。DCの場所はDNSのSRVレコードで示されています。 公開できるリソースの種類 ADでは、ユーザー、グループ、共有フォルダ、共有プリンタなどのリソースに関しても「ADに公開」することが出来るようになりました。

今頃ADの勉強会?という声も聞こえてきそうですが、新人はまったく別のことが専門だった人がほとんど・・・というのが今のSIerの実体で、需要は毎年あるのです。 3日かけて、AD勉強会をやりました。ものすごく疲れた・・・。 ちょっとは達成感があるけど、自分の技術的なスキル向上にはまだ全然やくにってない！人に話をする練習にはちょっとはなってるかな。 まだまだこれからだのぅ。

会社でだれにいわれたわけでもないけど、「やるぞ」ということで、ADの勉強会をしています。希望を募ったら、20人くらい集まったので、3日に分けて、まずは基本的なところから。今日は初日であんまりうまく出来なかったけれども、明日もあさってもあるから、もうちょっとうまくやろうっと。 でも、こんなことやって自分の仕事時間増やしても、特になにも得はないのです。もうちょっと何か文句でもいいからいってくれるといいんだけど・・・。

初めて高橋メソッドをつかって、上のエントリに関するPPTファイルを作ってみました。PPTファイルというところがダサいけれども・・・。 こんなのでいいのかな？まあいいのかな。 {{ul_display 0}}