SEくぼたの事件簿

インフラSEとしての活動を記録していきます

PowershellでのMicrosoft365への接続を一括で実施するモジュール(Office365,AzureAD,Exchange Online,Teams)

こんにちは!

Microosft365ユーザーが増えてくるといろんなことをやってみようとしてPowershellを利用しよう!!って方が合わせて多くなってきていますね!

今回ユーザー様からこんなお問い合わせをいただきました。

AzureADのコマンドレットを利用したいのだけど、Connect-MsolServeceしたのにコマンドがないってエラーになる!!」と!

Microosft365をPowershellで接続して利用する場合、必要なコマンドレットによって複数のサービスに接続することになります。

  1. Microsoft365(MSOLService)
  2. AzureAD
  3. Exchange Online
  4. Teams

これらに一つずつ接続してもよいのですが、実際利用し始めるとまた接続コマンド打たなきゃ・・・・って結構面倒だったりします。

 

面倒だからとりあえずスクリプト化するかってなるのですが、スクリプト化してしばらくするとスクリプトひらくのすら面倒に・・・・・笑

どんだけめんどくさがりなんやって感じですが!

 

ってことで今回は

「Microsoft365サービスに一斉接続するPowershellモジュールの作成」

について書いていきます!

※注意

本記載では接続する先のモジュールがインストールされていることが前提になっています。

初利用でモジュールをインストールしていない人は

Powershellを管理者で起動し、Install-Module xxxを実行してくださいね!

xxxはAzureADならAzureADPreview,Office365ならMSOLServiceです。

詳しくは以下を参照ください。

docs.microsoft.com

 

まず、PowershellにはImport-Moduleというコマンドレットがあり

作成したモジュールをインポートすることが可能です。

この機能を利用します!

Powershellでは.psm1という拡張子で保管したファイルをImport-Moduleでインポートすると.psm1内に記載されているファンクション(関数)を利用することができます。

 

  • では実際に作っていきます!!!

今回スクリプトPowershell_iseを利用して作っています。

スタート画面からPowershell_iseを検索してクリックします。

表示されたスクリプト画面に以下の通り記載します。

Function Connect-M365Services{

    $Cred = Get-Credential

    Connect-MsolService -Credential $Cred

    $exchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri “https://outlook.office365.com/powershell-liveid/” -Credential $Cred -Authentication “Basic” -AllowRedirection

    Import-PSSession $exchangeSession -DisableNameChecking

    Connect-AzureAD -Credential $Cred

    Connect-MicrosoftTeams -Credential $Cred
}

f:id:KKubo19:20201006230937p:plain

そして好きな名前で保管します。

この時、拡張子は[.psm1]とします。

今回はConnectM365Services.psm1というファイル名にしています。

*1

 

次にこのファイルを配置するフォルダを探します。

実際このファイルをImport-Module "ファイルのフルパス"とすれば利用できるのですが、毎回インポートするのってめっちゃ面倒ですよね??

なので、Powershell起動すると作ったモジュールがインポートされるようにしておこうと思います。

 

画面したのコンソールにて以下のコマンドを実行

$env:PSModulePath

f:id:KKubo19:20201006231346p:plain

するとパスの一覧が表示されます。

f:id:KKubo19:20201006233047p:plain

上記に表示されたいくつかのパスのどれかにモジュールを保存します。

今回はC:\Users\ユーザー名\Documents\WindowsPowershell\Modulesに保管します。

エクスプローラーで上記パスを開きます。

※Modulesフォルダがない場合は自分でフォルダを作成してください。

f:id:KKubo19:20201006231812p:plain

上記で作成した.psm1ファイルと同一名称のフォルダを作成します。

そのフォルダ内に.psm1ファイルを格納します。

f:id:KKubo19:20201006231934p:plain

これで準備は完了!!

あとは再度Powershellを起動し、Connect-M365Servicesとうって実行するだけ!

ちゃんとTab補完も効きますし、ise上では候補にもあがってきます!

下図は候補にあがっていることを表示しています。

f:id:KKubo19:20201006232334p:plain

あとは実行すれば一括接続ができます!!

毎回複数実行が面倒ならぜひ使ってみてください!

 

  • 最後に!

Twitterでも情報発信したいと思いますので、興味があったらフォローしてください!

*1:

このファイルではFunctionとしてConnect-M365Servicesというファンクションを作成しています。

 モジュールをインポートした後、Connect-M365Servicesを実行すると、各種Microsoft365サービスに接続するコマンドレットが流れます。

ExchangeOnlineはV1モジュールになっているので、V2モジュールがいいよって方は修正してください

Intuneのグループポリシー分析でADのGPOをどのくらいIntuneに移行できるか確認してみた

こんにちは

少しずつブログの書き方を覚え始めました!とともに継続して書くのって結構大変なんだなあと実感しています。

僕も頑張って書いていきたいなあって漠然と思っています。

 

WindowsのActiveDirectory(AD)でグループポリシー(GPO)を利用し、クライアント端末の設定している方って結構多いんじゃないかと思うんですよね!

結構いろいろな設定ができる上にスクリプトも実行させられるのでいっぱい設定してます!なんてパターンもあると思うんです。

先日AzureADのウェビナーに参加したところ、オンプレのADからの脱却を検討していく必要があるよ!と聞きました。

そんな時に検討する項目の一つとしてGPOをどのように移行していくの?というのがあるのではないかと思います。

実際オンプレのADから脱却するとなるとAzureADにデバイスを参加させる必要があるかと思います。

※このあたりのデバイスの管理形態のお話はぜひAzureADのウェビナーをご覧いただきたいです!分かりやすいのと時間も短め!最高だな・・・・

https://github.com/yusukekodama/PMActivities/blob/master/Webinar/Schedule.md

 

その上でクライアント端末の設定を制御するのはIntuneのプロファイル設定を利用することになるかと思います。

ただし!!!!ウェビナーでMicrosoftの方もおっしゃられてました

オンプレのGPOをそのまま全部移行しようと思っても難しい!

と!

バイスを管理していくにあたり考え方を変えていく必要があるよ

とのことでした。

 

まあ。。。。とはいえ実際今使っているGPOをどうやって見直すんや・・・・

ってなりますよね!笑

