Teamsのマイクボリュームが制御不能で困る

リモートワークで「Microsoft Teams」を利用している方々も多いのではないでしょうか。また、Webカメラやマイクに拘って、ちょっと高いのを買ってみたりして自己満足に浸っている私のような方もいるのではないでしょうか・・・えぇ、すごく分かりますよぉ~。

マイクのボリュームが上がらない

で、最近、遭遇した現象に「Microsoft Teams」のデスクトップアプリでTeams中に声が聞こえないよぉ~と言われて、よくよく調べてみるとマイクの音量が「0」、或いはとても小さくなっていることがありました。何でだろう?と思って再現を試みたところ、「Teams会議中」に、「デバイスの設定」を開くと、何故かマイクの音量が(私の場合は)「0」になってしまうことが分かりました。(2021年2月現在、再現率100%で、会社の他のメンバーでも全く同じ現象が100%発生しています。)

この「Teams」の「デバイス設定」画面を開いている状態で、OSの「サウンド設定」からマイクのボリュームを確認すると「0」になっており、ボリュームを上げてもすぐ「0」や小さい数値に戻ってしまいます。

マイクのボリューム設定

1.タスクバーの検索窓で「サウンド設定」と入力
2.「入力デバイスを選択する」をクリック
3.表示画面下の「サウンド コントロールパネル」リンクをクリック

4.表示画面の「録音」タブをクリック
5.デバイス(マイク)を選択して「プロパティ」をクリック
6.表示画面の「レベル」タブをクリック

ここでマイクの音量が確認できます。多分、「0」や低い値になってはいないでしょうか?繰り返しになりますが、「Teams」の「デバイス設定」画面が開いている状態だと、ここのボリュームを上げてもすぐ元に戻ってしまいます。よもやよもやだ・・・。

回避方法

「Microsoft Teams」は「マイク音量の自動調整」機能があるようで、そこに起因している可能性があるなど、海外のフォーラムでもこの問題について議論されているようです。で、個人的には「Teamsアプリのバグ」だと思いますよw。だって他のWeb会議ツールではこんなこと起きませんからね。

回避方法ですが・・・「Teamsのデバイス設定画面を閉じている(開いていない)状態で、OSのサウンド設定からマイクのボリュームを上げる」そして、「Teams会議中にデバイス設定画面を開かないこと!」です。これが一番です。海外のフォーラムではマイクデバイスを中継するソフトをインストールする、など回避方法はあるようですが、そのうちTeamsアプリのアップデートで修正されると思うので、大人しく待つのがいいと思っています。

Microsoft 365・AzureAD の監査ログについて

ここ最近、「Microsoft365」と「AzureAD」に関連する案件が増えているような気がします。で、話として多いのがログについての質問です。リモートワーク普及の背景もあり「不正アクセスがないか?」ということを確認したい意図のようです。

私もあまり本気で見たことが無かったのですが、調べたところによると、主だったログには「Microsoft365の監査ログ」と「AzureADのサインインログ監査ログ」があるようでした。

Microsoft365はAzureADと密接に関係しているので、Microsoft365へのアクセスログはAzureAD側にログにも出力されているのかなぁ~と思って見比べてみましたが、一致するログもあるのですが、そうでないログもあるようでした。
(厳密には整合性があると思うのですが、見た目上では、分かりやすいとは言えず・・・例えばログインしただけなのに一方には複数のログが出ているとか、そんな感じです。)

とりあえず「Microsoft365の監査ログ」と「AzureADのサインインログ、監査ログ」を眺めてみます。

Microsoft365 監査ログの表示

1.Microsoft365管理センターにアクセス:https:admin.microsoft.com
2.左メニューの「すべてを表示」-「セキュリティ」をクリック
3.「Office365セキュリティ/コンプライアンス」の左メニュー「検索」-「監査ログの検索」をクリック



ここから監査ログの検索が可能です。保存期間は「90日」との事です。

【参考:コンプライアンス センターで監査ログを検索する】
https://docs.microsoft.com/ja-jp/microsoft-365/compliance/search-the-audit-log-in-security-and-compliance?view=o365-worldwide

Microsoft365の監査ログを眺めてみた

適当な期間をログを検索、表示して実際のログを眺めてみました。
「アクティビティ」は「ユーザーのログイン」、「ファイルのアクセス」などパッと見て分かるものから、「ListViewed」(リストを表示ってことなんだろうけど、それってなに?)など一部英語表示されているものもあるようです。「アクティビティ」は画面右のフィルタで一覧表示されているから、どんなものがあるか分かると思います。

「ユーザーのログイン」では「IPアドレス」が表示されているので、「おや?」と思うアドレスがあったらチェックです。一応、「通知ポリシー」という機能があって、特定の「アクティビティ」が発生した場合、通知が出来るようですが、「外国のIPアドレスの場合」などという条件設定はできないようなので、この画面で怪しいIPアドレスのチェックを行うなら目視しかなさそうです。
(やはりログは別途解析ツールを使って監視や分析するのがいいですね!)

ただし!アクセス元のIPアドレスは正しくない可能性があります!(正確にはアクセス経路が思っているのとは違うという感じです。)良く分からないのですが、「アメリカのシアトル」のIPアドレスがちょくちょく出てます。シアトルと言えば・・・MS本社レドモンドがすぐ近くですね。この後の「AzureADの監査ログ」でも同じログが出ているので、そちらでコメントしています。

ということで、「Microsoft365 の監査ログ」は、細かくログが残ってはいるけど、実際問題、何かあった時に見るための、まさに監査ログという印象です。

それと!ファイルのアクセスでユーザーが「app@sharepoint」となっているログを見かけるかも知れません。そんなユーザー作った覚えがないのに・・・と思って調べてみたらどうやらバックグラウンドで、システム的に何かやっている時に出るユーザーみたいです。海外のフォーラムを見たら、バグ?のようでそのうち修正される、とのコメントがありました。

AzureAD ログの表示

