2024年9月

2024年9月10日 (火)

Adobestock_715101192

Microsoft 365 用の PnP PowerShell とCLI の登録方法が 2024年9月9日より変更されました。

アナウンスされたのが2024/8/22ですから、期限まで1か月もなく、バタバタと対応を迫られたのでまだご存じない方もいるかもしれません。早くブログに書いておこうと思ったものの先週の週末に検証がずれ込み、今日改めて記事にしています。

経緯

以前は、PnP Management Shell はマルチテナントアプリ登録の仕組みを利用してスクリプトに必要な権限を付与することができました。しかし、このマルチテナントアプリ登録は2024年9月9日に削除される予定であり、既存のスクリプトに影響を与える可能性があります。マルチテナントアプリ登録オプションは、オンボーディングする上では非常に有効だったものの、結果的に付与されるスコープが多すぎる問題が生じました。そのため、より少ない権限に絞れるように今回の対応となったという経緯があるようです。

新たな変更では、必要なスコープと権限のみを使用するシングルテナント アプリの登録を推奨します。これにより、セキュリティ対策の強化と改善が見込まれます。ただ、以前と同じくシングル テナント登録にはテナント管理者であり、Entra ID 側で必要な権限を持っている必要があります。

つまり、マルチテナント認証オプションに依存する既存スクリプトは2024年9月9日以降この変更の影響を受けるということです。

既存のスクリプトはどうなる?

シングルテナントアプリケーションの登録により認証が変更された後でも既存のスクリプトは動作します。認証/接続セクションを更新する必要があるかもしれませんが、どのコマンドレット/コマンドも同じように動作します。

インストールとアプリの登録

さて、シングルアプリケーションとしての登録方法について説明していきましょう。PnP Management Shell に関しては、Microsoft Community Learning グループがすでに YouTube に「Getting started with PnP PowerShell - Installation and app registration」としてインストールおよび登録方法についてビデオ解説しています。英語のみです。詳しくデモ付きで説明されているので、しっかり閲覧して手順を確かめるようにしましょう。CLIの方は Coming soon だそうです。


YouTube: Getting started with PnP PowerShell - Installation and app registration

ここからはビデオを見る前にどんな手順になるのかを概略説明しておきましょう。基本手順は次の通り。

  1. PnP Management Shell モジュールのインストール (インストールしていなければ)
  2. Entra ID への App Only アプリの登録
  3. インタラクティブ ログイン用の登録

なお、使用する PnP Managment Shell は 2.10以降が必要です。

インストール

PnP Management Shell モジュールをインストールしてない場合は install-module コマンドを実行します。インストールには PowerShell 7.2 以降が必要です。20240906_162646

必要に応じて -Force オプションを指定して実行してください。

20240906_162953

その他の詳細は下記のリンク先を参照してください。

Installing PnP PowerShell | PnP PowerShell

Entra ID へのアプリケーションの登録

Entra ID へのアプリ登録の詳細は下記に掲載されています。日本語版はありませんので必要があれば日本語に翻訳して読む必要があります。

Register an Entra ID Application to use with PnP PowerShell | PnP PowerShell

以降は主要なポイントのみピックアップしていきます。

非インタラクティブなログイン

接続時に非インタラクティブなログインを行う場合は、Register-PnPEntraIDApp コマンドを使って新たにシングル テナント アプリケーションを作成します。※Register-PnPEntraIDApp は Register-PnPAzureADApp の別名です。コマンドを調べる際には最終的にRegister-PnPAzureADAppの説明ページにたどり着きます。

Register-PnPAzureADApp | PnP PowerShell

たとえば次のコマンドを実行します。

Register-PnPEntraIDApp -ApplicationName <アプリ名> -Tenant <テナント名> -Interactive

このコマンドはアプリ登録時に実行パスに証明書(pfx, cer)を生成します。接続時の認証方法はいくつもありますが、この場合はサービスに続する際にこの証明書を使ってサインインすることも可能です。これによりインタラクティブにユーザー認証の情報を毎回渡す必要がなくなります (Non interactive Authentication)。またアプリのみのコンテキストとしての登録となり、スクリプトはユーザーの介入なしに実行できます。つまり、アプリに対して権限を付与すれば実行ユーザーがサイトに対してアクセス権限を持っていなくても良いということになります。

なお、管理者がユーザーにかわって作成した場合は、pfx をユーザーに渡したうえで次のように pfx をインポートしてもらう必要があります。

Import-PfxCertificate -FilePath "path\to\certificate.pfx" -CertStoreLocation Cert:\CurrentUser\My

インタラクティブログイン

接続の度にインタラクティブログインする場合はアプリ登録時に Register-PnPEntraIDAppForInteractiveLogin コマンドを使用してアプリを登録します。この場合は委任ログインとなります。ユーザーが持っているアクセス権限に基づいて操作は制限されます。

Register-PnPEntraIDAppForInteractiveLogin | PnP PowerShell

アクセス権限

基本的には Entra ID アプリケーションに対して最低限必要な権限を付与することが強く推奨されています。たとえば、Register-PnPEntraIDAppを上記のコマンド通りに実行すると次のように必要な権限が要求されました。