2020/9時点にてIntune内にプレビュー機能として「グループポリシー分析」っていうものがあります。

これを利用するとオンプレのADのGPOをIntuneに移行できるかどうかを比較してくれるらしい!!!神か!

ってことで今回は

Intuneのグループポリシー分析を利用してADのGPOを移行できるかどうか

について書いてみたいと思います。

 

  • 用意するもの
  1. Intuneを操作可能なライセンス←今回はMicrosoft365E3を利用
  2. 分析したいGPOを設定しているADサーバー
  • 実施方法

まずADサーバ-にログオンします。

f:id:KKubo19:20200915192728p:plain

グループポリシーの管理をクリックして起動します。

f:id:KKubo19:20200915192802p:plain

今回はClientPolicyっていうGPOを分析してみます。

ちなみに設定しているGPOはこんな感じです。

WSUS系の設定やコントロールパネル系の設定を適当にいれてます。

f:id:KKubo19:20200915192859p:plain

f:id:KKubo19:20200915193004p:plain

f:id:KKubo19:20200915193024p:plain

まずこのGPOをバックアップします。

対象のGPOを右クリックして、「バックアップ」をクリックします。

f:id:KKubo19:20200915193112p:plain

今回はデスクトップ上のGPOというフォルダにバックアップを取得するのでそのフォルダを指定して、「バックアップ」をクリックします。

f:id:KKubo19:20200915193149p:plain

「成功しました」と表示されたらOKをクリックします。

f:id:KKubo19:20200915193238p:plain

するとバックアップしたフォルダに以下のファイルが作成されています。

「gpreport.xml

f:id:KKubo19:20200915193357p:plain

f:id:KKubo19:20200915193418p:plain

このファイルをIntuneの管理センターからアップロードして分析していきます。

Microosft365管理センターより「エンドポイントマネージャー」をクリックします。

f:id:KKubo19:20200915193821p:plain

 

バイスをクリックします。

f:id:KKubo19:20200915194742p:plain

「グループポリシー分析」をクリックします。

f:id:KKubo19:20200915194814p:plain

「インポート」をクリックします。

f:id:KKubo19:20200915194843p:plain

赤枠のボタンをクリックして、先ほど取得した「gpreport.xml」を選択します。

しばらくすると上部に「インポートが完了しました」と表示されます。

f:id:KKubo19:20200915194912p:plain

結果が表示されます。

え。。。。。MDMサポートは2%??

ほぼ移行できへんやないか~い!ってなりました!笑

f:id:KKubo19:20200915194940p:plain

一応どんな内容なのかを確認します。

2%の部分をクリックします。

f:id:KKubo19:20200915195005p:plain

一覧で設定内容が見られました!

設定可能なのはまさかの1つ!!笑

いや1つでもあってよかった・・・・・

f:id:KKubo19:20200915195029p:plain

f:id:KKubo19:20200915195112p:plain

赤字あたりをクリックして横にスライドさせて、枠をひろげてみました。

リモートデスクトップ系の設定はできるようですね!!

f:id:KKubo19:20200915195228p:plain

ということで、Intuneのプロファイルを作成して設定してみます。

  • Intuneのプロファイル作成

管理センターよりデバイスをクリックした後、「構成プロファイル」をクリックします。

f:id:KKubo19:20200915195524p:plain

プロファイルの作成をクリックし、プラットフォームで「Windows10以降」をクリックします。

f:id:KKubo19:20200915195612p:plain

プロファイルは「管理テンプレート」をクリックし、作成をクリックします。

f:id:KKubo19:20200915195733p:plain

名前を入力し、次へをクリックします。

今回はtestというプロファイル名です。

f:id:KKubo19:20200915195825p:plain

赤字①の方でGPOの設定時と同様に対象の設定箇所まで選択していきます。

今回は「コンピューターの構成」-「Windowsコンポーネント」-「リモートデスクトップサービス」-「リモートデスクトップセッションホスト」-「接続」なので

そこを表示しています。

赤字②に設定箇所が表示されるのでダブルクリックします。

f:id:KKubo19:20200915200020p:plain

赤枠内で「有効」を選択し、OKをクリックします。

f:id:KKubo19:20200915200241p:plain

そのまま次へをクリックします。

f:id:KKubo19:20200915200332p:plain

今回割り当て先はすべてのユーザーにしました。

選択して次へをクリックします。

f:id:KKubo19:20200915200405p:plain

作成をクリックします。

f:id:KKubo19:20200915200452p:plain

以上でプロファイルの作成は完了です。

 

  • まとめ

グループポリシー分析は気になっていたので試してみれてよかったなあ!と思う一方で2%しか移行できないことにびっくりしました!笑

まあ上記紹介ウェビナー内でもそのままは移行できないよって言ってたのでその通りではありましたが。。。。笑

考え方を変えて移行していかないといけないんだなって理解できました!

  • 最後に!

Twitterでも情報発信したいと思いますので、興味があったらフォローしてください!

Powershellでの繰り返し処理(Foreach)の使い方

こんにちは

これまでいくつかブログを書いてみましたが、記載したものの中ではWindowsやActiveDirectory,Office365といった環境ではユーザー単位で設定することも多くスクリプトを作成しています。

 

その中で毎回のように繰り返し処理を利用しているので、今回は

PowerShellの繰り返し処理の記述」について書きたいと思います。

 

数年前まだ新入社員のころ(今でも気持ちは新入社員ですが!笑)にPowershellを利用し始めたのですが、最初は全く意味が分からず苦労しました。

そんな時必ずと言っていいほど色んな方が書いたブログを参考にしていました。

同じような方がいたときに少しでも助けになればと思い記録していきます。

 

  • foreachの利用例として特定のOffice365内のユーザー情報を取得

まずは、CSVファイルを作成します。

「C:\temp\test」というフォルダに「UserInformation.csv」というファイルを作成します。

f:id:KKubo19:20200818184629p:plain

 CSVファイルの中身はこんな感じで作成しています。

1行目はヘッダー情報としてUserPrincepalnameとDisplaynameとしています。(分かればなんでもいいです)

f:id:KKubo19:20200818192719p:plain

2行目のA列に対象のユーザー情報(メールアドレス)を並べていきます。

B列は今回なくてもよいのですが、説明のために書いています。