1.AzureADポータルにアクセス:https://portal.azure.com
2.「ホーム画面」から「Azure Active Directory」アイコンをクリック

3.管理画面左メニューの「監視」カテゴリにログ関連が集約されています。


「サインイン」・・・ログイン関連が集約されています。
「監査ログ」・・・ユーザー/グループの作成、デバイス登録など様々なアクティビティが記録されてます。

【参考:Azure Active Directory ポータルのサインイン アクティビティ レポート】
https://docs.microsoft.com/ja-jp/azure/active-directory/reports-monitoring/concept-sign-ins
・AzureADのサインインログについての説明が記載されています。

【参考:Azure Active Directory ポータルの監査アクティビティ レポート】
https://docs.microsoft.com/ja-jp/azure/active-directory/reports-monitoring/concept-audit-logs
・AzureADの監査ログについての説明が記載されています。


ログの保存期間は購入しているライセンスによって異なるようですが、最大でも30日なのは短いですね。そのため、Azureのストレージに定期保存する機能や、3rd Party製品にログを転送する機能が提供されています。



【参考:チュートリアル:Azure AD のログを Azure ストレージ アカウントにアーカイブする】
https://docs.microsoft.com/ja-jp/azure/active-directory/reports-monitoring/quickstart-azure-monitor-route-logs-to-storage-account
・Azure Blob Storage にアーカイブする手順が記載されています。

【参考:Azure Monitor での Azure AD のエンタイトルメント管理に関するアーカイブ ログとレポート】
https://docs.microsoft.com/ja-jp/azure/active-directory/governance/entitlement-management-logs-and-reporting
・Azure Monitorでログを可視化するための手順が記載されています。

AzureADのログを眺めてみた

AzureADの「サインイン」ログと「監査ログ」を眺めてみました。

「サインイン」ログは「IPアドレス」や「場所」、「アプリケーション」など割と分かりやすいログに見えます。ただ、「場所」は正確ではないかなぁ~と思います。東京にいるのに北海道と表示されたり、アメリカのシアトル(MS本社のレドモンドに近いな)だったり・・・「Microsoft Teams Web Client」のアクセスはシアトルになることが多いような気が。。。詳しく調べてみるとIPアドレス的にそもそも場所が間違っていたり、IPアドレス自体は確かにアメリカのシアトルだったりと、いまいち良く分からないですね。最初はもしかしたらアカウントが漏洩!?と心配になりましたが、どうやらそうでは無さそう・・・何でしょうね??

ユーザーのログインに関して言えば、「Microsoft365の監査ログ」よりこちらの方が見やすく分かりやすい気がします。ログの「アプリケーション」については1ヵ月ぐらい運用して取得したものが以下です。「Microsoft Teams Web Client」は、まあブラウザでTeams開いたんだろうなと。。。その他、分かるものもあれば、「何だこのアプリ?」というのもありました。

「監査ログ」ですが、まあ、こんな感じなのかな・・・「Update Device」など端末登録時に出るログは「端末名称」が表示されるので、「この端末がAzureADに登録されたんだな」と分かるので有意義なログだと思いました。その他は何かあった時のためのログですかね。以下は1ヵ月ぐらい運用して取得したサンプルログです。

監査ログの「アクティビティ」は比較的に分かりやすい気がします。また遭遇していない文字列が、まだまだたくさんあるのだと思いますが。

まとめ(所感)

「Microsoft365の監査ログ」、「AzureADのサインインログ/監査ログ」を眺めてみましたが、Web画面で見る範囲で言えば、普段は「アクセス元のIPアドレスを定期的にチェックする」というのが有意義な使い方なのかな、と思いました。それと、クラウドサービスのログは保存期間が短いので、別のストレージなどに転送するのが良いですね。

理想を言えば、「Azure Monitor」が参照できる「Log Analytics ワークススペース」にログを保存して、監視や分析、可視化をするのがいいですね。ただ、「Azure Monitor」はリアルタイムでログを監視するような用途には向いていないようで、そのような必要がある場合には、「Azure Event Hub」でログを他のツールにストリーミングして、そちらでリアルタイム監視を行うのが良いそうです。

今回はここまで。


Office365動的グループをPowerShellで操る

Office365 動的グループとは?

Office365の動的グループはルールを書くとその条件に従って自動的にメンバーを追加、削除することができる、とても便利な機能です。例えば、「所属部署が営業であれば、営業グループに所属させる」などです。

通常、このグループの作成やメンバーの出し入れはID管理システムで実施することがほとんどだと思いますが、この「Office365動的グループ」を利用すると、ID管理システム側の負担が軽減できます(グループ、メンバーって面倒なので、かなり工数を省力化できる機能だと思います!)。

Office365には「セキュリティグループ」や「配布グループ」があり、機能が一部被っています。そのため、これは個人的な予想ですが、今後は「Office365グループ」に集約されていくんじゃないかなぁ~と思っています。

PowerShellを起動して準備する

PowerShellはWindows10に標準で搭載されています。検索で「PowerShell」と打つと、幾つか候補が表示されますが、実行するのは「Windows PowerShell ISE」を「管理者として実行する」(不足しているコマンドをインストールするため)がお勧めです。

必要なモジュールをインストールする

今回は「Office365動的グループ」と作成したグループを「Microsoft Teams」にも表示させたいと思います。「Office365動的グループ」を利用すると「Microsoft Teams」の「チーム」からユーザーが勝手に脱退することが出来ない、など制御することができます。

起動しているPowerShellウィンドウで以下のコマンドを実行してください。
※ExchangeOnlineのコマンドはよく使うので一緒に入れちゃうだけです。

1.「Install-Module MSOnline」 /* Azure AD関連のコマンド */
2.「Install-Module ExchangeOnlineManagement」/* ExchangeOnline属性に関するコマンド */
3.「Install-Module MicrosoftTeams」/* MicrosoftTeams関連のコマンド */
4.「Install-Module AzureADPreview] /* Office365動的グループ関連のコマンド */