20240910_135521

登録されたアプリでアクセス権限を改めて確認すると次の通りであり、基本的にアプリに対してフル権限が付与されます。

  • Microosft Graph 
    • Group.ReadWrite.All
    • User.ReadWrite.All
  • SharePoint
    • AllSites.FullControl
    • Sites.FullControl.All
    • User.ReadWrite.All


20240910_140909

Register-PnPEntraIDApp コマンドおよびResister-PnPEntraIDAppForInteractiveLogin では既定の制限された権限が付与されますが、特定の権限に明示したい場合は次のようなパラメーターを指定できるようになっています。

  • SharePointApplicationPermissions
  • SharePointDelegatePermissions
  • GraphApplicationPermissions
  • GraphDelegatePermissions

Client ID

登録時に最後に表示される Client ID は接続のたびに指定することになるので控えておきましょう。なお、Client ID は接続のたびに必要になるため、これが煩わしいようならシステム環境変数として登録しておくようにしましょう。手順は次のリンク先に詳しく書かれています。

Set a default Client ID | PnP PowerShell

ちなみに、先に紹介した YouTube の手順では$env:ENTRAID_APP_ID = "XXX" というような環境変数を使っていますが、これは当該セッションで使う一時的なもので永続的なものではありませんので注意してください(この辺はてっちゃん(@techan_k)さんに別途、情報提供いただきました。ありがとうございます!)。

登録されたアプリの確認

コマンド実行後は Entra ID にアプリ登録が無事に登録されていることがわかります。接続時に必要な クライアントIDも確認できます。

 

20240906_173834

接続

では接続してみましょう。次のように証明書を使う場合は、非インタラクティブ認証を利用できます。接続先は任意のSharePoint サイトのURLなどです。

connect-PnPOnline -Url <テナント>.sharepoint.com -ClientID <クライアントID> - CertificatePath <証明書(pfx)へのパス>

インタラクティブログインの場合は、次のように指定します。

connect-PnPOnline -Url <テナント>.sharepoint.com -ClientID <クライアントID> -Interactive

他にも特定のデバイスやブラウザーを指定するなど複数の認証方法があります。詳しくは下記のリンク先を確認するようにしてください。

Authentication | PnP PowerShell

関連情報

2024年9月 6日 (金)

Adobestock_261207157

2024年8月22日付で次の更新機能がアナウンスされました。

  • 受信者への取り消し通知のオプション
  • 取り消し可能なメッセージ世代の最大値
  • 外部ラウンド トリップルーティング

Exchange Online Message Recall Updates - Microsoft Community Hub

受信者への取り消し通知のオプション

これまで組織内のユーザー宛のメールは送信主が相手に知らせることなく送信済みメールをこっそりと取り消すことができていました。とはいえ、一度、受けとったことを目にしているユーザーもしくは一度目を通したユーザーにとっては「あれ、あったはずのメールがない!」ということになり混乱を招くこともあったのです。

そんな背景から、新たにテナント管理者は取消し通知を宛先に指定したユーザーに対して有効にできるようになりました。次の2つのいずれかのオプションを指定できます。

  • 全ての取り消されたメッセージ
  • 受信者が読んだ取り消したメッセージのみ

要するに全社はすべての送信済みメールに対して取り消したことを知らせる。後者は読んだ人にだけ、「あっ、あのメール取り消しましたからね。もうないんですよ」という旨を知らせることができるわけです。

この設定は PowerShellコマンドからも実行できますが、Exchange 管理センターから確認するのがわかりやすいでしょう。まず、[設定]>[メールフロー]の順にアクセスします。

20240904_150431

次に表示される画面から「メッセージの取り消し」セクションにある “受信者のリコール アラートを有効にする” をオンにします。この時に「すべてのリコール済みメッセージ」または「受信者によって読み取られた取り消されたメッセージの場合のみ」のいずれかを指定します。あとは、「保存」を押下するだけです。この設定変更は以上の設定は1時間ほど反映されるまで時間がかかるそうです。

20240904_150444

メッセージを取り消す

では、送信済みのメール(組織内宛て)をメッセージ取り消してみます。

20240904_171657

しばらくすると送信対象者に取り消しを知らせるメッセージが届きます。

20240906_204254

取り消し可能なメッセージ世代の最大値

ちなみに、上記設定の下にある「これより古いメッセージの取り消しを送信者に許可しない」オプションでは、取り消しが可能な送信後の日数を指定できるようになっています。既定値は 365です。最低5分～最大10年まで指定できます。

20240906_201842

外部へのラウンド トリップルーティングのサポート

設計上、メッセージの取り消しは Exchange Online のサービス境界外へと送信されたメッセージの取り消しには対応していません。しかし、一部の管理者は、テナント内のメール（送信者と受信者が同じテナントにある場合）を Exchange Online からサードパーティのサービスまたはオンプレミスのシステムに転送して追加処理を行った後、再び Exchange Online に転送して配信しています。従来では、このシナリオでは取り消しは失敗していました。

ですがアップデートにより現在は外部を経由して Exchange Online に戻って配信されるテナント内メッセージの取り消しもできるようになったそうです。