#Office365への接続
$Cred = Get-Credential
Connect-MsolService -Credential $Cred
#ソースデータファイルのパス指定
$Datapath = "C:\temp\Test\UserInformation.csv"
#データファイルのインポート(Shift-JIS)
$Datas = Import-Csv -Path $Datapath -Encoding Default
#データファイルの行数分ループ
foreach($Data in $Datas){
    Get-MsolUser -UserPrincipalName $Data.UserPrincipalname
}

f:id:KKubo19:20200818183617p:plain

  • 記載内容の解説

2,3行目でOffice365への接続

6行目でCSVファイルのパス指定

9行目でCSVファイルのインポート

12-14行目でユーザー情報の取得

を行っています。

 

2,3行目はOffice365への接続でどうしても必要な記述なので説明を省きます。

9行目でCSVファイルのインポートを行うと、$Datasという変数の中にCSVのデータが読み込まれます。

$Datasを実行するとこんな感じです。

f:id:KKubo19:20200818193648p:plain

$Datas.userprincipalnameを実行すると$Datas内の[UserPrincipalname]の箇所のみとりだせます。

f:id:KKubo19:20200818193812p:plain

[UserPrincipalname]はCSVファイルのヘッダー情報として[UserPrincipalname]と1行目に記載したのでその値となっています。

CSVファイルの1行目の名前を[UserPrincipalname]ではなく[UPN]するとここで実行するのは$Datas.UPNとなります。

このように変数名にを[.]でつないで変数内に格納されている特定の値のみ取得することも可能です。

 

今回Office365の特定のユーザー情報を取得するには以下のコマンドレットを実行する必要があります。

Get-MsolUser -UserPrincipalName ユーザーのメールアドレス

上記コマンドではユーザーのメールアドレスをそれぞれ指定して実行していく必要があります。

そんな時にforeachを利用します。

書き方は以下のような形です。

  • foreachの書き方
foreach($Data in $Datas){

}

foreach(変数名1 in 変数名2){}です。

ここで変数名1と変数名2を指定する必要があります。

そもそもforeachは繰り返し処理なので、繰り返し処理をしたい情報を変数名2にいれます。

今回は上記にも記載してきた通り、UserInformation.csvの情報を$Datasという変数に格納したため、変数名2は$Datasとしています。

foreachは$Datasのデータの終わり(今回はヘッダー情報を除くとCSVのデータは2行なので2回処理)まで繰り返し処理をします。※データの行数分繰り返し処理をしてくれます。

変数名1はここで新たに定義してよい変数です。そのため、名前は他と被らなければなんでもよいです。今回は$Dataとしました。

$Dataにどんな情報が入ってくるのか分かりにくいので以下の図にしました。

f:id:KKubo19:20200818195412p:plain

f:id:KKubo19:20200818195508p:plain

上記図のように繰り返し処理を実行しているタイミングによって$Data内に1行分の情報が格納されていきます。

これの何が嬉しいかというと、先ほどのコマンドレットで指定するユーザーのメールアドレスは一人一人指定していく必要がありました。

この指定方法を利用することで1ユーザーずつの情報を取得することができます。

次にforeach(変数名1 in 変数名2){}の{}についてです。

{}の間に記載した処理を変数名2($Datas分)繰り返し処理を実行します。

そのため例えば、

foreach($Data in $Datas){
     write-host A
}

と記載すると$Datas内のデータ数分(今回は2回)、[Write-Host A]というコマンドレットを繰り返し実行します。※コマンドレットに意味はないです。

ここで今回実施したかったコマンドレットは

Get-MsolUser -UserPrincipalName ユーザーのメールアドレス

であったことから{}内に上記コマンドレットを入れたらよいことが分かります。

foreach($Data in $Datas){
     Get-MsolUser -UserPrincipalName ユーザーのメールアドレス
}

ユーザーのメールアドレスの箇所にユーザー毎のメールアドレスを指定していく必要があるので

{}内にて$Dataという変数を利用します。

foreach($Data in $Datas){
    Get-MsolUser -UserPrincipalName $Data.UserPrincipalname
}

このように$Data.UserPrincipalnameと記載しておくと、データの行数分繰り返しながら、その行のUserPrincipalNameのみを指定することができます。
下図がイメージです。

f:id:KKubo19:20200818200931p:plain

f:id:KKubo19:20200818201032p:plain

このような記載をすることで{}内の処理の1回目は

Get-MsolUser -UserPrincipalName test2@jbtest.tk

2回目の処理は

Get-MsolUser -UserPrincipalName testUser@jbtest.tk

というようにコマンドレット内で指定する引数のデータをCSVファイル内のデータに合わせて変化させて使うことができます。

実行結果は下記の形です。

f:id:KKubo19:20200818201507p:plain

今回はユーザー情報を取得するのみでしたが、CSVファイルの列をもっと多数にして様々な情報を入れておき、実行するコマンドレットを変更して、ユーザー情報を登録したり変更したりすることができます。

とっても便利なので僕はよく利用しています。

みなさんすでに利用されているかもしれませんが、まだ利用したことないよって方はぜひ一度試してみてくださいね!

 

  • 最後に!

Twitterでも情報発信したいと思いますので、興味があったらフォローしてください!

 

ADドメイン参加済みWindowsをHybridAzureADJoin時にIntuneに自動登録させる設定

こんにちは

Microsoft365(Office365)を利用されているユーザーでよく聞くのは、指定のデバイスのみOffice365にアクセスさせたいってことです。

これを実現するにはいつくか方法があるのですが、その一つとしてIntuneとAzureADを利用したデバイスベースの条件付きアクセスを利用することが多いです。

サードパーティー製IdPを利用したアクセス制限だとOffice365アプリにおいてはAzureADのトークンの仕様上、狙った動きをしないことがあるので。。。。。

 

その際、Intuneにデバイスを登録する必要があるのですが、当初IntuneへのWindowsバイス登録ってどうやるのか悩んだので記録します。

 

IntuneへのWindowsバイス登録にはいつくか方法があるのですが、

今回は「HybridAzureADJoin時に自動的にIntuneにWindowsバイスする方法」を記載していきます。

 

HybridAzureADJoin自体の設定は以下に記載しています。

 

kbtblog.hatenablog.com

 