・NuGet プロバイダーをインストールするようにメッセージが表示されたら、「はい」を選択します。
・PSGallery からモジュールをインストールするようにメッセージが表示されたら、「はい」を選択します。

注意点として、「AzureAD」のモジュールが既に導入されている場合、「AzureADPreview」と競合するため、「Uninstall-Module AzureAD」で削除すること。後で必要になったらInstallすれば良いので、割と手軽にInsatll&Uninstallしても大丈夫です。

「Get-Module -ListAvailable | Select-Object -Property Name,Version,Path」で「AzureAD」モジュールが無いことを確認すること。

画面ショットでは「AzureAD」のモジュールが(バージョン違いが2つも)入っているので、この状態で「AzureADPreview」をインストールするとエラーになります。

最終的に目的のモジュールがインストールされているか(↓こんな感じで導入したモジュールが存在しているか)確認してみてください。

インストールしたモジュールをインポートする

必要なコマンドをインストールしたのに「インポート」するってどういう事?って最初思いましたが、モジュールはインストールしたけど、実際に使うときは必要なものをインポートして使ってね、という事らしいです。PowerShellのバージョンが古い場合、インポートしないとコマンドが利用できなかったらしいですが、最近のバージョン(v3.0以降)では、コマンドを実行した場合、利用できるコマンドがインストールされていれば、暗黙的にインポートされるようです。なので、最近は明示的にインポートしなくても良いらしいですが、やっておいた方が安心らしいです。よもや、よもやだ。。。

1.「Import-Module MSOnline」
2.「Import-Module ExchangeOnlineManagement」
3.「Import-Module MicrosoftTeams」
4.「Import-Module AzureADPreview」

Office365動的グループを作成する

Office365の動的グループをPowerShellから作成するコマンドを記載します。最初に(静的)Office365グループを作成して、その後、動的に変更することもできます。それと「xxx-AzureAdMsGroup」コマンドを利用するためには最初にAzureADに接続する必要があります。

AzureADに接続
Connect-AzureAD

Office365の作成(静的グループ)
New-AzureADMSGroup -DisplayName “テストグループ01” -GroupTypes “Unified” -MailEnabled $True -MailNickname “Test01” -SecurityEnabled $True

※「-MailNickname」→ グループのメールニックネームを指定します。MailEnabledが$ Falseの場合でも、メールのニックネームを指定する必要があります。

Office365の静的グループを動的グループに変更
Set-AzureAdMsGroup -Id “グループのオブジェクトIDを指定” -GroupTypes @(“Unified”,”DynamicMembership”) -MembershipRule “(user.department -eq “”営業””)” -MembershipRuleProcessingState “on”

Office365の動的グループを静的グループに変更
Set-AzureAdMsGroup  -Id “グループのオブジェクトIDを指定” -GroupTypes @(“Unified”) -MembershipRuleProcessingState “Paused”

最初からOffice365動的グループを作成する
New-AzureADMSGroup -DisplayName “テストグループ02” -GroupTypes @(“Unified”,”DynamicMembership”) -MembershipRule “(user.department -eq “”営業””)” -MembershipRuleProcessingState “on” -MailEnabled $True -MailNickname “Test02” -SecurityEnabled $True

動的ルールの演算子などはこちらを参照
【Azure Active Directory の動的グループ メンバーシップ ルール】
https://docs.microsoft.com/ja-jp/azure/active-directory/users-groups-roles/groups-dynamic-membership

動的グループは利用するメンバーの数分「AzureAD Premium1」のライセンスが必要ですが、実際は「AzureAD Premium1」を1つでも購入していれば、動的グループは利用できます(ライセンスが割当ってないユーザーも動的グループで自動的に割り振られる事を確認しています)。現状ではこの辺りのライセンス縛りは紳士協定的なのかもしれません(ライセンス違反はダメですよ!)。

Office365動的グループをTeamsに表示させる

Microsoft Teamsの「チーム」を作成すると裏では対応する「Office365グループ」が作成されています。逆にPowerShellで「Office365グループ」を作成し、Teamsに表示させるようにする事もできます。

そして、重要なポイントは「Office365動的グループ」をTeamsの「チーム」として利用すれば、ユーザーは自身の属性によって、自動的に「チーム」に参加できる点です。更に、ユーザーは所属している「チーム」から勝手に脱退することもできません。

詳しくは以前の記事「Office365の動的グループなどについて」を参照ください。

「Office365グループ」をMicrosoft Teamsの「チーム」に表示するためのPowerShellを記載します。最初に「MicrosoftTeams」に接続する必要があります。

Microsoft Teamsに接続
Connect-MicrosoftTeams

Team作成:Microsoft365グループを指定する
New-Team -GroupId “グループのオブジェクトIDを指定”

Team削除:Microsoft365グループを指定する
Remove-Team -GroupId “グループのオブジェクトIDを指定“

実際にTeamsアプリに「チーム」が表示されるまでに時間がかかりました。(体験的には1時間ぐらいでしょうか。)すぐに表示されない場合も焦らず暫く待ってみてください。

その他気付いた事

・Office365動的グループの振り分け条件にはアカウントの属性のみ利用可能。
・条件式ではアカウントの拡張属性「extensionAttribute1~15」も利用可能。
・条件式(条件部分)の合計文字数が 2,048 文字を超えないようにとのこと。
 (MSさんはそう言ってますが、実際は3,072文字まで大丈夫でした。)
・動的グループのメンバーにグループを含めることはできない。
・動的グループへのメンバーシップ反映には時間がかかる(最大2時間ぐらい?)
・メールが有効なセキュリティグループは動的グループに変更できない。

・利用するPowerShellコマンドはなるべくモジュール間を跨らないように設計したい。
 例えば、セキュリティグループをExchageのコマンドで作成して、その後、AzureADの
 コマンドで動的グループに変更するような作成手順を踏んだ場合、AzureAD側に
 作成したグループが反映までタイムラグ(1時間ぐらい?)があるので、結構難しい。

