Windows10 バージョンごとに別のポリシーを適用する方法

最近 ActiveDirectory のグループポリシーを OS のバージョンに応じて適用したいという要件に出くわしたので、そういった対応が可能か確認してみました。

結論として WMI フィルターを活用することで対応できそうだったので、適用方法を確認していきたいと思います。

まず、適用したい OS のバージョン情報を確認します。

今だとクライアントならほぼ Windows10 になると思いますが、設定アプリのシステムよりバージョン情報を見ていきます。

この画面内 OS ビルドの値を覚えておきましょう。

以下内容の場合 18363.959 となっています。このうち 18363 が覚えておく場所です。

 

f:id:mohessu:20200812030309p:plain

 

続いて AD にアクセスし、グループポリシーの管理を開きます。

ここから WMI フィルターを選び、右クリックで新規を押します。

名前はわかりやすいフィルター名をつけましょう。次に追加ボタンを押します。

f:id:mohessu:20200812031129p:plain

するとクエリの追加画面になるので、名前空間とクエリを記載していきます。
名前空間は初期値のままで大丈夫です。クエリは先ほど覚えた 18363 の前に 10.0. を付加します。これは Windows10 を表すバージョン番号ですね。

名前空間:root\CIMV2

クエリ:Select * from Win32_OperatingSystem where Version = "10.0.18363"

f:id:mohessu:20200812025901p:plain

今回は名前を Windows10_1909 としました。

f:id:mohessu:20200812025922p:plain

対比できるようにバージョンを 20185 とした WMI フィルターも作っておきます。( 2009_Insider_Dev としました)

f:id:mohessu:20200812030039p:plain

この WMI フィルターを使用している GPO の枠で右クリックし追加を押しましょう。

GPO の選択画面が出るので関連させたい GPO を選びます。

f:id:mohessu:20200812031749p:plain

これで適用準備は完了です。

あとはこのポリシーが配布された GPO が適用されるOU内のユーザーやマシンでアクセスしてみましょう。

以下コマンドをコマンドプロンプトから確認すると、適用されたかどうかがわかります。 1909 のマシンでアクセスしたのですが、見事適用されたようです。

gpresult /r

f:id:mohessu:20200812030126p:plain

WMI フィルターに適用可能な値は wmic というコマンドで確認可能です。

コマンドプロンプト以下コマンドを打つとクエリに適用可能な項目がわかります。

wmic

/namespace:\\root\CIMv2

path Win32_OperatingSystem

f:id:mohessu:20200812030139p:plain

バージョン情報は後ろの方ですね。

f:id:mohessu:20200812030155p:plain

今回はルートに GPO を適用していますが、ポリシーを途中に付けても同様に動作しました。

f:id:mohessu:20200812032752p:plain

WMI フィルターはほかにも細かく設定可能ですのでぜひ一度何ができるか確認してみてください。

音楽:永遠の螺旋

Windows10 DNS over Https を試してみました

先週の Windows10 Insider Dev で取り込まれた DNS over Https を試してみたいと思います。

利用するサイトは 8.8.8.8 の Google DNS にしてみました。

設定アプリから Wi-Fi の設定を変更する方法で進めていきます。
設定自体は DNS 設定の編集画面から選択するだけですが、 8.8.8.8 を2か所に設定し、優先を 53 ポート、 代替を 443 ポートにするといった芸当は行えませんでした。

f:id:mohessu:20200811014433p:plain

というわけで、今回は 8.8.8.8 の暗号化のみ( 443 ポート)にして検証です。

f:id:mohessu:20200811014446p:plain

簡単に確認していきたいため nslookup を使って確認してみます。
その後、 netstat コマンドで 8.8.8.8 があるかを確認します。

f:id:mohessu:20200811015149p:plain

8.8.8.8 はなかったのですが dns:https というそれっぽい値がありました。

おそらくこれですね。

f:id:mohessu:20200811015135p:plain

もうちょい踏み込んで、リソースモニターでも確認してみます。

リソースモニター、ちょっとした確認するのにとても便利ですよね。