ここから記載する手順は対象のPC(ユーザー)でHybridAzureADJoinを実行する前に実施しておく必要があります。

 

※注意!Intuneの設定は2020/8/1移行Azureポータルからの設定は不可になっています。

    設定はMicrosoft365管理ポータル内のエンドポイントマネージャーより実施してください。

 

  • 設定手順

1.CNAMEレコードをDNSに追加

外部に公開しているDNSにIntune利用用のCNAMEを登録する必要があります。

管理センターの設定-ドメインをクリック

f:id:KKubo19:20200818151625p:plain

利用対象のカスタムドメインの「DNSの管理」をクリック

f:id:KKubo19:20200818151709p:plain

続行をクリック

f:id:KKubo19:20200818151925p:plain

所有の外部公開DNSがあるので、「自分のDNSレコードを追加する」を選択して続行

f:id:KKubo19:20200818152020p:plain

詳細オプションをクリック

f:id:KKubo19:20200818152122p:plain

「IntuneとMobile Device Management for Micorsoft365」にチェックを入れる

f:id:KKubo19:20200818152211p:plain

下記のCNAMEレコードを2つ所有のDNSに登録した後、続行をクリック

DNSにレコードが正しく追加されていれば「状態」が適切となります

f:id:KKubo19:20200818152345p:plain

完了をクリック

f:id:KKubo19:20200818152516p:plain

 

2.デバイス登録のスコープ設定

管理センターより「エンドポイントマネージャー」をクリック

f:id:KKubo19:20200818152550p:plain

バイス-デバイス登録をクリック

f:id:KKubo19:20200818152702p:plain

自動登録をクリック

f:id:KKubo19:20200818152940p:plain

MDMユーザースコープの「すべて」を選択して保存をクリック

※MAMユーザースコープは「なし」としておいてください。

 MAMユーザースコープを「すべて」とすると「Windows Information Protection」を利用する設定となりIntune登録されないようです。

f:id:KKubo19:20200818153055p:plain

下図のように変更

f:id:KKubo19:20200818153321p:plain


3.グループポリシーの設定(ActiveDirectoryのグループポリシーの管理もしくはローカルグループポリシー)

ADサーバーよりグループポリシーの管理を起動し、必要な場合は新規でグループポリシーを作成します。

作成したグループポリシーを右クリックして編集を選択

管理用テンプレート > Windows コンポーネント > MDM

を選択

f:id:KKubo19:20200818154516p:plain

既定のAZURE AD 資格情報を使用して mdm の自動登録を有効にする

をダブルクリックして

「有効」ー「ユーザーの資格情報」

を選択してOKをクリック

f:id:KKubo19:20200818154659p:plain

作成したグループポリシーオブジェクトをHybridAzureADJoinedするデバイスに適用する必要があります。

対象のコンピューターオブジェクトが格納されているOUにグループポリシーをリンクします。

 

対象のWindowsクライアント側に上記で設定したグループポリシーが適用されていることを確認します。

コマンドプロンプトを管理者で起動し、「gpresult /r」コマンドを実行することで適用されたグループポリシーが表示されます。

これで設定は完了です。

 

GPOの設定については以下のURLに情報がありました。

https://docs.microsoft.com/ja-jp/windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy

 

  • 最後に!

Twitterでも情報発信したいと思いますので、興味があったらフォローしてください!

PowershellでActiveDirectoryユーザーのUPNプレフィックス、サフィックスを一括変更する方法

こんにちは!

前回の記事でHybridAzureADJoinedの設定について記載しました。

※詳しい前提内容は以下の記事を参照ください。ここから記載する内容は前回記載のUPNサフィックスの追加が完了している前提で記載します。

kbtblog.hatenablog.com

 

その中ではActiveDirectory(AD)ユーザーのUPNプレフィックスサフィックスを変更する必要があるパターン(UserA@test.co.jpであればUserAがプレフィックス、test.co.jpがサフィックス!)だったのですが、1ユーザーずつ手動変更するのはめっちゃ大変・・・・・・

こんな時、利用するのはやっぱり「Powershell」!!

ってことで今回はPowershellを使って、ADユーザーのUPNプレフィックスサフィックスを変更する方法を記載します。

 

  • 変更の前提
  1. ActiveDirectoryサーバにてPowershellが利用可能な環境である
  2. ユーザー情報を[UserA@test.local]から[TestUserA@test.co.jp]に変更する

 

今回利用するコマンドレットは以下のコマンドレットです。

Set-ADUser

ユーザーのプレフィックスサフィックスを変更するのでこんな書き方です。

Get-ADUser -SearchBase "CN=Users,DC=test,DC=Local" -Filter {UserPrincipalname -eq "UserA@test.local"} | Set-ADUser -UserPrincipalName "TestUserA@test.co.jp"

 

「-SearchBase」は設定変更するユーザーの検索先OUもしくはCNを指定します。

例では[test.local]内のUsersコンテナ配下を検索するように記載しています。

※例えば下図の「Office365内のUsers」を指定したい場合は「OU=Users,OU=Office365,DC=test,DC=Local」となります。

f:id:KKubo19:20200807153720p:plain

 

今回も!複数ユーザーに一斉にこれを実施したいので!!

まずはcsvデータを作成します。

UserData.csvという名前で作成しています。

f:id:KKubo19:20200817194408p:plain

1行目のAセルに「CurrentUser」、1行目のBセルに「NewUPN」を記載します。

これがヘッダー情報です!

2行目以降に変更したいADユーザーの情報を記載していきます。

 「CurrentUser」の列に現在の「UserPrincipalName」、

「NewUPN」の列に変更後の「UserPrincipalName」を記載していきます。

作成したCSVファイルをPowershellを実行するADサーバーの以下のフォルダに配置します。

「C:\temp」

以下のスクリプトを作成します。

#ソースデータファイルのパス指定
$Datapath = "C:\temp\UserData.csv"

#検索対象OU指定
$Searchtarget = "CN=Users,DC=test,DC=Local"

#データファイルのインポート(Shift-JIS)
$Datas = Import-Csv -Path $Datapath -Encoding Default

#データファイルの行数分ループ
foreach($Data in $Datas){

        $Command = 'Get-ADUser -SearchBase $Searchtarget -Filter {UserPrincipalname -eq "' +$Data.CurrentUser + '"} | Set-ADUser -UserPrincipalName ' + $Data.NewUPN
        Invoke-Expression $Command
}