・Office365動的グループでもライセンス付与ができる。
 【Azure Active Directory のライセンス管理にグループを使用する際のシナリオ、制限、および既知の問題】
 https://docs.microsoft.com/ja-jp/azure/active-directory/enterprise-users/licensing-group-advanced
 グループのネストでは、下位グループにライセンス付与できないなど、制限事項を確認してみてください。

今回はここまでとします。

フェデレーション環境下のおける「Adobe CC のデスクトップアプリ」の挙動について

最近、「Adobe Creative Cloud」とのフェデレーション案件が多く、いろいろと触る機会が多くなってきました。その中で、「Adobe CC のデスクトップアプリ」ってWebアプリじゃないけどフェデレーション環境下でどのように動くのか?という質問が多いため、以下に挙動(画面遷移)をまとめておきます。

 

アプリケーション パッケージの作成

管理者は「Illustrator」や「Photoshop」などのアプリケーションを1つのインストールパッケージにしてユーザに提供することが多いと思います。「Adobe Admin Console」でパッケージを作成する際、「ブラウザベースのログインを有効化」する項目にチェックを入れてください。デフォルトではチェックは入っていません。ここを有効化すると、「Creative Cloud Desktop Application」のログイン時にブラウザを経由して認証を行うフローになります。逆に無効だと「Creative Cloud Desktop Application」のログインはアプリ内に組み込まれたWebViewで行われます。

 

実際の認証フロー

例えば、

・Adobe CCがフェデレーション対象
・認証サーバ(IdP)で認証済み状態(OS既定ブラウザのCookieに認証情報を保持している)

という状態ですと、「Creative Cloud Desktop Application」起動し、Adobe IDを入力(ここの入力は必要です)→IdPにリダイレクト、OSの既定ブラウザが起動、認証済みなので、そのまま「Creative Cloud Desktop Application」にログインできます。

 

ブラウザで認証後、自動的に「Creative Cloud Desktop Application」へ戻っていきます。良くできてますね。

「Creative Cloud Desktop Application」にログイン済みであれば、「Illustrator」や「Photoshop」などのアプリケーションを単独で起動してもログイン済み状態となっています。アプリ間では認証情報を共有しているってことですね。では、未認証状態で最初から「Illustrator」や「Photoshop」などのアプリケーションを単独で起動した場合はどうなるか?というと・・・アプリはOS既定のブラウザを立ち上げないので、アプリ内のWebViewで認証を行います。

↑アプリに組み込まれたログイン画面です。OS既定のブラウザではありませんので、仮にOS既定ブラウザに認証情報を保持(OS既定ブラウザのCookieに認証情報を保持)している状態でも、ここからIdPにリダイレクト、「ID/Pass」などの入力をして認証を行う必要があります。まあ、ユーザ操作として、アプリの単独起動から始めるのではなく、まずは「Creative Cloud Desktop Application」を起動して更新情報などいろいろ見てね!って事なんでしょう。もちろん、アプリ単独起動でも認証を行えば、認証情報はアプリ間で共有されているので、「Creative Cloud Desktop Application」も認証済みとなっています。

 

Adobe アプリケーションからのログアウトについて

Adobeアプリケーションを「×」ボタンで終了しても認証情報は消えません。再びアプリを起動すれば(認証済み状態で)そのまま利用を開始できます。認証情報を破棄したい場合にはアプリから意図的にログオフする必要があるので注意が必要です。

Adobeさんっていち早くソフトウェアパッケージの提供方式から(サブスクリプション方式の)クラウドサービスに移行して成功している企業さんですよね。すごいなぁ~と思ってますが、そもそもAdobeさんが提供しているソフトウェアって競合もあるんだろうけど唯一無二的な感じもあったからなぁ~。必要なものはどのような提供形態でも必要とされるのでしょうね。

エラー:これにはインターネットが必要です。(0x800704cf)

新規にPCを購入してセットアップ中に以下のような現象に遭遇しましたのでメモ。

発生した現象

・Officeアプリケーションの認証でエラー
→ Word/ExcelなどのOfficeアプリケーションの「サインイン」時にエラー
→ アカウント/パスワード入力後に「これにはインターネットが必要です。(0x800704cf)」と表示

・Google Chromeのインストールができない
→ エラーでインストールできない。
→ 「インターネットに接続している必要がある・・・」旨のエラーが表示

・Microsoft Storeのアップデートができない
→ アプリの更新でプログレスバーが(まったく)進まない
→ 「ダウンロードしています・・・」などのメッセージは表示される

・Windows Updateが失敗する
→ 更新エラーでエラーコードとして「(0x800704cf)」が記載されている
→ 更新エラーとなるが、エラーメッセージが表示されない場合もある

Gmailとか Youtube などネットサーフィンはできます。なのでネットワーク環境の問題ではないような気がしましたが、結局ネットワーク環境の問題でしたw

解決方法

なんと、ネットワークアダプターの「プロパティ」にある「TCP/IPv6」のチェックを外したら全て解決できました。ただし、このエラーはネットワーク関連に問題がある場合に発生するらしく、この解決方法が全てに当てはまる訳ではありませんのでご了承ください。ネットワークのエラーって幅が広すぎですね。。。

Windowsの「設定」を開く

表示された画面にある「ネットワークとインターネット」を選択

左メニューの「WiFi」を選択、表示画面下の「関連設定」-「アダプターのオプションを変更する」

WiFiを右クリックし、「プロパティ」を表示

接続項目にある「インターネットプロトコルバージョン6(TCP/IPv6)」のチェックを外し「OK」ボタンを押す

根本的な原因は、ホームゲートウェイ(NTTからレンタルしているやつ)の設定を確認したところ、IPv6が無効になっていたことです。Windows 10 は IPv6 を優先して使うようなので、今回の現象を引き起こしたのだと思います。