というわけでこちらからは 8.8.8.8 に 443 ポートで接続していることが見て取れました。

f:id:mohessu:20200811015507p:plain

これ使うまで知らなかったのですが dns.google って DNS 名が割り当てられているのですね、、、
やっぱり DNS サーバーにも名前があると便利なのでしょう。 ActiveDirectory のように他者に名前解決をゆだねるようなケースでしょうか。

思ったよりも簡単に確認できてよかったのですが、これが一般に使われ始めると、もうネットワークは 80 / 443 ポートのみ利用できればなんでもできる時代になってきそうですね。

最近のネットワークは複雑化しすぎている気がするのでこの流れはとても歓迎できます。

ぜひこの流れ、進んでほしいところですね!

音楽:青い波頭

Windows10 Insider Preview Build 20185リリース

今週も Insider Dev チャンネルで新しい Build がリリースされています。

今年に入ってからはアメリカの祝日以外はきちんと更新されているようなのでこのままこの更新が続いてくれるとよい流れになりそうですね。

f:id:mohessu:20200809124135p:plain

さて今週は DNS の設定に手が加わっています。

ネットワークの設定は徐々に設定アプリに移動されていますが、その一環として DNS も設定アプリに移動してきた形です。そして、そのタイミングに合わせて暗号化された DNS 通信を許可するようになったのです。暗号化された通信は DNS over HTTPS の通信となっており、今のところ DNS over TLS は選択できなさそうでした。

設定は設定 - ネットワーク - 状態 からプロパティを選ぶことで選択画面に移動できました。現在はネットワークごとに設定ができず、全体設定でのみ変更できるようでした。(赤字で書いてあるように Wi-Fi だけの制約かもしれません。)

f:id:mohessu:20200809122056p:plain

全体 Wi-Fi 設定に入るとこんな感じです。 DNS 設定の後方にかっこで Unencrypted とありますね。

f:id:mohessu:20200809122134p:plain

設定内容を見ていくと、特定のアドレスのみで暗号化設定が行えるようになっています。

f:id:mohessu:20200809122228p:plain

GoogleDNS なんかでは選択ができるようになっていますね。

選択肢は非暗号、暗号化のみ、暗号化優先(どちらでも可)の 3 択になっています。

f:id:mohessu:20200809122254p:plain

今暗号化で使えるのは以下の URL で紹介されているいくつかの IP のみですが今後増えていくことでしょう。

https://techcommunity.microsoft.com/t5/networking-blog/windows-insiders-can-now-test-dns-over-https/ba-p/1381282

DNS は昔から悪意あるユーザーに狙われやすい箇所なので、ここが整備されてくるとインターネットの安全性が高まっていきますね。

ただ DNS は不変であるという前提で作られているシステムも多いはずなので入れ替わっていくまでには相応の時間が掛かることかと思います。

本当は Wi-Fi の規格が更新されるタイミングなんかに合わさるとよいのですけどね。

OS や アプリのレイヤーからではできるところからコツコツとやっていくほかないので、決めごとのレイヤーは異なりますが WPA4 あたりに必須として実装されることを祈りたいですね笑

そのほか、スマホ同期も更新されたようですが、いまだに iPhone では縁のない限られた世界となっています。

また今後に向けてとなるようですが、 Intune で多数の admx ポリシーがサポートされつつあるようです。Azure AD を適用しきれない理由の一つとして GPO のサポートがあったので、この辺りが移行できるようになるといよいよ ActiveDirectory からの離脱が加速してくるかもしれませんね。

こうなってくると Microsoft 365 のうち、いまいちパッとしなかった EMS が一気に脚光を浴びそうな感じがしてきますね。

それまではまだ時間が掛かると思いますが、ぜひこの流れは進めていってもらいたいですね!

音楽:笑ってた

 

Microsoft 365 MFA の設定をリセットするには

一度 MFA の設定を行うと、次からは最初に設定した方法で多要素認証をすることになります。

スマホの番号が変わった場合や、認証方法を変更したい場合には設定を変える必要があります。