f:id:KKubo19:20200817195428p:plain

 

2行目の「$Datapath = "C:\temp\UserData.csv"」で読み込むCSVファイルのパスを指定しているのでパスやファイル名を変更した場合はここを修正します。

5行目の「$Searchtarget = "CN=Users,DC=test,DC=Local"」で変更対象のADユーザーの検索場所を指定しています。上記記載の「-SearchBase」を指定する方法です。

ADユーザーの格納場所をしてしてください。

 

スクリプトを実行するとCSVに記載のADユーザーのUPNが変更されます。

※変更後のUPNサフィックスがADサーバーに追加されていないとできないので注意してください。

方法は上記過去記事に記載してあります。

 

今回もforeachを使用して繰り返し処理を記載しています。(正確にはForeach-Objectですね!笑)

とても便利なのでぜひ使ってみてくださいね!

そのうちForeach-Objectの使い方も書こうかなあ。。。単純すぎていらないか・・・笑 

 

  • 最後に!

Twitterでも情報発信したいと思いますので、興味があったらフォローしてください!

 

 

 

 

 

ActiveDirectoryとAzureADでのHybridAzureADJoined設定と必要なADユーザーの情報変更

こんにちは

 

Office365を利用する中でActiveDirectory(AD)とAzureAD(AAD)の同期でHybridAzureADJoined設定が必要になるケースがあります。

例えば

  1. IntuneとMECM(旧名SCCM)の共同管理を利用する
  2. オンプレADドメイン参加済みWindowsPCのIntuneへの自動登録
  3. Windows10 E3 or Windows10 E5のライセンス自動適用
  4. WindowsVirtualDesktopで作成するデバイスをオンプレADに参加させる

等々、設定が必要になってくるケースがあることと、HybridADJionするWindowPCの状態にも依存していて最初に調べた時に結構困ったので、内容を記録しておきたいと思います!

※2はHybridAzureADJoin時に登録しないと自動登録されなくなるみたいで後から登録したいってなると再度HybridAzureADJoinさせないといけなくなるので事前に計画して実施するなら先に設定してください。

 設定方法はこれです。

kbtblog.hatenablog.com

 

 

ということで今回は「AzureADConnectを利用したHybridAzureADJoined設定」について書いていきます!

まず初めにHybridAzureADJoinedは書くと長いので以後HAADJと略していきます!

 

そもそもAzureADにデバイスを参加させる方法は3つあります。

  1. AzureAD参加
  2. ハイブリッドAzureAD参加
  3. AzureAD登録

このあたりの違いについては僕が書くよりもとってもいい資料があるのでご紹介です!笑

※Micorosoft社の方が書いてくれておりめっちゃ読みやすいんです!

https://github.com/yusukekodama/PMActivities/blob/master/Webinar/Schedule.md

過去記事の以下のタイトルの内容を読んでくださいね!

Azure AD の新しいデバイス管理パターンを理解しよう
Modern device management with Azure AD

 

  • HAADJの動き(AzureADConnectのみの場合)
  1. ActiveDirectoryとAzureAD間でAzureADConnectでユーザーオブジェクトを同期する 
  2. 同期されたユーザーにてクライアントPCにログオンする←ここめっちゃ重要

  3. クライアントPCがActiveDirectoryとAzureADに情報を受け渡し(クライアントPC内のタスクスケジューラにて実行)、ActiveDirectory内の自身のクライアントPC(ログオンしたコンピューターオブジェクト)のUserCertificateに証明書の値を追加
  4. AzureADConnectは同期対象のOUかつコンピューターオブジェクトであれば「UserCertificate」に値が入っている場合、AzureADに同期
  5. AzureADにコンピューターオブジェクトが同期され、AzureADにてログオンされたユーザー情報との紐付けを実施

何が重要かというと2のPCでのログオンユーザーがAzureAD(Office365)のログオンユーザーIDと一緒でないといけないです!

下図みたいなパターンだとADのユーザー(ユーザーA)の社員番号が1234と仮定すると恐らく、WindowsPCにtest\1234もしくは1234@test.localでログオンしているかと思います。

AzureAD(Office365)には1234@test.localなんてユーザーはいないためHAADJは失敗します。

f:id:KKubo19:20200804184834p:plain

 

つまりADユーザーのUserPrincipalNameをAzureAD(Office365)と一緒にする必要があります。(今回は下図のとおりプレフィックスサフィックスも変更しています。)

f:id:KKubo19:20200804192045p:plain

ADユーザーの情報を上記状態(UserPrincipalNameのみでOK)に変更すると、ユーザーはWindowsに「ユーザーA@test.co.jp」でログオンすることができるようになります。

するとAzureAD(Office365)のIDとも一致し、HAADJが成功します。

※ユーザーはWindowsへのログオン名が変化するため注意する必要があります。

 

~2020/08/20追記~

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

UPN変更さえしていれば、sAMAccountname(test\1234)でログオンしてもHAADJが成功しました!!知らなかった!そうだったのか

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

 

プレフィックスサフィックスの変更による影響は以下に参考になるものがありました。

https://docs.microsoft.com/ja-jp/azure/active-directory/hybrid/howto-troubleshoot-upn-changes

 

HybridAzureADJoinの動作やAzureADの動作について細かな内容は以下に記載がありました。

https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-how-it-works-device-registration

 

ちなみにWindowsクライアントがADおよびAzureADにデバイス登録通信をするときにはWinHTTPを利用しているようなのでWinInetにしかプロキシ設定していないとかだと通信できずにエラーになるのでご注意を!!

※インターネットオプションのプロキシ設定だけだとNGなことあるよってことです!

 

  • 構成

ActiveDirectoryサーバー兼AzureADConnectサーバー(WindowsServer2016)

※ActiveDirectoryとAzureADConnectサーバーのOSはWindows2012R2以降であればOKなようです。詳しくは以下URLをご確認ください。

https://docs.microsoft.com/ja-jp/azure/active-directory/devices/hybrid-azuread-join-managed-domains

 

  • 設定手順 

1.AzureADConnectのインストール

