TEMTECOMAI ORTHOSTATIC HYPOTENSION

元ダメプログラマで現ダメ中間管理職の駄文

カテゴリ: Active Directory

Windows 10 (1803) になった途端に BitLocker 暗号化が実行されなくなった

Active Directory に参加させた PC を所定の OU に移動させ、BitLocker に関するグループ ポリシー オブジェクトを食ったのを確認し、その PC にて BitLocker 管理ツールからシステム ドライブを暗号化しようとすると
Active Directory ドメイン サービス スキーマは Bitlocker ドライブ暗号化を実行するように構成されていません。 システム管理者に問い合わせてください。
のようなエラーが発生。
GPO で 「AD DS にオペレーティング システム ドライブの回復情報が格納されるまで BitLocker を有効にしない」 にしてあるので、「AD に格納できる準備ができてないから暗号化をしなかった」 という事でしょう。
いや、Windows 10 (1709) までは正常に暗号化されているわけで、何かがおかしい。

とりあえず成功した

対象 PC のローカル Administrators に所属している、Active Directory 側のユーザーで作業をすれば成功しました。
TechNet の US フォーラム BitLocker on Windows 10 1803 というスレッド、というかそこから飛んだ先にある Reddit の Bitlocer with AD-stored keys bloken on new 1803 installs? というスレッドのなかでサラっと成功談が書いてありましたね。

それまでの作業方法はというと、ます PC の Administrators に参加させたローカル作業用アカウントで作業を進めていた。
たまに AD 側への認証が必要になる場面では、必要とされる資格情報を入力してパスしていく。
その流れで暗号化処理もおこなっていたのだけれど、理由は不明だが、作業者なら作業者の AD 側のアカウントを PC のローカル Administrators に参加させ、その AD 側のアカウントでログオンして暗号化処理を行えばよいとの事。

根本的な解決方法にしては腑に落ちないけれど、とりあえず今回の事象に対してはこの対策法ですすめることにした。

Windows 10 (1803) 用の ADMX が公開されてるよ

これはエラーの件とは無関係だと思いますが、Windows 10 (1803) 向けのグループ ポリシー テンプレートが公開されているとのことで、こいつを早速  Active Directory のセントラル ストアに入れてしまいます。
Administrative Templates (.admx) for Windows 10 April 2018 Update (1803) - 日本語

ここからダウンロードした Administrative Templates (.admx) for Windows 10 April 2018 Update.msi をドメインコントローラー上で実行し、C:\Program Files (x86)\Microsoft Group Policy\Windows 10 April 2018 Update (1803) に展開された PolicyDefinitions フォルダーの中身をすべてセントラル ストアにコピー。
あとは他のサイトにあるドメイン コントローラーにも複製されるのを待つだけ。
待つだけ。
いつまで?
いつまで待てばいいの?
とか気になっていたら 「古い Active Directory からバージョンアップしてきた場合、ファイル複製の機能のままになってるかもよ。 今は DFSR だよ」 なんていう記事を発見。。。

そして FSR から DFSR へのマイグレーション

マイクロソフト Network & AD サポートチーム公式ブログの FSR から DFSR への移行 (SYSVOL) という記事に丁寧な手順が書いてある。
さらに、毎度本当にお世話になっている富士通のサーバー関係の PDF 文書から今回は Windows Server 2012/2012 R2 Active Directory 移行の手引き3.2.6 SYSVOL 複製方式の変更 にも丁寧な手順が書いてある。

ローカルのサイトに PDC 役を含め DC が 2台、別のサイトに 2台、さらに別のサイトに RODC が 1台計 5台の DC で作業を開始。 途中 AD の複製スパンによる待ち時間が発生しつつ正味 3時間で再起動なしに終了。

警察です、ここの事業所に Aさんという方はいますか?

お調べしますね。 ここの事業所には W1 と W2 と W3 の 3つ事業本部が所属しています。
どの事業本部をお調べしますか? W1 ですね。
お調べしますね。 W1 事業本部には 4つの部がありますね。
・・・
・・・
・・・
・・・
Aさんはここの事業所ので所属はなく、ここの事業所の W3事業本部の  X5部の Y2課の Z1係の所属ですね。
これが Z1係の従業員リストです。 どうぞ。