自分自身はマイアカウントのセキュリティ情報から変更することができますが、管理者として変更するには Azure AD の設定もしくは PowerShell から変更する形となります。

今回は PowerShell での変更方法を見ていきます。

まずは管理者で Microsoft 365 に接続しましょう。

Connect-MsolService

f:id:mohessu:20200808093714p:plain

いつものように認証ですね。

f:id:mohessu:20200808093813p:plain

パスワード、、、

f:id:mohessu:20200808094007p:plain

多重認証と、入力していきます。

f:id:mohessu:20200808093919p:plain

ログイン出来たら以下のコマンドを利用して MFA を一時解除することで設定がリセットされます。

Set-MsolUser -UserPrincipalName "UPN名" -StrongAuthenticationMethods @()

f:id:mohessu:20200808094103p:plain

リセット後にログインを行おうとすると、、、

f:id:mohessu:20200808094240p:plain

追加のセキュリティを確認する画面が起動します。

これ、初期設定と同様ですね。

f:id:mohessu:20200808094323p:plain

テキストメッセージでコードを送信するにした場合は以下のようにコード入力画面が表示されます。電話するにすると電話がかかってきますね。

f:id:mohessu:20200808094407p:plain

ブラウザではなくアプリの場合は専用のパスワード認証となるため、こんな感じの表示が追加されます。

f:id:mohessu:20200808094528p:plain

という感じで MFA 設定のリセットが行えました。

管理者で設定の変更が必要となるときはこの方法は有用なのでぜひ覚えておきましょう。

音楽:SANTI-U

Microsoft 365 MFA を PowerShell で設定するには

Microsoft 365 を利用する上ではぜひ利用しておきたい多要素認証の機能。
GUI からの設定もありますが PowerShell からでも設定することができます。

今回は PowerShell を使った設定を見ていきましょう。

MSOL に接続ができる状態にするため、必要であれば以下モジュールをインストールしておきましょう。

https://docs.microsoft.com/en-us/powershell/azure/install-az-ps?view=azps-4.5.0

まずは PowerShell を起動します。

 Connect-MsolServiceコマンドでログインします。

f:id:mohessu:20200808093714p:plain

ログインは管理権限がある人で行いましょう。

f:id:mohessu:20200808093813p:plain

管理権限を持っている人の場合、最近は MFA が自動的に有効となっているので安全です。まだ MFA を有効化していない場合はぜひ有効にしておきましょう。

f:id:mohessu:20200808094007p:plain

MFA は初期設定の状態により電話や SMS などで認証する形になっています。

f:id:mohessu:20200808093919p:plain

次に MFA 設定情報を作ります。

この設定情報をユーザーにあてることで設定していく形となります。

$sar= New-Object Microsoft.Online.Administration.StrongAuthenticationRequirement
$sar.RelyingParty= '*'
$sar.State = "Enabled"

RelyingParty は信頼先になります。 * を設定するのが良いようです。(ほかの値は何が取れるかわかりませんでした。おまじないと思っておきましょう、、、)

State は多要素認証を利用するかどうか。ですね。

State は Enabled のほか、 Enforced (強制)、 Disabled (無効)から選べます。

f:id:mohessu:20200808142153p:plain

1 名のユーザーに追加する場合は以下のコマンドレットを利用します。(最後の $sar の部分で先ほど作った MFA 設定情報を使う形ですね。)

Set-MsolUser -UserPrincipalName "UPN" -strongauthenticationrequirements @($sar)

複数ユーザーに適用したい場合は以下の形にして CSV ファイルなどから読み込みましょう。

$users=Import-Csv "c:\users.csv"
$users | foreach{Set-MsolUser –userprincipalname $_.userprincipalname -strongauthenticationrequirements @($sar)}

この書き方の場合 CSV ファイルはヘッダー付きのカンマ区切りで Unicode エンコードになっていれば OK です。ヘッダーは 1 行目から読まれるため、どこかに userprincipalname  の列があればOKです。

うまく活用すると少しの人数に分けながら MFA を有効にしていくことができます。