まずはAzureADConnect(AADC)をサーバーにインストールします。本番環境ではADサーバーにAADCをインストールすることは非推奨ですが、今回は検証用なのでADサーバーにインストールしちゃいます。

 

https://www.microsoft.com/en-us/download/details.aspx?id=47594

にアクセスして、DownLoadボタンからAzureADConnectのモジュールをダウンロード

f:id:KKubo19:20200814145321p:plain

ダウンロードしたmsiファイルをダブルクリックで実行

f:id:KKubo19:20200814145506p:plain

カスタマイズをクリック

f:id:KKubo19:20200814145654p:plain

インストール先の指定やSQLServerを利用する場合は以下の項目をクリック

※不要であればそのままインストールをクリック

f:id:KKubo19:20200814145745p:plain

今回サインオン方式は推奨の「パスワードハッシュの同期」としています。

この違いについても上記記載のMicrosoftの方の資料に記載があります。(神かよ!)

f:id:KKubo19:20200814145851p:plain

AzureAD(Office365)のグローバル管理者のアカウントIDおよびパスワードを入力

f:id:KKubo19:20200814150201p:plain

オンプレADの情報追加

フォレストより対象のドメインを選択して「ディレクトリの追加」をクリック

f:id:KKubo19:20200814150306p:plain

オンプレADのエンタープライズ管理者(EnterPrise Admin)のユーザー情報を入力しOKをクリック

f:id:KKubo19:20200814150434p:plain

構成済みディレクトリに反映されていることを確認し次へをクリック

f:id:KKubo19:20200814150534p:plain

ユーザープリンシパル名のプルダウンでADユーザーのどの属性を利用してAzureADのIDを生成するかを決めます。

※ADドメイン(test.local)はAzureAD(Office365)のカスタムドメインとして存在していないので、以下画面のような警告が表示されます。

今回は別理由にてADユーザーのMail属性(電子メール)を利用したのでこのまま進みます。

userPrincepalNameで同期を実施する予定があり、ADとAzureADのUPNサフィックス(ドメイン名)が違う場合は、事前にADサーバーにてUPNサフィックスを追加し同期する各ADユーザーの情報を修正する必要がありますので、注意してください。

手順は下に記載します。

ADドメイン(test.local)、AzureADカスタムドメイン(test.co.jp)のような環境でUPNサフィックス追加なしでUserPrincicalNameでUserA@test.local(test\UserA)の同期を実施するとUserA@xxx.onmicrosoft.comというアカウントとしてAzureADに作成されます。

 

f:id:KKubo19:20200814150751p:plain

変更前

 

f:id:KKubo19:20200814151607p:plain

変更後

特定のOU配下のみIDを同期するかどうかを指定できます。

今回はOffice365というOUの配下にUsersとComputersというOUを作成し、その中にいるユーザーやコンピューターのみAzureADに同期をさせます。

HAADJではコンピューターオブジェクトを同期する必要があるため、OU「Office365」内のOU「Computers」にコンピューターオブジェクトを配置しています。

※以下図は参考情報

f:id:KKubo19:20200814153946p:plain

「選択したドメインとOUの同期」をクリックし、その配下の同期するOUのみにチェックをつけ、次へをクリック

 

※個人的には特定OUだけ同期するとしておいた方が、ADにはユーザーを作成したいが、Office365側は不要みたいなケースに対応できるのでいいのかな?って思っています。同期した後Office365側だけユーザーが不要になったときに同期対象OUからユーザーを移動するとOffice365側のユーザーのみが削除されるので、ADユーザーだけは残すってこともできます。

f:id:KKubo19:20200814151950p:plain

ADユーザーとAzureADユーザーのマッチを何で実施するかを指定しています。

今回はADユーザーのメール属性をAzureADユーザーのIDとして同期しているのでこのまま次へをクリック

f:id:KKubo19:20200814152328p:plain

今回フィルターを利用しないので次へをクリック

f:id:KKubo19:20200814152541p:plain

オプション機能の設定画面です。

デフォルトで同期されるユーザー情報に加えて追加で情報を同期したい時などは、このオプションから追加属性を指定します。

今回は実施しないので次へをクリック

f:id:KKubo19:20200814152633p:plain

そのままインストールをクリック

※AADCの冗長化を実施する際は、ActiveなAADCは1台である必要があります。

 2台目以降の構築では以下の「ステージングモードを有効にする」にチェックを入れてインストールします

f:id:KKubo19:20200814152905p:plain

終了をクリック

f:id:KKubo19:20200814153202p:plain

ここまでで、AzureADConnectのインストールは完了です。

この項目まで終わるとADユーザーがAzureADに同期されます。

 

2.HybridAzureADJoined設定

デスクトップに作成されたAzureADConnectをダブルクリックで実行

f:id:KKubo19:20200814153524p:plain

構成をクリック

f:id:KKubo19:20200814153606p:plain

バイスオプションの構成を選択し次へをクリック

f:id:KKubo19:20200814154129p:plain

次へをクリック

f:id:KKubo19:20200814154207p:plain

AzureADのグローバル管理者のアカウントを入力

f:id:KKubo19:20200814154855p:plain

ハイブリッドAzureAD参加の構成を選択し次へをクリック

f:id:KKubo19:20200814154913p:plain

「Windows10以降のドメインに参加しているデバイス」にチェックを入れ次へをクリック

f:id:KKubo19:20200814155002p:plain

対象のフォレストにチェックを入れ追加をクリック

f:id:KKubo19:20200814155053p:plain

エンタープライズ管理者(EnterPriseAdmins)のユーザー情報を入力

f:id:KKubo19:20200814155124p:plain

次へをクリック

f:id:KKubo19:20200814155201p:plain

構成をクリック

f:id:KKubo19:20200814155232p:plain

終了をクリック

f:id:KKubo19:20200814155300p:plain

以上でHybridAzureADJoinedの設定が完了です。

 

3.ADユーザーの情報変更

上記「HAADJの動き」にて記載したように今回はADユーザーのプレフィックスおよびサフィックスがAzureAD(Office365)と違うことを想定しているので、子の変更も実施します。

ADサーバーにて「ActiveDirectory ドメインと信頼関係」をクリック

f:id:KKubo19:20200814162708p:plain

ActiveDirectory ドメインと信頼関係を右クリックし、プロパティをクリック