警察です、ここの事業所の全従業員のリストをください

はいどうぞ、全従業員です。

たらい回しもイヤだ。 かといって全部から調べるのもイヤだ。 というかハッキリと答えてほしい

Get-ADGroupMember -Identity <グループ名>
これで取れるのは指定したグループに直接参加しているユーザーやグループの一覧なので、参加しているグループのメンバーの名前はでてこない。
Get-ADGroupMember -Identity <グループ名> -Recursive
これで指定したグループに参加しているグループに参加しているグループに参加しているメンバーのように間接的に参加しているメンバー全員をリストアップできる。
でも  YES か NO で答えが知りたい。

Get-ADGroupMember は Microsoft.ActiveDirectory.Management.ADPrincipal 型のオブジェクトか、その配列を返すので DistinguishedName とか SamAccountName とか SID とか持っているようです。
比較側のユーザーは普通に Get-ADUser で取得。 これももちろん同じプロパティを持ってる。
(Get-ADGroupMember -Identity <グループ名> -Recursive | Select-Object -ExpandProperty DistinguishedName) -Contains (Get-ADUser -Identity <ユーザー名>).DistinguishedName
これで Get-ADGroupMember から返ってきた DistinguishedName の配列と Get-ADUser から返っていた DistinguishedName を比較でき、含まれているかどうかを True / False で調べられるようになった。
本質を理解していないのでイロイロ遊んでみたら、Get-AdUser 側は DsitinguishedName を引き合いに出さなくても行けました。
(Get-ADGroupMember -Identity <グループ名> -Recursive | Select-Object -ExpandProperty DistinguishedName) -Contains (Get-ADUser -Identity <ユーザー名>)
そういうものなのかと理解したつもりになって、ついでに引数名 -Identity も省略してみたけど、これでも行けますね。 -Identity はデフォルトの引数だったかね。
(Get-ADGroupMember <グループ名> -Recursive | Select-Object -ExpandProperty DistinguishedName) -Contains (Get-ADUser <ユーザー名>)
さらに冒険してみた。
Select-Object でプロパティ展開する部分は -ExpandProperty を使うのだけれど、文字が長いとか -ExcludeProperty と間違うとか、意外に嫌われているようで、Select-Object の替わりに ForEach-Object を使う事もできるんだそうな。
(Get-ADGroupMember <グループ名> -Recursive | ForEach-Object DistinguishedName) -Contains (Get-ADUser <ユーザー名>)
奥が深いというか、、、

Windows 2000 の時からエクスプローラーに備わっていた、Active Directory のユーザーやコンピューターを簡易的に検索するダイアログです。
Windows 10 もエクスプローラーで [ネットワーク] を選ぶとリボンに [ネットワーク] タブが出てきて、その中にある [Active Directory の検索] というボタンでダイアログが出る。
Active Directory 検索ダイアログ

Active Directory 検索

個人的には自作のショートカット ファイルを作り、そいつをタスクバーにピン留めしています。
C:\Windows\System32\rundll32.exe dsquery.dll,OpenQueryWindow
で、[表示] -> [列の選択] で検索結果一覧に表示する項目を選べまして、この中に "社員 ID" という物があるのですが、ユーザーを検索してもこの列は空欄のままでございます。 ユーザー アカウントの EmployeeNumber と EmployeeID に社員番号を仕込んであるので表示されてもいい物はずなのですが。
このツールの [社員 ID] は Active Directory ユーザーアカウントの EmployeeID ではないのだろうか。。。

と数年間悩んでいたのですが、検索場所の指定で初期値 「全部のディレクトリ」 となっているところを自分のドメインを指定して検索したら結果に社員 ID も表示されました。
ディレクトリ全体を検索する場合は取り出す属性を絞ってるんでしょうかね。
何はともあれめでたしめでたし。