いきなり MFA が有効になると戸惑うことも考えられるため、適用ウインドウを考えながら設定を進めていくのがお薦めです。

音楽:昴の集い

Microsoft 365 アプリケーションランチャーに Project が含まれるようになっていました

いつのころからか、 Microsoft 365 アプリ一覧の中に Project が含まれるようになっていました。

この Project はその名の通りプロジェクトを管理するためのソフトです。

Office のアプリとして数えられることが多いのですが Visio とともに Office Suite に入らずに単独製品としての地位を確立しています。

利用するときはビジネスケースが多いため高級なソフトのイメージが強いですね。とうとう Microsoft 365 ファミリーとしてだれでも使えるようになったのかとも思ったのですが、実際はビューワーが解禁となったようですね。

https://www.office.com/apps?auth=2

f:id:mohessu:20200807014422p:plain

早速選択してみると以下のサイトに遷移しました。

https://project.microsoft.com/ja-JP/

初回起動時は例のごとくチュートリアルです。

f:id:mohessu:20200807014452p:plain

ホームの動作について説明されていますね。
2 枚のみの簡単な説明で終わってしまいました。

f:id:mohessu:20200807014515p:plain

起動すると左上に新しいプロジェクトの作成ボタンとプロジェクトの確認画面が表示されました。

f:id:mohessu:20200807014708p:plain

作成ボタンはこのように、ライセンスがないと動作しないつくりとなっています。

f:id:mohessu:20200807015405p:plain

ちょっとだけ使えるんじゃないかとも期待したのですが、まあ順当なところでしょうか。

それよりもビューワーとしては利用できるようになったということは入力者を絞った使い方はサポートされているのかもしれません。入力は管理者に任せることは多々あると思うので、良い使い方がないか検討してみるのも面白いかもしれませんね。

音楽:Warriors

Microsoft 365 Azure Information Protection クライアントのサポート終了時期が明示されていました

Microsoft 365 はクラウドの仕組みであるため、サポート終了に関することは細心の注意を払ってみておく必要があります。が、ちょっと見逃していました。 というわけで、 Azure Information Protection のクラシッククライアントがサポート終了に向けて動き出したようです。

https://docs.microsoft.com/en-us/azure/information-protection/rms-client/aip-client

f:id:mohessu:20200806014416p:plain

ここにもあるように終了は 2021 年 3 月 31 日となっています。

この発表は 2020 年 3 月だったようなので、約 1 年の猶予をもってサポート終了となっていくようです。

Azure Information Protection はファイルに対し暗号化や転送禁止設定などのファイルの保護やユーザーにファイルがどういった属性のものかをわからせるためのラベルを付与する機能を持った仕組みでした。

仕組みが Office 寄りのため、 Excel や Word から設定することができ、結構便利に利用することができるのですが、これをさらに拡張して Microsoft 365 のセキュリティセンター内のラベルと統合していくという方針になったようです。

その中で、古い Azure Information Protection クライアントをサポートの対象から外していこうというのが今回の流れになっています。

今後は統合されたラベル付けクライアントとして配布されていくようです。

クラシックといってもクライアントソフトとなっていて、見分けるためには以下のバージョン情報を見てくださいということのようです。

バージョン 1.X 系がクラシック、バージョン 2.X 系が統一されたラベル付けクライアントとなります。

https://docs.microsoft.com/ja-jp/azure/information-protection/faqs#identify-the-client-you-have-installed

f:id:mohessu:20200806015527p:plain

また、名称も Microsoft Information Protection という形に変更となるみたいですね。

https://techcommunity.microsoft.com/t5/azure-information-protection/announcing-timelines-for-sunsetting-label-management-in-the/ba-p/1226179

Windows にも似た名前の仕組みがあり、 Windows Information Protection という社内のファイルと自宅のファイルを分けて管理するものとなっています。

Azure 、 WindowsMicrosoft とどれが何かわかりにくいですが、それぞれのラベルを統合して管理しようというのが Microsoft Information Protection となるため、ぜひこの機能を使って管理を統合していきたいですね!

音楽:サイクル