f:id:KKubo19:20200814163100p:plain

AzureAD(Office365)で利用するカスタムドメインを追加

※今回はtest.co.jpとしています。

f:id:KKubo19:20200814163215p:plain

f:id:KKubo19:20200814163323p:plain

この設定(UPNサフィックス追加)を実施するとADユーザーはサフィックス設定にてtest.co.jpが選択できるようになります。

ActiveDirectoryのユーザーとコンピューターを起動し、変更対象のユーザーのプロパティを表示します。

f:id:KKubo19:20200814163626p:plain

以下のようにプレフィックスを「1234」から「ユーザーA」サフィックスを「test.local」から「test.co.jp」に変更します。

f:id:KKubo19:20200814163724p:plain

これでこのユーザーはWindowsに「ユーザーA@test.co.jp」でログオンできるようになり、HAADJが成功します!!

~2020/08/20追記~

上記状態ならtest\1234でログオンしてもHAADJ成功した!!

~~~~~~~~~

f:id:KKubo19:20200818175403p:plain

 

え!!!!!これ全ユーザーやるの??ってなりますよね・・・・笑

それはめっちゃ大変なので、次回は「PowershellでADユーザーのUPNプレフィックスおよびサフィックスを一括変更する」を書きたいと思います!

 

上記内容は以下に書いておきました。

kbtblog.hatenablog.com

 

 

やってみたけど、うまくいかないよって場合はJapan Azure Identity Support Blogにトラブルシューティング手順があるので非常に参考になると思います(相変わらず丁寧な記載なのでマジ助かる!)

https://jpazureid.github.io/blog/azure-active-directory/troubleshoot-hybrid-azure-ad-join-managed/

 

  • 最後に

Twitterでも情報発信したいと思いますので、興味があったらフォローしてください!











 




 

ActiveDirectoryとOffice365のID同期で起きた事件(利用開始済みOffice365ユーザーとADユーザーの同期)

こんにちは!

よくあるお話なのですが、Office365を利用するにあたってオンプレのActiveDirectoryとOffice365(AzureAD)のID同期をしたい!!ってことが。。。。

実際それ自体は推奨されていますし、ID管理の上でも実施すべきだな~って僕自身思います!!

 

今回そんなID同期にて事件発生!(ただの障害なんですが。。。笑)ってことで何がおきたのかとどうすべきだったかを記載して

Office365とADの同期を後から実施することに悩まれてる方がいらっしゃったら参考にしていただけると嬉しいです。

 

そしてなにより言いたいのは

お願いだからOffice365の利用開始時にオンプレADとOffice365のID同期やっといて」ってこと!!笑

 

今回記載する内容は「Office365もオンプレActiveDirectoryもID同期なしで利用スタートしちゃって今からID同期やりたいよ!!!!!」ってパターン

  

  • トラブった内容

今回のケースのご紹介です。

  1. すでにオンプレActiveDirectoryとOffice365をID同期なしで利用
  2. Microsoft365利用のためにオンプレActiveDirectoryとOffice365のIDを同期したい要件が発生(最終的にはHybridAzureADJoined構成)
  3. Office365ではExchange Online,SharePoint Onlineを利用中
  4. Exchange OnlineではAliasを利用 ←今回これを見逃しました

今回の構成ではオンプレActiveDirectoryとOffice365(AzureAD)間のID同期はAzureADConnectサーバー2台を導入して同期します。

AzureADConnectサーバーは冗長化する場合、1台を「Active」1台を「Staging Mode」として構成します。

※細かいお話は割愛します。知りたいよってかたがもしいたらコメントください。

 

そもそもオンプレActiveDirectory(以後AD)とOffice365をあとから同期する場合、ユーザー間の紐づけが必要となります。

ソフトマッチやハードマッチといったマッチング方法があるのですが、

今回はソフトマッチを利用しています。

ソフトマッチって何かというと、ADのID情報(AzureADConnectを構築時に指定するパラメータ)とOffice365のID(UserPrincipalName)が一致していたら同一ユーザーとみなして、同期するよってこと!

今回その情報にAD側は「Mail」属性を利用しています。※これを代替IDって呼んだりします。

AzureADConnectのインストール画面にて以下の通り構成しています。

f:id:KKubo19:20200807151320p:plain

f:id:KKubo19:20200807151443p:plain

f:id:KKubo19:20200807151610p:plain

これ失敗するとOffice365に別ユーザーとして複製されてしまい後戻りできないので実施する場合は慎重にやってくださいね!!!(状況によってはなんとかなりますが)

余談ですが、「HybridAzureADJoined」を完了するためにはオンプレActiveDirectoryの「UserPrincipalName」とOffice365の「UserPrincipalName」が一致していないといけないので、HybridAzureADJoinedを利用するよって場合は代替UPNサフィックスを利用してください。

この辺もいつの日か書けるといいなあ。

 

さらにADとOffice365(AzureAD)間でID同期すると同期したユーザーの情報はADでしか変更することができなくなります。

※現在ExchangeOnlineで利用している値をAD側で変更するためにはAD側にExchangeスキーマ拡張が必要になるケースが多々あるので、事前に利用している値を確認してくださいね!

ありがちな値は「ユーザーをアドレス帳から非表示にする」という項目です。

これはExchangeスキーマ拡張してないとADで操作できないのでご注意ください。

f:id:KKubo19:20200807144911p:plain

 

以下のパターンの時(作業前状態図)でも色々考えないといけないことがあります。

f:id:KKubo19:20200804184834p:plain

作業前状態図


上記図をみていただくとざっとこんな問題が。。。。。。。。。。。

  1. ADのドメインが「test.local」
  2. ADとOffice365で「UserPrincipalName」「DisplayName」「部署名」が違う
  3. ExchangeOnlineで上司情報を利用している(メールルールで上司をCCに強制追加等)
  4. (補足)図では分からないのですが、Office365側のユーザーがOffice365管理者の管理者になっていると同期エラーになります。※一度管理者権限を外し、同期を終えてから再度管理者権限を付与してください。

順番に解説していくと

・1について

ADのドメインが「.local」だったとしても、Office365側も「.local」ってことはありえません。