もし、ネットワークが繋がったり繋がらなかったりと不安定な状況だった場合、一度、端末のネットワークアダプターの「IPv6」設定を無効化して試してはどうでしょうか。

Office365の動的グループなどについて

Office365のグループって幾つか種類があり、用途も被っているように見えるため(実際、同じことが複数のグループで出来ます)、ちょっと分かり難いですよね。

作ったグループがどのサービス(Microsoft OneDriveやMicrosoft Teamsなど)から利用できるのか、アプリ側で操作すると裏でグループが作られているとか・・・そんな事にも絡んでくるため、更に分かり難い状況になっています。

また、PowerShellのコマンドレットが用意されているので、要件が複雑な場合にはスクリプトを作って動かそう!と思っても、動的グループを作成するためのコマンドレットが含まれているPowerShellのバージョンが「プレビュー」状態であるなど、まだ発展の途中でいろいろ変わりそうな雰囲気がしています。

なので、この状況でスクリプトなどで作り込むのはまだやめましょう(笑)!きちんと整理されてベストプラクティスが確立するまでもうちょっと待ったほうが良さそうです。

***************************
2020年11月6日 追記
こちらの記事にOffice365動的グループに関する具体的なPowerShellコマンドを記載しました。
実際にいろいろ試したので、そのまま利用できると思います。
****************************

Office365のグループの種類

Office365管理画面からグループ作成を開始すると最初に「種類の選択」画面が表示されます。

大きく分けると3種類ですかね。「セキュリティグループ」は”メールアドレス:あり / なし”がありますが、基本は一緒ですね。

【参考:Microsoft グループを比較する】
https://docs.microsoft.com/ja-jp/microsoft-365/admin/create-groups/compare-groups?view=o365-worldwide

Office365グループの作成

リモートワークでMicrosoft Teamsを利用するユーザが増えてきていますね。Microsoft Teamsに表示される「チーム」はOffice365グループと連携しています。管理者がOffice365グループを作成するときにMicrosoft Teamsの「チーム」と連携させることや、ユーザがMicrosoft Teamsの画面で「チーム」を作成するとOffice365グループが作成されます(ここの制御をしたい企業が多いと思いますが、詳細は後半で記載しています)。

Microsoft Teamsアプリの画面ですが、「教育チーム」と表示されているところが「チーム」と言われて実態は「Office365グループ」です。その下に「チャネル」というカテゴリ分けみたいなものがぶら下がります。デフォルトでは「一般」が作成されているはずです。

話を元に戻します。Office365管理画面から「Office365グループ」を作成するときにはポイントがあります。

グループには「所有者の割り当て」という設定があり、ここに設定したユーザはグループの管理者となり、メンバーの追加や削除などの管理者権限を持ちます。

「所有者」は複数ユーザの設定も可能ですが、「Microsoft Teams」のライセンスを持つユーザじゃないと、次の「グループへのMicrosoft Teamsの追加」というチェックボックスがグレーアウトして設定できないので注意してください。

私も最初、Teamsのライセンスを付与されていないユーザを設定してしまい、「グループへのMicrosoft Teamsの追加」というチェックボックスがグレーアウトしており、ちょっと悩みました。ライセンスを付与してもちょっと時間がかかったり、一度ログオフして再度、管理画面にログインしないとチェックボックスがグレーアウトしたままになっていたりするので注意です。

ちなみに付与するライセンスは「Microsoft Teams Exploratory」でも大丈夫です。Microsoft Teams「Exploratoryライセンス」は、Microsoft Teamsを含まないOffice 365の各プランをご契約されているお客様だけが利用申し込みができる特別なMicrosoft Teams試用版のことです。「Exploratory」の利用期間(期限)は2021年1月まで、となっております。それ以降は、Teamsを含むプランに移行する必要があります。

【参考:Office 365 Businessだけを契約してTeamsが使えるのか?その真相を解説します】
https://licensecounter.jp/office365/blog/2020/03/office365business-teams-exploratory-license.html

グループ作成の最後に「設定の編集」がありますが、「グループへのMicrosoft Teamsの追加」のチェックボックスがここにあります。

このチェックボックスが有効だと、Microsoft Teamsの「チーム」として表示されるようになります。グループの一覧表示で「Teamsの状態」というカラムにアイコンが表示されていればMicrosoft Teamsからも見えるようになっています。

この「グループへのMicrosoft Teams の追加」ですが、PowerShellで「Office365グループ」を作成するときに引数で持たせることができるか調査しましたが、どうも無いようです。PowerShellで「Office365グループ」を作成し、対象グループの「ObjectID」を取得、この値を引数として「New-Team」コマンド(Microsoft Teams関連のPowerShellモジュールが必要)で「チーム」を作成する必要があります。

メンバーは「Office365グループ」の作成後にグループの編集画面から追加します。「メンバー」タブをクリックして「+メンバーの追加」ボタンを押してからユーザを入力、追加してください。「+メンバーの追加」ボタンを押さずに「メンバー検索」のテキストボックスに値を入力しても既に追加済みメンバーを検索するだけなので、(メンバーが居ないと)何も検索できませんので注意です。

Azure Active Directoryの動的グループ

グループの管理で一番面倒なのはメンバー管理です。組織変更がある度にメンバーの入替作業を行う必要があり、大変手間です。また、Microsoft Teamsではユーザーがチームのメンバーを編集したり、自分からチームを脱退することができてしまいます。しかもMicrosoft Teams側の基本設定では、これらを制御することはできません。

Azure Active Directoryの動的グループを使うと、設定した条件に従ってユーザーを自動的にグループのメンバーに含める、或いはグループメンバーから自動的に削除できるなど、大変便利な機能となっています。また、Microsoft Teamsではこの動的グループと連動している場合、メニューの「チームから脱退」と「メンバーを追加」が非表示になります(デフォルトで所属している組織全体のチームからはそもそも脱退できません。また「チャネル」の制御はできません)。そのため、ユーザーは勝手にチームから脱退することやメンバーを追加することが出来なくなります。

