- 2018年4月9日
- ヨシダですけど
Active Directoryの構築、導入においてメリットやデメリット、注意点などを解説！
どーも、腹痛、腰痛、寝不足、運動不足、女に悩むヨシダです。
タイトル通り、Active Directory（以下AD）の構築方法や、導入するにあたっての注意などを解説していきますが、正直解説しきれません笑
だって、できることが多すぎるんだもん…
なので、ざっとになりますが解説します！
まずは、導入を考えている方は弊社のLP「アクティブディレクトリ構築サービス」をご覧いただきたい。
こちらに書かれているようなことに悩んでる方は、人が増える前にさっさとADを導入するべきです!!
お気軽にご相談ください。
設定できる機能の例
ADを導入したら設定できる機能の例は以下の通りです。
①パソコンやサーバーのID、パスワード管理
管理者がAD配下のPCやサーバーについてのID、パスワードを管理しやすくなり、セキュリティ的に非常によくなります。
②部署や役職ごとのアクセス権設定
ADサーバー内に全てのユーザーが管理できているため、例えばADサーバー内のファイルを操作できるのが、営業グループだけにしたい場合などに、アクセス権を設定することによって設定できるようになります。
こちらはよくGPOと勘違いしている方が多いです。
GPO(Group Policy Object)は名前にGroupが入っているので紛らわしいですが、各種Windowsに関する設定をADからクライアントへ配布・適用する仕組みであり、フォルダーにアクセスできるユーザーやグループを設定する機能ではありません。
ドメイン参加していない状態でクライアントPC上の「ローカルセキュリティポリシー」で設定できる内容と基本的に同じです。
「ローカルセキュリティポリシー」の設定をAD上で一括で管理して、対象のクライアントに一括で配布・適用できます。
例えば、「一般ユーザーで管理者フォルダにアクセスできないようにする」のは、クライアントPCでの対象フォルダーにおける設定同様、共有フォルダー配下の適当な設定対象のフォルダーを右クリック -> [プロパティ] -> [セキュリティ] から許可するユーザー・グループを指定する設定になります。
この設定は GPO とは呼ばず、ACL(Access Control List) 設定やアクセス制御リスト設定と言います。
許可するユーザー・グループの指定はAD上に作成したユーザー・グループを指定することができます。
ACL設定はADならではの機能ではなく、ADで一括設定という機能も下記のとおり微妙なところですが基本的に使いやすい形では提供されていません。
一応、GPOには対象マシン上の任意のフォルダーのACL設定を強制する設定が可能ですが、異なる対象マシンごとに、異なるパスや名前のフォルダーがあったり、フォルダーごとに異なるACL設定を行うには、個別にGPOを作る必要があり大変判りづらいためこの機能で設定することは普通はしません。
また、GPOはWindowsの設定を配布・適用する仕組みですので、配布・適用できる対象は、Windows Server OS,Windows Client OSのみで、QNAP, Linux, macOSなどはWindows OSではないため設定を配布・適用できません。
上記の理由と、ACL設定は各フォルダーに対する設定ですので、共有フォルダーのある各サーバー等のフォルダーごとに設定するのが一般的です。各マシンは、Windows Server, Windows 10, QNAP, Linux, macOSなどいろいろ考えられます。
ACLの設定で指定できるユーザー・グループは、そのOS上で認識しているユーザーとグループになります。NAS（QNAP）も連携することを想定した場合、具体的には以下のとおりです。
・ドメイン参加していないWindows Server or Client OS
対象クライアント上に作成してあるローカルユーザー・グループを設定できます。
AD上のドメインユーザー・グループは設定できません。
・ドメイン参加しているWindows Server or Client OS
ドメイン参加先のAD上のドメインユーザー・グループを設定できます。
・ドメイン連携設定していないQNAP
QNAP上に作成してあるローカルユーザー・グループを設定できます。
AD上のドメインユーザー・グループは設定できません。
・ドメイン連携設定しているQNAP
連携しているAD上のドメインユーザー・グループを設定できます。
QNAPを設定する場合は、QNAPの管理画面からフォルダーごとの読み書き許可するユーザー・グループを指定することになります。
フォルダーを共有しているかどうかの状態に関係しないフォルダーごとのACL設定(NTFSアクセス権とも呼ぶ)を想定した説明ですが、それ以外に共有フォルダー設定に対する「アクセス許可」設定もあります。
両方設定すると紛らわしいため、普通はフォルダーごとのACL設定で細かく設定します。
③ソフトウェアのインストールまたはアンインストール、利用制限、更新の管理
正直、ADのソフトウェアの管理は、msi形式など特定の形式にしか対応していなかったりと、かなり制約があるので実質あまり役に立たず、多種多様なソフトウェアを管理するには別途資産管理ソフトが必要になってきます。
④USBメモリなどメディア利用の管理
こちらもグループポリシーでクライアントPCに一括で設定できます。
具体的にはグループポリシーエディターから [コンピューターの構成] -> [管理用テンプレート] -> [システム] -> [リムーバブル記憶域へのアクセス] から書き込みアクセス権の拒否を設定することになります。
⑤パソコン設定全般の管理
例えば、「音声が出力されないように設定」や「IEを既定のブラウザに設定する」などのキッティング作業の負担を減らすことができます。
様々な細かい設定までできるので、非常に便利です。
⑥インターネットやプリンターなどその他機器との設定管理
AD連携機能がある機器であれば使用時の認証にADのユーザー情報が使用できるものがあります。
Windows共有によって別マシンから利用できる機器(例: プリンターなど)はADサーバーにドライバーインストールと登録して各クライアントに共有することで、使用時にサーバー側からクライアントに自動的にドライバーを配布することができ、クライアント側にドライバーをインストールしておく必要がないというメリットがあります。
また、機器のIPが変わった場合もADサーバーで共有しているデバイス設定を変更するのみでクライアント側は変更不要です。
デメリットはサーバーダウン時に使用できないことと、すべてADサーバー経由での出力となるため拠点を跨る場合非効率となります。
また、高機能なプリンターではWindows共有経由からの利用だと使用できる設定項目が少ない場合があります。
AD連携機能がない、Windows共有できない機器に関してはAD側と密に動作できことは特にないですが、実施するとしたらADのDNSサーバーに正引きを手動登録することで独自ドメインで参照できるようになります。
⑦Mac miniを使用すれば、Mac OSやiOSでもADを組める
弊社では、Macクライアントに対してもAD同様、制限制御するような構築をすることができます。
例えば、macOS/iOSのソフトウェア管理はProfile Managerで行うことで制限したりします。
⑧外部ソフトウェアとの連携（SS1やGsuiteなど）
こちらは、ソフトウェア側がADとの連携が可能な場合があり、非常に管理がしやすいようになっております。
また、SaaS（アプリケーションソフトウェア）においては、Azure ADと組み合わせることによって、SSOなどができるようになったりします。
⑨WSUSとの連携
WSUSを導入すれば、自動ログイン設定禁止、アップデートなどのWindows制御の実現が可能になりますが、導入して重くなるケースが多く、スペックも必要になってきます。
実は、アップデートなどに関しましては、グループポリシーの設定でWSUSなしでもいつ実行するかの設定は一括設定可能です。
強制的にアップデートするようにも設定可能です。
個別アップデート単位での制御が必要な場合はWSUSが必要になります。
でも、たいていすべて承認するので個別に制御することは滅多にないと思います。
また、WSUS の設定に関してはGPOで配信可能なため、後からでも全端末に設定を適用することが可能であります。
GPOでの設定については、Windows 10に関しましては大型アップデートの適用状況によって名称や設定内容が異なりやや判りずらい状況となっております。
基本的には大型アップデートの適用を制御するものとなり、下記のマイクロソフト社ブログにて現時点の状況が網羅的に説明されています。
参考：https://blogs.technet.microsoft.com/jpwsus/2017/09/06/dfr-upg/
GPO [コンピューターの構成] -> [管理用テンプレート] -> [Windowsコンポーネント] -> [Windows Update]以下の設定項目にて設定します。
必要スペックに関しましては下記のとおりです。
〜ADのみ〜
CPU: 2 Core 以上
メモリ: 4 GB 以上
ディスク: 100 GB 以上
〜WSUS導入時〜
WSUSは従来Microsoft社の推奨では300GB以上のディスクが必要だったのですが、2016年10月からMicrosoft社の方針変更によりマンスリーロールアップがリリースされるようになり事情が変わってきております。
参考：2016 年10月からのロールアップリリースに伴うWSUS運用の注意点
マンスリーロールアップは毎月それまでのアップデートをすべて含むアップデータが配信されており、WSUSはこのアップデートをすべて蓄積してしまい、お客様環境において、既にディスクを1.43TB消費している環境があります。
WSUS のマンスリーロールアップ対応が現状上手く実装されていないため、WSUS の導入はあまり推奨いたしません。
WSUS を導入する場合下記のスペックが必要です。
CPU: 4 Core 以上
メモリ: 8 GB 以上
ディスク: 2 TB 以上
⑩操作ログの取得
IISマネージャーからログの管理や設定を行うことができます。
しかし、ログオン時の認証やADやファイルサーバーのファイル共有に対する操作ログなど、AD関連サーバーへ接続して何かする操作は取得可能ですが、端末内だけで完結している操作のログは取れません。
例えば、どんなソフトを起動したかやどのサイトへアクセスしたかなどは取れません。
メリットとデメリット
次に、ADを導入した際のメリットとデメリットをざっと紹介します。
企業のメリット
- コスト削減
- 業務効率アップによる利益アップ
- 万が一のセキュリティ事故時に被害拡大を防止
- セキュリティ体制により安全な企業アピールができる＝顧客の信頼を獲得
管理者メリット
- パソコンやネットワーク機器、アカウント管理の負担を大きく軽減
- 1台ずつ手作業で設定する必要なし（リモートで一括管理）
- 作業ミスが減る
- 管理者の教育がしやすくなる（管理ツール利用により）
クライアントのメリット
- どのパソコンからでも自分のアカウントにログインできる
- たくさんのパスワードを覚える必要なし
- アップデートなど端末管理をする必要なし
- プリンターなど機器の利用がかんたんになる
- 使いたい機能を検索できる（両面印刷できるプリンターを探したい、など）
- ITに詳しくなくても使いやすい
- シングルサインオンによって一度の認証でローカル環境の操作がすべて可能にできる
１つめの「どのパソコンからでも自分のアカウントにログインできる」に関してですが、環境によってはいくつか注意点があります。
例えば、使用しているシステムやメールの利用がすべてブラウザやシステムのあるサーバーへのリモートデスクトップ接続先で完結しているのであれば別PCを利用されてもブラウザを立ちあげて該当システムへログインすれば使用できるかと思います。
各マシン内にユーザー設定があるこの構成を「ローカルユーザープロファイル」と呼びます。
システムやメールの利用が各端末内のソフトウェア(例:Outlookなど)の設定に依存しているようですと、個別の設定はログオンしているユーザーのユーザープロファイル領域(C:\ユーザー\ユーザー名\AppData\ 以下) に保存されているかと思います。
ユーザープロファイル領域のうち、C:\ユーザー\ユーザー名\AppData\Roaming\ 以下に関してはADの設定にて各アカウントごとに「移動プロファイル」を設定すると、C:\ユーザー\ユーザー名\AppData\Roaming\ 以下のファイルはクライアントのディスクではなくサーバー上に保存され、ログオン毎にログオンしたマシンへダウンロード、ログオフ時にサーバー上にアップロード保存されます。
そのため、違うマシンであっても同じ設定ファイルが参照され同一環境を使用することができますが下記の注意点があります。
- ソフトウェアのインストールパスが全マシン同一であること
マシンA は C:\Program Files\Software1、マシンB は C:\Program Files\Application1 など違うパスだと違うマシンを使用時にショートカットや設定ファイルなどがうまく動作しません。 - 移動プロファイルは毎ログイン・ログオフごとにダウンロード・アップロードするため、移動プロファイル内のデータ容量が大きいとログオフ・ログオンが非常に遅くなります。また、容量が小さくても通常のローカルプロファイルより遅くなります。
お使いの環境の C:\ユーザー\ユーザー名\AppData\Roaming\ 以下のサイズをご確認いただき、それが毎回転送される時間をご想定ください。 - 移動プロファイルはWindowsファイル共有が可能なサーバー上(例:ADサーバー2台のうちのどちらか)に保存されます。基本的にどれか1サーバーを指定するため、そのサーバーがダウンしている場合、該当アカウントでログオンしようとしても移動プロファイルがロードできなくなり、移動プロファイルを保存したサーバーがSPOFとなります。
- 同じユーザー名を異なるPCに同時ログオンすると移動プロファイルが環境によって壊れる問題があります。
2. の移動プロファイルが大きい場合に毎ログオン・ログオフの時間を短縮するために、「フォルダーリダイレクション」を組み合わせることもできます。
これは毎ログオン・ログオフごとに移動プロファイル内のファイルを転送するのではなく、ログオン後、該当ファイルを触るときに透過的にサーバー上のファイルを読み込む方式です。
この方式の場合、ログオン・ログオフ時間は短縮されますが、該当ファイルを読み込み・編集する度にサーバーへのアクセスが生じ、ファイルサイズが大きいと毎回遅い処理となります。
また、移動プロファイル同様、フォルダーリダイレクション先のサーバーがSPOFとなります。
移動プロファイル・フォルダーリダイレクションは便利な機能ですがその分、構成の複雑度やSPOFが増します。
シンプルにローカルユーザープロファイルで運用可能であればそちらをお勧めします。
デメリット
- 制限が強すぎると、管理者の許可がいるようになってしまう
- ログの確認で誰が何をしたかがわかるので、クライアント側が心理的または倫理的にも社内に良くない結果をもたらすかもしれない
- 初期の設定で手間と金額がかかってくる
- 管理者のパスワード窃取やシステム脆弱性への攻撃でActive Directoryを乗っ取られてしまうと、社内すべてのパソコンも乗っ取られてしまいとても危険
- Active Directoryの豊富な機能を管理者が使いこなすのは難しいかもしれない
ADドメイン名の注意点
ADを構築する際に、ADドメイン名を決めなければいけないのですが、ここにもひとつ注意点がございます。
ADドメイン名にしたサブドメイン配下は、すべてADの内蔵DNSサーバーで管理されます。
例えば、「corp.XXX.co.jp」にした場合、「CORP」が省略名(NetBIOS ドメイン名)になります。
コンピューター名「AD01」は「AD01.corp.XXX.co.jp」となり、正引き・逆引きがAD内蔵DNSサーバーに登録され、ドメイン参加しているクライアントからも正引き・逆引きできるようになります。
また、「CORP\ユーザー名」といったユーザー名表記になります。
「CORP\」は通常意識する必要なく、ログオン時はユーザー名のみの入力です。
自社名の省略表記や意味を持たせず「corp」にしたりするのが一般的です。
なお、ADドメイン名は後から変更するとクライアントのドメイン参加がすべてやり直しになりますのでご注意ください。
また、注意としてドメイン名はお客様保有の実在ドメインのサブドメインを強く推奨いたします。
例えば.localは古い資料等においてよく例としてあげられておりますが、現在は下記の2つの理由により推奨されておりません。
1. .localはMacOS環境において予約ドメインである
MacOS環境において、.localは予約ドメインに使われてしまっているため、将来もしADの認証情報をMacOS環境においても連携する場合、正常に動作しない機能が発生いたします。
・サーバーと内部ドメインに名前をつける必要がある理由
https://technet.microsoft.com/ja-jp/library/cc626155(v=ws.10).aspx
・Macが参加するADのドメイン名で.localを使わないでください。
https://www.picturecode.co.jp/faq/dot-local-domain/
2. 所有しないドメインを使用すると将来的に存在ドメインを衝突する恐れがある
現在、ドメインは新gTLDにより任意のトップレベルドメインを作成できるため、自社で保有していないドメインを使用した場合、将来的にそのドメインが使用された場合、ドメイン名が衝突し、そのサイトへはアクセスができなくなります。
・新gTLDに伴う.home/.corp問題、オープンリゾルバーなど2013年のDNS総ざらい
https://internet.watch.impress.co.jp/docs/event/626241.html
クラウド環境でのAD
お客様の中でよく相談を受けるのは、社内にADサーバーを設置するか、クラウドに設置するかになってきます。
基本的には社内にADサーバーを設置することをオススメしていますが、社内にサーバーを設置することがないので、クラウドでやりたいという方ももちろんいます。
ただ、クラウドで構築するといくつかメリットやデメリットがあります。
AWSでやりたいというお客様が多いので、AWSの場合で考えてみます。
AWSのEC2にWindows Server 2016を立てる場合
クライアントとADの通信はSMBプロトコルが使用されますので、社内とクラウド側のネットワークはローカルネットワークで通信する必要があり、そのために拠点間VPN接続が必須となります。
拠点間VPN接続にはAmazon VPCと社内VPNルーターを接続する形態となります。
この際、Amazon VPCとの接続がベンダーサポートが保証された機器が推奨となります。
また、VPN接続となりますのでネットワーク帯域が重要となります。
ドメインログオン時の認証に関しては、認証処理のため大きな帯域は必要としないため、問題になることはまずありません。
しかし、AD機能のログオンスクリプトなどによりサーバーからファイル転送を行う処理を含み場合は帯域の影響を強く受けます。
AWSサービスにおけるネットワーク帯域は使用するEC2インスタンスタイプにより定まっております。
Amazon VPC自体の帯域は常に水平スケーリングされた最高速度が維持されるため、それより遅い EC2インタンスのネットワーク帯域に依存します。
EC2インタンスのネットワーク性能は数値しては公表されておらず、「Low」「High」「10G」といった種別表記で示されております。
各種別ごとに計測された参考値として例えば、VSR800はVPNスループットが最高320Mbpsとなっておりますので、「Moderate(low)」 以上のインスタンスタイプであればネットワーク帯域は問題となりません。
なお、実際にはUTM機能の有効・無効によりスループットはさらに遅くなること、インターネット回線自体の速度によっては最高速度がその速度に律速するなどがあります。
また、それ以外のシステムもAWSに移行したいとうお客様も多いですが、EC2ではネットワーク速度同様、I/O速度もインスタンスタイプによって最高速度が制限されています。
参考：https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-ec2-config.html
そのため、I/Oが重いシステムの場合は上記も考慮する必要があります。
その他、システムへWebアクセスやリモートデスクトップ接続するために、AD同様、ネットワーク速度を考慮する必要があります。
バックアップ等に関してはオンプレ同様AWS上に何らか実装する必要があります。
Amazon RDSなどのマネージドサービスを利用される場合は、あらかじめ冗長構成を選択できますので冗長構成を組んだうえでデータのバックアップ等を設計する必要があります。
AWSのAWS Directory Serviceを使用する場合
AWS Directory Serviceを使用する場合は別途EC2インスタンスを手動で作る必要がなく、裏側で勝手に専用のインスタンスが作られて使えるようになります。
こちらも拠点間VPNを組む必要性があり、AWSへの月額使用料が発生します。
料金は、その裏で動いているEC2インスタンス代(2台分)+αが含まれています。
パスワード管理等のAD機能だけならEC2にWindowsServerを立てなくてもAWS Directory Serviceだけで問題ありません。
しかし、GPOを使いたいとなった場合にはAWS Directory ServiceはまだWindows Server 2012 R2ベースのため、Windows 10特有のGPO設定ができません。
Windows 7の設定と共通のものはWindows 10端末にも設定を適用できます。
Windows 10特有のGPO設定はWindows Server 2016からデフォルトサポートで、Windows Server 2012 R2には別途ADMXファイルをインポートすれば使えますが、AWS Directory Serviceにはそのインポートする機能が未サポートで使えません。
また、AWS Directory ServiceはAD機能しか使用できないため、他のシステムのインストールやリモートデスクトップ接続でできません。
メリットとしては、マネージドサービスのため運用が容易なのと、ユーザーCALが不要ということです。
ユーザーは最大5,000ユーザー、別途、ユーザー+グループ+コンピュータの合計で最大30,000まで登録できます。
かなりの数のユーザーがいると、ユーザー CALに相当費用掛かるため、AWS Directory Serviceを使用するのもありですね。
ユーザー CAL 不要は正確には下記のとおり上限があります。
https://aws.amazon.com/jp/directoryservice/faqs/
Q: AWS Microsoft AD がサポートしているユーザー数、グループ数、コンピュータ数、およびオブジェクトの総数は?
AWS Microsoft AD (スタンダードエディション) には、1 GB のオブジェクトストレージが含まれます。この容量により、最大で 5,000 ユーザー、またはユーザー、グループ、コンピュータなど 30,000 ディレクトリオブジェクトをサポートできます。AWS Microsoft AD (エンタープライズエディション) には、17 GB のディレクトリオブジェクトストレージが含まれ、最大 100,000 ユーザーまたは 500,000 オブジェクトをサポートできます。
クラウドはクラウドでメリット、デメリットがあるのがわかったと思います。
最後に
上記の説明はまだまだADの一部で、代表的なところを抜粋して解説しました。ADを導入しようと考えている方は、メリットやデメリット、注意点などが上記のようにあるのがわかったと思いますが、ADのことを詳しく知らない方は正直何を言っているのかわからない部分もあるでしょう。
そんな方はお気軽にレオンテクノロジーのお問い合わせから吉田までご連絡くださいませ。
ありがとうございました。
