・前提
社内SEとして必須技術のADについて机上の知識しかないため以下の講座を用いてハンズオンで学習する
この際、AWS上にADの評価環境を作成しハンズオンで学習していく
AWSで作って学ぶActive Directoryメンテナンス基礎と実践 | Udemy
ADの基本機能について整理する
ADのドメインサービスとはユーザとコンピュータを一元的に管理するサービスのことで、管理するサーバのことをドメインコントローラという
もしADがないとユーザの認証情報はPCごとに必要になり管理が大変→ADを使うとPCにユーザ情報が不要になる点もメリット
また、ADで管理されたPCのことをドメインに参加したPCということもある
ユーザとPCはOUとコンテナという入れ物をツリー上にして格納して管理している
以下ADの基本機能
- ユーザ認証
- ユーザ情報検索機能(姓や名や電子メールや役職など検索可能)
- 権限管理→権限の許可・拒否に関するセキュリティグループをフォルダにアタッチして
- 設定管理→GPOによってパスの長さの設定やコントロールパネルの起動禁止など設定可能
ADの関連システムとAD障害時の影響範囲
ADと名前解決について、ドメイン参加端末はユーザ認証時DNSを使用することでDNSコントローラを見つける
具体的にはドメイン参加端末がDNSサーバにDCの名前解決を依頼するわけであるが、一般的にはDCがDNSサーバを兼ねるのでDC停止時DNSサーバも停止する可能性があることには留意されたい。また、NTPサーバも兼ねている場合もあるのでDNS同様DC障害時、時刻が同期できない可能性もある
また、ドメイン参加端末とDCの時刻が5分以上ずれるとADのユーザ認証が出来なくなるのでその点にも注意
AD認証は様々なアプリ(FS,ジョブ実行,バックアップ実行,SQLサーバなどのサービス起動,業務アプリなど)に利用されているのでDCが障害時様々なアプリに影響が及ぶ
ADの冗長化とSPOFについて
DCはマルチマスタ構成で冗長してユーザやGPOなどのレプリケーション対象を同期する
レプリケーション間隔はデフォで15秒、サイトを跨ぐ場合はデフォで3時間
- サイト→ドメインメンバが優先的に利用するDCを制御する機能で、東京や大阪などで分ける運用などがある
- ドメイン→PCとユーザの管理単位でtest.localのように.を付けて名前管理→フォルダのツリー構造のように管理
- フォレスト→ドメインの集まりでフォレスト内のドメインは互いにアクセス可能
- 操作マスター(FSMO)→フォレスト/ドメインの内一台のDCのみが持てる役割があり、その機能を持つDCのこと
- 以下、操作マスタの5つの役割
- ①スキーママスタ→ユーザのプロパティ(姓・名など)の定義→windowsサーバのバージョンアップ時などに使用
- ②ドメイン名前付けマスタ→フォレストに対するドメインの追加・削除の管理
- ③RIDマスタ→各ユーザが持つSIDの基になるRIDを生成
- ④PDCエミュレータ→時刻同期の最上位、パスワード情報の最新管理
- ⑤インフラストラクチャマスタ→ドメイン間でのセキュリティグループメンバ整合性管理
FSMO停止時に以下のような大きな変更がなければしばらくは運用が継続できるが早めの復旧が推奨される
ADのバージョンアップ、フォレストへのドメイン新規作成、ユーザの大量作成
ADをAWS上に構築してハンズオンする
今回構築する構成はVPC内にドメインコントローラとドメインメンバを作成してインターネットGWをエンドポイントに設置してローカルPCからリモートアクセスする構成で、ログイン後色々な設定を編集する
※今回やることはユーザメンテナンスとグループポリシーメンテナンスでADドメインサービスのインストールとドメイン参加は実施しない
まずは、例によってcloudformationで準備頂いた構成を展開する
その後ドメインコントローラのEC2から接続を選択してRDPクライアントからRDPでログオンする
ログオン成功！
ハンズオン(ユーザメンテナンス)
ログオンしたのちスタートメニューからwindows管理ツールを検索し「Active Directory ユーザーとコンピュータ」を選択→以下の画面がユーザを作成・削除したりする管理画面になる
上記、corp.localがドメイン名でOUはグループポリシーを割り当てることが出来、新規作成もできるが、コンテナは出来ない違いがある
なので今後はOUの中にユーザを作成していくことになる
以下ではOUを作成し、その後ユーザ作成し、メンバサーバへのユーザのRDP権限を付与しメンバサーバへRDP接続する
corp.localを右クリックして新規作成からOUを選択し、同様にユーザを作成
作成完了
ユーザも作成完了
続けて、RDP接続の権限を付与するためにADメンバにログオン
その後スタートメニューを右クリックして「コンピュータの管理」を選択して「ローカル ユーザとグループ」を選択し「グループ」からRemote Desktop Usersを選択
その後、追加からユーザ名を追加し「名前の確認」を選択してパスワード入力して認証が通れば以下の通り
そして、メンバサーバからログインしてみる
ログイン時に[その他]から[別のアカウントを使用する]を選択して認証情報を入力
ログオン成功！
続けて、ユーザ名を変更してログオンしてユーザとプロファイルの関係を理解する
流れとしてはプロファイルデータを確認し、テストファイルを作成→ユーザ名を変更→変更ユーザからメンバサーバへログオン→プロファイルを確認
プロファイルとはユーザ個別のデータ群のこと
プロファイルデータは以下のようにエクスプローラのCドライブ直下ユーザから確認できる(今回でいえばtest1)
早速DCに移動して作成したユーザ名(今回でいえばtest1)を変更する
これをtest2にしてみる
変更完了
メンバサーバから再度ログオンしてみる
するとtest1で事前に作成したtestファイルが残っている→test1からプロファイル情報を引き継いでいることが分かる
プロファイルのフォルダ名がそのままであることから、ユーザ名とプロファイルは直接関係していないことが分かる
ユーザとプロファイルを紐づけているのはユーザ名でなくSID
SIDの確認方法はコマンドプロンプトから[whoami /user]を入力すればよい
→つまり、ユーザを削除してしまうとSIDが変わってしまうのでプロファイル情報を復元できないということ→嫌なら以下のように無効化しておく
以下、ユーザの無効化・有効化・削除について
例によって[AD ユーザとコンピュータ]から対象のユーザを右クリックして上記操作を選択できる
ユーザとコンピュータの移動について
通常のwindowsのコピペ(ctl+X,V)でできる
保護されたOUの削除方法について
保護を外してから削除することになるので表示]タブから[拡張機能]を選択して[プロパティ]の[オブジェクト]タブから[誤って削除されないようにオブジェクトを保護する]のチェックを外して削除
セキュリティグループと共有フォルダの作成について
以下、ユーザ名を元に戻してセキュリティグループを作成(test1をグループに所属させる)してDCに共有フォルダを作成しメンバサーバからtest1で共有フォルダにアクセスしていく
作成したtestOU内で右クリックして新規作成からグループを選択して以下のようになる
今回グループのスコープにグローバルを選択したが、フォレスト内に複数のドメインがある場合などはドメインローカルを選択したりする
そして、グループを選択してメンバタブからtest1を選択して追加する
次に共有用のフォルダを作成し右クリックしてプロパティを選択し詳細な共有を選択
その後アクセス共有から権限をフルコントロールにチェックする
続けてセキュリティタブに移動して編集を選択してオブジェクトを入力して追加を選択
そして付与したい権限にチェックする
そして、確認のためメンバサーバへログオンしてwin+Rで検索ウィンドウを出して「\\[DCのホスト名]\[DCで設定した共有フォルダ名]」を入力
DCで作成した共有フォルダの表示に成功！
以下、実務で使えるユーザ出力について
ユーザの情報を変更した際、前後で不要なことをしていないというエビデンスを作成するために実施するもので作業の前後でユーザとコンピュータのプロパティ情報を全て出力しておくというもの
今回は特定のユーザの姓・名を変更してその前後のプロパティ情報を出力する段取りで行う
まず、DCのコマンドプロンプトから
csvde -u -f [出力ファイル名].csv #プロパティ情報を出力
エクスポート完了！
そしてDCで設定変更
そして再度エクスポート
以下のようにcsvファイルが作成されていることが分かる(しかし、上記のように設定前後で同じファイル名を指定してしまったので上書きされてしまった、ここは要注意だ)
※大量のユーザ作成やユーザ編集はPowerShellを使用するのがよい→シェルファイルによる実行だとcsvファイルを使えるのでスマート
ハンズオン(グループポリシーメンテナンス)
グループポリシーの管理ツールは[windows管理ツール]から[グループポリシーの管理]を選択
上記、今まで表示されていたコンテナ(OU以下のUsersフォルダなど)が表示されていないが、コンテナにはグループポリシーを編集できないので当然
また、ポリシーの適用範囲について、上記Default Domain Policyについてはドメイン内(上でいえばcorp.local内)の全てに適用され、Default Domain Controllers PolicyについてはDomain ContorollersOU内全てに適用される→ということでDomain ControllersOUには両方のポリシーが付いてしまうが合算した内容が適用される→しかし、矛盾する内容が設定されている場合は適用の優先順位があり以下のように確認可能
※優先順位はOUからツリー的に近いほうが優先される
ポリシーの内容も確認可能
GPOについて、上記のようにユーザの構成とコンピュータの構成という二種類に適用が分かれているが、適用対象はそのままユーザの構成ならユーザに適用されるが、ユーザの構成の適用タイミングはログオン時でコンピュータの構成の適用タイミングはコンピュータ起動時
GPOに記載する内容としてはユーザの構成のみを記入するパターン(適用するユーザのOUに適用)とコンピュータの構成のみを記入するパターンと両方を記入する(適用するユーザ・PCの最上位のOUに適用)パターンがある
以下、グループポリシーの新規作成とリンクしてその後結果を確認する
グループポリシーの作成は直観的に右クリックで作成可能
作成したら右クリックで編集していく
今回は以下のデスクトップの壁紙を変更していく
設定していく
適用したいOUで右クリックして既存のGPOのリンクを選択してリンク
メンバサーバからログオンすると壁紙が変わっている
もし適用されていなければ以下のコマンドで強制適用する
gpupdate /force以下、基本設定の用途について
基本設定で設定したのはそれ以外と異なり、ユーザの方でも設定を変更できるので、運用の効率化のために使用することが多い
また、基本設定では対象を絞って設定することが出来るので便利で具体的には以下の通り
上記でコンピュータ名を選択すればホスト名で対象を絞れる
グループポリシー全体の適用結果を確認する方法はコマンドプロンプトを管理者権限で実行して以下を入力
gpresult /h test.htmltest.htmlファイルを確認すると確かに内容を確認できる
ここでグループポリシーオブジェクトの欄を確認して適用されているGPOを確認する
※ローカルグループポリシーよりGPOの方が優先順位が高い
グループポリシーを本番環境で適用したいとき、開発環境で評価を重ねた上で適用するべきで、
開発環境で評価→本番環境でOUを新規作成してその中で評価→評価したGPOを正規のOUにリンクというステップを踏むとよい
開発環境で評価したオブジェクトを本番環境に持っていくときにGPOのバックアップ/インポートをすることができる
段取りとしてはバックアップ用のフォルダを作成してバックアップしたいポリシーを右クリックしてバックアップを選択してバックアップ用のフォルダのパスを選択するだけ
インポートの方法は空のポリシーを作成してそのポリシーを右クリックして設定のインポートを選択してコピーしたポリシーのファイルを選択するだけ
アカウントポリシーは一つのドメインに一つしか設定できないが、複数のパスワードポリシーを設定したいときはPSOを設定する(ユーザ・グループ単位で適用できる)
PSOの作成方法はwindows管理ツールからActive Directory管理センターを選択してドメイン名を選択後Systemというものを選択してPassword Settings Containerを選択して新規→パスワードの設定→設定内容を編集していく→※この画面で適用先を選択して任意のユーザ・グループを選択する
コンピュータアカウントパスワードについて、ドメインメンバはコンピュータにもパスワードを利用しており、パスワードが異なるとログオン不可でパスワードは30日ごとに更新されるのでPCでバックアップを取ったのに30日以上またいでパスワードが更新されてしまっていたらリストアしてもログオンできなくなってしまうので、セキュリティオプションからコンピュータアカウントパスワードの定期的な変更を無効にしなくてはならない
フォレストはドメインの集まりで、フォレスト内のドメインは自動的に信頼関係が結ばれドメイン間でユーザが参照できたりするなど