世の中に「.local」なんてドメインがないからです。通常Office365で作成するカスタムドメインは「co.jp」や「.com」だったりします。なので、ADの「UserPrincipalName」を利用してOffice365に同期するとADとドメインが違いただしくユーザー同期をしてくれません。※今回はそもそもADとOffice365の「UserPrincipalName」の情報がずれているのでNGですが・・・・・

 

・2について

ADとOffice365を同期するとADの情報でOffice365のユーザー情報を上書きします。

そのため、事前にどちらの値を利用していくか決定しておく必要があります。

※今回はOffice365のユーザー情報を利用することとしました。

ADの「UserPrincepalName」をOffice365に合わせるために、代替UPNサフィックスというものを利用しています。

 

・3について

ExchangeOnlineにてユーザーの上司の情報を利用している場合、ADとID同期すると上司の情報もAD内で設定し同期する必要があります。

しかし、ADで上司設定を使用とすると、フリー入力ではなくAD内のオブジェクト検索でヒットしたものが登録されます。そのため、上司をメールアドレスで検索できず、Office365への登録した際も正しい状態とならないことが想定されます。

※2での対応にも記載の通り、代替UPNサフィックスを利用してADの「UserPrincipalName」をメールアドレスの状態とすることでオブジェクト検索でメールアドレス形式で検索してもヒットするようになります。

 

色々記載しましたが、結局どうしないといけないかというとこんな感じ「下図(同期直前状態)」です。

ADのユーザー情報を下図の通り変更してから、AzureADConnectを利用して同期します。

f:id:KKubo19:20200804192045p:plain

同期直前状態

しかし!!!!!!!!

ここで今回の僕の大きな見落としが!

実はExchangeOnlineでメールエイリアスを利用していたのです。。。。

メールエイリアスとは別名としてメインのメールアドレスとは別に受信のみできるメールアドレスを保有するイメージです。

f:id:KKubo19:20200804192315p:plain

同期前の見落とし


その状態でユーザー同期を実施したために。。。。。。。。。。

Office365側のメールエイリアスが全ユーザー分消えた。。。。。。。。。。

きえた。。。。。。。。。。。これは事件だ。。。。。。

この事件俺が必ず解決して見せる!じっちゃんの名にかけて!

ふざけてすみません。ほんとに焦りました。

f:id:KKubo19:20200804192637p:plain

見落とした状態での同期

今回のケースでどうしておかないといけなかったかというと、

AD側の「ProxyAddresses」という属性値にプライマリメールアドレスとセカンダリメールアドレスを登録しておく必要がありました。。。。。

f:id:KKubo19:20200807152116p:plain



下図「正しい状態(同期前)」の状態にしておくのが正しい状態でした。。。。

今回は事前にユーザーの情報を取得しておいたのでその情報をもとにデータを戻していきました。

f:id:KKubo19:20200804194011p:plain

正しい状態(同期前)

ADの「ProxyAddresses」という属性に「SMTP:メインのメールアドレス」「smtp:Alias用メールアドレス」として登録することで正しく同期されます。

SMTP:」がメイン、「smtp:」がエイリアスと覚えてください。

f:id:KKubo19:20200807152306p:plain

 

考えるべき内容をざっとまとめてみました。

f:id:KKubo19:20200807150511p:plain


  

実施すべき内容は以上です!!!!

が、これって1ユーザーずつやってるとめっちゃ大変なのでは????

って思いますよね

ここでPowershellを利用することで一括登録できます。

※今回はProxyAddressesのみを登録するスクリプトをご紹介します。

需要あればそのうち、UserPrincipalNameやその他値の一斉変更も書こうかな

 

 

ADユーザーの情報変更は以下のコマンドレットを利用します。

 Set-ADUser

今回はProxyAddressesに登録するのでこんな書き方です。

 Get-ADUser -SearchBase "CN=Users,DC=test,DC=Local" -Filter {UserPrincipalname -eq "ユーザーA@test.co.jp" } | Set-ADUser -Add @{"ProxyAddresses"="SMTP:メインメールアドレス","smtp:サブメールアドレス"} 

 「-SearchBase」は設定変更するユーザーの検索先OUもしくはCNを指定します。

例では[test.local]内のUsersコンテナ配下を検索するように記載しています。

※例えば下図の「Office365内のUsers」を指定したい場合は「OU=Users,OU=Office365,DC=test,DC=Local」となります。

f:id:KKubo19:20200807153720p:plain

ただ、複数ユーザーでこれを実施したいので!!

まずはcsvデータを作成します。

SMTPData.csvという名前で作成しています。

f:id:KKubo19:20200807154636p:plain

変更が必要なユーザー分記載します。(同一OUもしくはCNにいるユーザーである必要があります)

上記ファイルをADサーバ上の以下のフォルダに保管します。

「C:\temp\UPN\SMTPData.csv

 

以下内容をスクリプトとして作成します。

#検索対象OU指定
$Searchtarget = "CN=Users,DC=test,DC=Local"

#import用CSVの指定
$Data = "C:\temp\UPN\SMTPData.csv"

#データのインポート
$UserDatas = Import-Csv -Path $Data -Encoding Default

#インポート情報のループ
foreach($User in $UserDatas){
 
        #ユーザー情報のセット
        $Setinfo = 'Get-ADUser -SearchBase $Searchtarget -Filter {UserPrincipalname -eq "' +  $User.UPN + '" } | Set-ADUser -Add @{"ProxyAddresses"="' + $User.Primary + '","' + $User.Second + '"}' 
        Invoke-Expression $Setinfo
}

$Searchtarget = "CN=Users,DC=test,DC=Local" と記載のある箇所は

実際に情報変更したいユーザーが格納されている場所を指定してください。

※1 csvファイルの文字コードを[Shift-JIS]想定で8行目を -Encoding Defaultとしています。違う場合は修正してください。

※2 今回はProxyAddressesに追記する想定のため、14行目で -Addとしていますが、データを置き換えたい場合は-Addではなく-Replaceと記載してくださいね!

f:id:KKubo19:20200807155350p:plain


CSVファイルに変更が必要なユーザー分データを用意して上記スクリプトを実行することで一斉に変更をかけることができます!

前回に引き続きforeachを利用しています。

とても便利なのでぜひ使ってみてくださいね!

 

  • 最後に!

Twitterでも情報発信したいと思いますので、興味があったらフォローしてください!