**** 2020年10月追記 ****
この時点で試したところ、「チームから脱退」メニューは表示されたが、実際に脱退はできませんでした。
↓こんなポップアップが表示されます。

*****************************

が、利用するには、「Azure AD Premium P1」ライセンスをグループメンバー分用意し、各ユーザーに割り当てる必要があります。

動的グループは、Azure Active Directory 管理センター (https://aad.portal.azure.com/)からグループ作成時に設定することができます。

【参考:動的グループによるMicrosoft Teamsのチームメンバー管理】
テクノバンBlog_Office365動的グループによるMicrosoft Teamsのチームメンバー管理

なお、動的グループとして利用可能なグループの種類は「Office365」と「セキュリティ」の2種類です。

動的グループをPowerShellで操作する

さて、便利な動的グループですが、この機能を利用する規模になるとID管理システムからグループを作成する、ワークフローシステムと連携して(承認されたら)グループを作成するなど、外部から操作する必要が出てきます。そのため、PowerShellを駆使することになりますが、動的グループを操作するには「Azure AD PowerShell バージョン 2」 のプレビュー バージョンのコマンドレット(New-AzureADMSGroup,Set-AzureADMSGroup など)を使用する必要があります、と記載がありまして、(2020年6月現在)まだプレビューとのことです。

【参考:Azure Active Directory で静的なグループメンバーシップを動的に変更する】
https://docs.microsoft.com/ja-jp/azure/active-directory/users-groups-roles/groups-change-type

【参考:New-AzureADMSGroup】
https://docs.microsoft.com/en-us/powershell/module/azuread/new-azureadmsgroup?view=azureadps-2.0

PowerShellを駆使すればいろいろ出来そうですが、グループの整理整頓も今後行われそう(?)ですし、PowerShellもプレビューなので、このタイミングではまだ作り込まない方が賢明かと思います。

~~~出展、参考サイト~~~

マイクロソフト
【Office365管理センターのヘルプ:グループを比較する】
https://docs.microsoft.com/ja-jp/microsoft-365/admin/create-groups/compare-groups?view=o365-worldwide

【Azure Active Directory で静的なグループメンバーシップを動的に変更する】
https://docs.microsoft.com/ja-jp/azure/active-directory/users-groups-roles/groups-change-type

【PowerShell New-AzureADMSGroup】
https://docs.microsoft.com/en-us/powershell/module/azuread/new-azureadmsgroup?view=azureadps-2.0

SB C&S株式会社
【Office 365 Businessだけを契約してTeamsが使えるのか?その真相を解説します】
https://licensecounter.jp/office365/blog/2020/03/office365business-teams-exploratory-license.html

テクノバン株式会社
【動的グループによるMicrosoft Teamsのチームメンバー管理】
https://blogs.techvan.co.jp/microsoft/2018/11/28/%E5%8B%95%E7%9A%84%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97%E3%81%AB%E3%82%88%E3%82%8Bmicrosoft-teams%E3%81%AE%E3%83%81%E3%83%BC%E3%83%A0%E3%83%A1%E3%83%B3%E3%83%90%E3%83%BC%E7%AE%A1%E7%90%86/

Adobe CC とのシングルサインオン設定

今回は「Adobe Creative Cloud」とのシングルサインオン(フェデレーション)設定を行ったときのメモです。久しぶりにAdobe CCを触ってみたところ、以前よりも設定が簡単になっていました。

Adobe Admin Console へログイン

まずは、アドビの管理コンソール(https://adminconsole.adobe.com/)にログインしましょう。

フェデレーションドメインの追加

次にフェデレーションで利用する独自ドメインを登録します。ログイン後、上部メニューの「詳細」-「設定」をクリックします。
デフォルトでは「ディレクトリ」が表示されているので、「ドメイン」タブで移動します。
※「ディレクトリ」は認証連携を行うIdPの登録やフェデレーションドメインの”リンク”を行うので後で作成します。

「ドメインを追加」ボタンが表示されているので追加します。

フェデレーションドメインを追加するだけですので、迷うことは無いと思います。ドメインの追加が完了すると以下のような「検証」と表示されていると思います。当然ながら指定したドメインの持ち主であることを確認するために利用しているドメインサービスに管理者としてログインし、該当ドメインに対して「txtレコード」を追加する必要があります。

「検証」ボタンを押すとtxtレコードに入力する値が表示されてますので、「adobe-idp-site〜」をコピーしてDNSのtxtレコードに設定してください。

設定したフェデレーションドメインの(所有権の)「検証」が完了すると、以下のように「検証」から「ディレクトリにリンク」と表示が変わります。

フェデレーションドメインの追加はいったん完了です。

「ディレクトリ」の作成

フェデレーションドメインを追加した後は、「ディレクトリ」を作成します。この「ディレクトリ」という表記はアドビ独自の呼び方なので最初は何だろう?と思いましたが、ここで認証連携を行うIdP情報を設定して、更にフェデレーションドメインと関連付けする(リンクする)、というオブジェクトです。

「ディレクトリ」タブから「ディレクトリを作成」ボタンを押して作成に取り掛かります。

任意の名前を入力し、「Federated ID」を選択、次に進みます。ちなみに「Enterprise ID」を選択すると、フェデレーションは行わないがID作成やメンテナンスなどの操作は管理者が行う、というものらしいです。

詳しくはこちらを参照してください。

【アドビエンタープライズ製品でのIDタイプの管理】
https://helpx.adobe.com/jp/enterprise/using/identity.html

次の画面では認証連携を行うIdPの情報の設定に入ります。今回は「他のSAMLプロバイダー」を選択し、次に進みます。

そうすると、アドビ側(SP側)の「メタデータ」のダウンロードと、認証側(IdP側)の「メタデータ」のアップロードができるようになっています。しっかり作り込まれているIdPなら、SP側のメタデータを読み込んで必要な設定を自動化できますし、IdPのメタデータを出力することもできますので、ここでお互いの設定をメタデータファイルの読み込みで行います。(とても簡単ですね!)
※Adobeのメタデータファイルの中身については最後に参考情報として掲載しておきます。

「ディレクトリ」が作成されると以下のように表示されます。「編集」ボタンがあり、間違いがあれば後からいくらでも再設定できます。

以上で「ディレクトリ」の作成は完了です。

「フェデレーションドメイン」を「ディレクトリ」にリンク

これ忘れないでください。作成した「ディレクトリ」に追加したフェデレーションドメインを”リンク”します。

先に「ディレクトリ」を作成してからドメインを追加する手順を踏めば、画面を行ったり来たりしなくて良いと思うのですが、ドメインの検証には時間がかかる可能性があるので、最初にドメインを追加することから始めました・・・というぐらいの意図しかないので、お好きな手順でどうぞ。

「ディレクトリにリンク」ボタンを押すと以下のような画面が表示されるので、リンクする「ディレクトリ」を選択してください。

ドメインとディレクトリの紐付けが完了すると「ディレクトリにリンク」から「アクティブ」に表記が変わります。

以上でフェデレーションのための設定は全て完了です。最後にフェデレーションユーザの作成を行います。

「フェデレーションユーザー」の作成

Adobeには3種類のIDタイプがありますが、フェデレーションを行うIDタイプは「Federated ID」です。新規にユーザーを作成する場合、「IDのタイプ」で「Federated ID」を選択してください。

ユーザーの作成は画面上部メニューの「ユーザー」-「ユーザの追加」から行います。入力欄にユーザID(メールアドレス)を入力します。

ユーザーIDを入力すると、恐らく重複チェックなどを行い、作成可能なIDなら「IDのタイプ」や「SSOユーザー名」、「国/地域」などの設定項目が表示されます。「IDのタイプ」を「Federated ID」に設定して作成してください。

ちなみにですが、ユーザードメインと「ディレクトリ」にリンクした「ドメイン」が一致していると、自動的に「ディレクトリのユーザー」に追加されていることが分かります。なので、ユーザーを作成するだけでフェデレーションユーザーとなります。

実際にログイン画面(https://www.adobe.com/jp/)にてユーザーIDを入力(Office365同様、ドメインしかみてませんので@前は適当な文字列でOKです)して、IdPにリダイレクトされるか確認してください。

それと、既存ユーザーの「IDタイプ」を変更する場合、管理画面から簡単にはできないようです。調べたところ、CSVファイルを利用した一括変更で対応するしかないようです。画面からポチポチできれば良いのに・・・。

【アドビエンタープライズ製品でのIDタイプの管理】
https://helpx.adobe.com/jp/enterprise/using/identity.html
※「IDタイプを一括編集」の項を参照。

参考:メタデータについて

Adobeのメタデータファイルの中身を見てみました。

IdP側の設定に最低限必要な「entityID」、「NameIDFormat」、「AssertionCOnsumerService」の情報は含まれています。ユーザー識別子「Nameid」には当然ですがAdobeのユーザーIDをセットする必要があります。

<md:EntityDescriptor>
entityID=”https://federatedid.services.adobe.com/federated/saml/metadata/alias/・・・”

<md:SPSSODescriptor>
<md: NameIDFormat>
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
<md:AssertionConsumerService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” Location=”https://federatedid.services.adobe.com/federated/saml/SSO/alias/・・・”

ログアウトの情報がないんですよね・・・シングルログアウトには対応してないと思うので、終了時にはブラウザを「閉じる」という運用になると思います。

以上。

リモートワークと多要素認証とOffice365と。

世の中いろいろ大変ですが、頑張って乗り切りましょう!

さて、そんな最中ですが私は通常よりも忙しい毎日を過ごしています。

リモートワークを行う人が増えたため、認証サーバへのアクセス数増加の対応や、ZoomやWebEXなどのサービスの認証連携(シングルサインオン)をしたいなどの要望が急激に増えました。

一方で今まで外部アクセスは多要素認証を行なっていたが、リモートワークを行う人が増え、OTPの設定に関する問い合わせが増えておりまして、あるサービスへのアクセスは一時的にパスワード認証に戻して欲しい、或いは、一部の人だけパスワード認証に戻して欲しい、などと言うセキュリティレベルを下げる依頼も多くありました。

後者は絶対にやってはいけないのですが、どうしてもやって欲しいという事で対応はしましたが、以下の点を覚悟してくださいと伝えてます。

・多要素認証を一部だけ解除することは、セキュリティに穴をあけることになる。
・メール機能を持つOffice365などはアカウント奪取後、スパムメールの踏み台にされることが多い。
・社内に侵入されなくても、1つのメールアカウントが漏洩するだけで、その被害は広範囲に渡る。

これらは実際に私が経験したことでもあります。悪意のあるハッカーは企業内に侵入し、機密情報を奪うという高度なことをする人よりも、シンプルに取得したメールアカウントを踏み台に大量のSPAMメールを送信するとか、アドレス帳から関連している企業に対して更なるアタックを仕掛けようとする、ことが圧倒的に多いです。

そのため、(企業なら)一般社員なら大丈夫だろう、(教育機関なら)学生は一時的に多要素認証を解除してもやむを得ない、何かあっても影響範囲が限定的だろう、という考えはとても危険だなと感じました。

Googleは8年も前から「あらゆるネットワークを信頼しない、ゼロトラスト セキュリティモデル(Beyond Corp)」を研究、実践してきました。そのため、コロナ騒動でリモートワークが増えても、特別な対応をすることなく、高いセキュリティレベルを維持しています。

「VPNを介さなくても業員や契約業者などのユーザーがほぼどこからでもより安全に働けるようにします。」ってとてもカッコイイ!!ですよね。

【Google 企業セキュリティに対する新しいアプローチ:Beyond Corp】
https://cloud.google.com/beyondcorp?hl=ja

まあ、Chrome bookeやChromeブラウザのみの利用を前提としたりしているので一般の企業で実践するにはまだまだ考えなくてはいけないことが多いのですが、方向性(ゼロトラストをベースにする)としてはこれからの流れに即しているのではないかな、と思います。

 

Azure AD Connect インストールと初期設定

Azure AD Connect ダウンロード

https://www.microsoft.com/en-us/download/details.aspx?id=47594
※言語が「English」ですが、インストール後に起動するウィザードは日本語です(OSの言語設定に依存)。

初期設定

インストール完了後、設定ウィザードが起動します。

①ライセンス条項への同意

②「簡単設定を使う」or 「カスタマイズ」の選択(今回は簡単設定を選択します。)

③Azure ADへの接続アカウントを入力(●●●@●●●.onmicrosoft.comアカウントを入力します。)

④Active Directoryに接続
接続が完了すると、自動的に「Active DirectoryのUPNサフィックス」を取得、表示してくれます。
更に、Office365に登録されているドメインと比較し、一致しているか?を確認してくれます。
(ADのUPNサフィックスがOffice365にドメインに登録されているか?ということです。)

「一部のUPNサフィックスが確認済みドメインに一致しなくても続行する」にチェックを入れて「次に」進みます。

⑥構成の確認

⑦完了!

とても簡単ですね。ただ、このままですとADの情報を全て同期してしまうので、特定のOU配下を同期対象にするなど、オプション設定をお勧めします。「ADConnect」を起動すると「追加のタスク」画面が表示されます。

「同期オプションのカスタマイズ」で、同期対象OUなどを指定することができます。

その他、パスワードの書き戻しや拡張属性を同期対象とするなど、細かい設定ができます。

その他メモ

Azure AD Connectを導入したサーバにて、PowerShellから同期停止、同期開始が実行できます。

・同期を開始する場合

Start-ADSyncSyncCycle

・同期を停止する場合

Stop-ADSyncSyncCycle

ADConnectの同期を停止しただけでは、Office365側は同期の非アクティブ化がされません。PowerShellからOffice365へ「connect-MsolService」で接続、以下のコマンドで「同期の非アクティブ化」をしてください。なお、反映にはかなり時間がかかるようです。

Set-MsolDirSyncEnabled –EnableDirSync $false

非アクティブ化がされていない状態でID管理製品などからID同期を行おうとすると、以下のようなメッセージが表示されるようです。また、Office365の管理画面よりアカウントの作成はできるようですが、Exchange属性の編集を行おうとすると同様なエラーが発生することを確認しています。

選択されたユーザー アカウントは、テナント ‘●●●●’ に存在しないため、そのテナントのアプリケーション ‘●●●●’ にアクセスできません。最初に、アカウントをテナントの外部ユーザーとして追加してください。別のアカウントをお使いください。

PowerShellからOffice365へ「connect-MsolService」で接続、以下のコマンドで同期のアクティブ/非アクティブが確認できます。

Get-MsolCompanyInformation | Select-Object DirectorySynchronizationEnabled

 

昔に比べてとても使いやすくなっていると感じました。次回はADFSがない環境でもADで認証を行う「パススルー認証」機能について検証してみたいと思います。「Azure AD Connect」をちゃんと使いこなせば、「社内ADでアカウント管理 + Officew365の多要素認証」という環境が出来上がるので、お金をかけずにOffice365に対するセキュリティを高めることができると思います。

Office365「Windows接続済み」で自動ログインする件

EdgeブラウザでOffice365に自動ログインしてしまう

Office365にサインインした時に、「組織がデバイスを管理できるようにする」とした場合(詳しくは前の記事へ)、認証情報がWindowsOSの「アカウント」に登録されます。更に「Azure Active Directory」の「デバイス」に端末情報が登録されます。この状態でEdgeブラウザからOffice365のサインインページに飛ぶと、パスワード入力などユーザが認証操作をすることなくログイン後ページが開きます。
※自動ログインの解除については「前の記事へ」に記載しています。

ブラウザのCookieやローカルストレージのファイルを消してもなお自動ログインができるため、WindowsOSに登録された認証情報を利用してログインしているのだろう、という事は想像できます。

実際のシーケンスについて

実際のシーケンスがどうなっているかEdgeブラウザのツールで覗いてみました。詳細かつ正確なことは分かりませんでしたので想像します。

  • Request-Headesに「authorization」が入っているシーケンスを見ると「graph.microsoft.com」というHOSTにアクセスしている。
  • 「要求URL」が「https://graph.microsoft.com/v1.0/me/drive/root」となっている。

Microsoft Graph について

OSに格納した情報を利用して「Office365の認証を行っている」、或いは「この「graph.microsoft.com」へのアクセスを行っている」のは何となく分かりますが、この「graph.microsoft.com」へのアクセスは一体何をしているのか?Webで手掛かりがないか、検索してみたところ以下のような情報が。

Microsoft ID プラットフォームから取得したアクセストークンを利用して「Microsoft Graph」を呼び出すと、「サインインしているユーザーのプロファイル情報」を返すことができる。

【Microsoft Graph の認証と承認の基本方法】
https://docs.microsoft.com/ja-jp/graph/auth/auth-concepts

もしかしたらOSが保持している「アカウント情報」は、この「graph.microsoft.com」へのアクセスキーやユーザIDなど、そんな情報なのかも知れません。

そして想像してみる

「組織がデバイスを管理できるようにする」という設定を有効にすると、「Azure Active Directoryのデバイス一覧」に端末情報が登録され、その情報を毎回呼び出しているようなシーケンスを想像しています(デバイスが登録されているから認証OK的な?)。Windows10の「アカウント」-「職場または学校にアクセスする」から登録されているアカウントを「切断」すると「Azure Active Directory」の「デバイス」からも登録情報が削除されるので、以降は通常の認証に戻る・・・と想像しています。

想像だらけの内容になってしまいました。すみません。