2017年3月の Windows 10 累積的な更新プログラム KB4013429 は Active Directory 管理センターがクラッシュする件に対応しています。

KB4013429

Addressed issue where the Active Directory Administrative Center (ADAC) crashes when attempting to modify any attribute of any user account in Active Directory.
累積的な更新プログラムの一覧の日本語ページにはまだ掲載されていないようですが英語版のページには掲載されていますね。
まずはよかったよかった。

アカウント情報を編集して更新しようとすると Active Directory 管理センターが不明なエラーを発して落ちてしまう問題の原因が分かった。
以下は先週末自宅に引きこもって実験した結果。

まずは手順

  1. Windows 10 Enterprise 評価版を使って VM を作成。 (Windows 10 Version 1607)
  2. 作成した VM を Active Directory に追加。
  3. RSAT を VM にインストール。
  4. Active Directory 管理センターが正常に使えることを確認。
  5. Windows Update で OS を最新状態にする。
  6. Active Directory 管理センターが異常終了することを確認。
  7. 「インストールされた更新プログラム」 から累積的な更新プログラムを削除。
  8. Microsoft Update カタログから一つ前の累積的な更新プログラムをダウンロードしてインストール。
  9. Active Directory の動作を確認。
  10. 以下 7 から 9 を繰り返し、Active Directory 管理センターが正常終了するポイントを見つける。

結果、2016年12月13日公開の累積的な更新プログラム 「KB3206632 (14393.571)」 をインストールすると Active Directory 管理センターが異常終了することが判明。
その少し前、2016年12月9日に公開された 「KB3201845 (14393.479)」 までにとどめておけば良い。

残念ながら最新の累積的な更新プログラムである 2017年1月10公開の 「KB3213986 (14393.693)」 でもこの現象は継続中。

【参考】
Windows 10 用のリモート サーバー管理ツール (RSAT) のダウンロード
https://www.microsoft.com/ja-JP/download/details.aspx?id=45520
Microsoft Update カタログ
https://catalog.update.microsoft.com/v7/site/home.aspx
Windows 10 バージョン 1607 (64bit) と Windows Server 2016 の累積的な更新プログラム一覧
https://support.microsoft.com/ja-jp/help/4000825

Windows 10 Professional にインストールした RSAT の Active Directory 管理センター (略して ADAC っていうのかな?) で不明なエラーが頻発して困っている。

Windows 10 にログオンして ADAC を利用している Windows アカウントは対象 AD のアカウント オペレーターの権限を持っている。
作業対象のアカウントの属性値などを変更して上書き保存しようとすると 「不明なエラーが発生しました」 となる。
ちなみに結果は反映されている。

イベントログには次の二つのエラーが記録されている。
--------
ソース: .NET Runtime
イベント ID: 1026
アプリケーション: dsac.exe
フレームワークのバージョン: v4.0.30319
説明: ハンドルされない例外のため、プロセスが中止されました。
例外情報: System.ComponentModel.Win32Exception
--------
ソース: Application Error
イベント ID: 1000
障害が発生しているアプリケーション名: Dsac.exe、バージョン: 10.0.14393.347、タイムスタンプ: 0x57f86637
障害が発生しているモジュール: KERNELBASE.dll、バージョン: 10.0.14.393.479、タイム スタンプ: 0.582588e6
例外コード: 0xe0434352
--------

この PC には先に Windows 10 用の RSAT をインストールし、そのあとの機会に Visual Studio Communication 2017 RC を入れ、調子が悪いので RSAT を再インストールしている。
別の Windows 10 PC に入っているdsac.exe のバージョンが微妙に違うが、これは RSAT をインストールした時期による違いか。

ということは Visual Studio Community 2017 RC が影響してるのか?
一応 RC なら運用環境の PC でも問題ないってことになってはいるが、とはいえ RC は RC であり RTM じゃぁない。
というところが原因なのかな。。。
エラーを回避するため久しぶりに Active Directory ユーザーとコンピューターを使って作業をしたけれど、久しぶりだと使いづらいなぁ。。。

↑このページのトップヘ