九州大学における Office 365 サービス環境の再構築
嶋吉 隆夫 1) , 笠原 義晃 1) , 尾花 昌浩 2) , 藤村 直美 1)
1) 九州大学 情報基盤研究開発センター
2) 九州大学 情報システム部
simayosi@cc.kyushu-u.ac.jp

Restructuring of Service Infrastructure for Office 365 in Kyushu University
Takao Shimayoshi1) , Yoshiaki Kasahara1) , Masahiro Obana2) , Naomi Fujimura1)
1) Research Institute for Information Technology, Kyushu University
2) Information Systems Department, Kyushu University

概要
九州大学では 2016 年から Oﬃce 365 を全学サービスとして正式に提供してきたが、その基盤システムやテナン
ト運用などについて様々な課題が生じていた。そこで、基盤システムとテナントを含めて環境を新たに再構築し、2018 年 4 月から新しいサービス環境の提供を開始した。本稿では、従来の環境における課題とその解決策、さらに、新しい環境の構築過程で生じた問題とその解決方法などについて紹介する。

1 はじめにについて説明したのち、3 章で以前のサービス環境の構成と課題について述べる。次いで 4 章で新たに構築

Microsoft 社が提供する Office 365 Education はクラしたサービス環境の設計について述べたのち、5 章でウドアプリケーションスイートの教育機関用エディ実装や配備、移行の方法、また、移行に際して直面しションである。Office 365 の基本機能は教育機関に対た問題と解決策などについて述べる。最後に 6 章で、して無償で提供されており、それには、Office Online,

今後の計画と課題について述べる。

OneDrive for Business, Exchange Online, Skype for
Business, SharePoint Online などが含まれる。本稿では Office 365 は Office 365 Education を指す。

2 九州大学の構成員識別情報
九州大学では全構成員に対して、複数の情報サービ

九州大学では、2015 年から日本マイクロソフト社

スで共通して利用できる ID として SSO-KID を発行と結んでいる包括契約 Enrollment for Education Solu-

している。SSO-KID は、過去の構成員も含めて重複のtions (EES) に Office 365 ProPlus のライセンスが含まない 10 桁の数字であり、個人と SSO-KID の対応が特れることを受け、Office 365 の全学サービス導入につ定できないように無作為に割り振られる。全構成員のいて検討と評価が始められた。その後、2015 年度中に情報が格納される全学共通認証基盤の全学共通 ID 管試験サービスとして提供を開始し、それを 2016 年 4 月

理システムが SSO-KID を決定する。SSO-KID とパスから正式サービスとして全構成員に提供した。Office

ワードの一覧は厳重に管理され、学外持出しは禁止さ

365 の試験サービス提供以降、サービス提供のためのれている。なお、全学共通 ID 管理システムでは各ア

基盤システムの管理、運用や、サービスの提供方法、カウントに対してシリアル番号である UID が付与さ内容などについて、様々な課題が明らかとなってきた。

れている。また、学生は SSO-KID 以外に、学籍番号

そこで検討の結果、課題を解決するため、新たなサーとして学生 ID を持つ。

ビス環境を構築し、従来のサービス環境を廃止して移九州大学では全構成員に対して全学基本

行することとした。その後、2018 年 4 月から新しい環

メ ー ル サ ー ビ ス が 提 供 さ れ て い る 。学 生 に境で正式サービスを提供している。

は “⟨学生 ID⟩@s.kyushu-u.ac.jp”、教職員には

本稿では、九州大学における Office 365 のサービス
環境を再構築した経緯と経過を紹介する。まず最初に2 章で前提となる九州大学における構成員の識別情報“⟨姓⟩.⟨名⟩.⟨数字⟩@m.kyushu-u.ac.jp” という全学基本メールアドレスが割り当てられる。

AD の内容も変更される。次いで、オンプレ AD の内

3 以前のサービス環境

容は、Microsoft 製の Windows Azure Active Directory

Sync (DirSync) を用いて Azure AD へと定期的に同期

3.1 構成本節では、2015 年度に試験サービス、2016 年度かされる。

ら正式サービスとして提供していた Office 365 テナン

Office 365 の利用には、Azure AD へのユーザー登録

ト、および、その基盤システム（以降、旧環境）[1] にだけでなく、各ユーザーにライセンスを割り当てる必ついて説明する（図 1）。九州大学の Office 365 サー

要がある。旧環境では、全学共通認証基盤で追加、削ビスは、教育機関向けに無償で提供される Office 365

除等のあった構成員の一覧を、全学共通 ID 管理シス

Education (Office 365 A1) と、EES に含まれる Office

テムの機能を用いて日次バッチ処理にて CSV に出力

365 ProPlus のライセンスを組み合わせて使用する。

し、独自開発の PowerShell スクリプトにより処理する

Office 365 テナントを作成すると自動的に “⟨テナント

ことで、ライセンス割当、削除を行っていた。

名⟩.onmicrosoft.com” というドメインが割り当てられ

3.2

課題

るが、一般的に組織のドメイン名をテナントに登録す

旧環境のサービス稼働後に、オンプレ AD と Azure

る。旧環境では、九州大学で以前に使用していなかっAD との同期に使用していた DirSync は 2017 年 4 月にたドメイン名 ms.kyushu-u.ac.jp を登録していた。

サポートが終了し、また、2018 年 1 月以降は DirSync かOffice 365 ではユーザー識別認証サービスとしてらの通信を受け入れなくなることが発表された。これ

Azure Active Directory (Azure AD) が 使 用 さ れ る 。

に対処するためには、DirSync から Azure AD Connect

Office 365 のユーザー情報は Azure AD に格納され、へと移行する必要がある。しかし、DirSync と Azure

ユーザーは user principal name (UPN) により識別され

AD Connect では、ユーザー同期に必須の属性など、仕る。旧環境では UPN として、全学基本メールアドレ

様に相違があることが判明し、全学共通認証基盤からスのローカルパートの後に、学生、教職員によらず、オンプレ AD にユーザー情報を登録する部分について@ms.kyushu-u.ac.jp を加えたものを Office 365 専用にも変更が必要であった。

付与していた。また、ユーザーの認証には、Azure AD

前述の通り旧環境では、Office 365 のユーザーへのを利用するクラウド認証と呼ばれる手法を用い、Office

ライセンス割当処理に、全学共通 ID 管理システムの365 専用パスワードを Azure AD に保存していた。

機能と独自開発の PowerShell スクリプトを用いてい九州大学では構成員情報は全学共通認証基盤に格納た。しかし、構成員の追加、削除における全学共通 ID

されており、その情報を元に Azure AD にユーザー情

管理システムの動作が、必ずしも PowerShell スクリ

報を設定する必要がある。その実現に、旧環境では以プト設計段階での想定通りではなかったことから、少下の方法を用いていた。まず、オンプレミスの Active

なくない割合の新規構成員について Office 365 のライ

Directory（以降、オンプレ AD）を Office 365 専用に学センスが割り当てられないという不具合が発生してい内の仮想化基盤上に構築し、全学共通認証基盤からオた。その後 PowerShell スクリプトに対して何度か対ンプレ AD に Office 365 のユーザー情報を登録する。

症療法的な改修が行われたものの、最後まで根本的な全学共通認証基盤の登録内容に変更があれば、全学解決には至らなかった。なお、その設計開発は全学共共通 ID 管理システムの機能により自動的にオンプレ

通 ID 管理システムの開発元が受注していた。
九州大学では全学基本メールサービスを独自構築したシステムにより運用していることから、旧環境

Azure AD

Office 365

での Office 365 テナントではメールサービスである

当

Exchange Online を無効にしていた。しかし、サービ

参照

力
出

全学共通認証基盤
全学共通
ID管理
システム

同期

PowerShell
スクリプト
チ
ッ

バ

更新

オンプレ

AD

サインイン, 利用

ス割
セン
ライ

端末

ス提供開始後に、Skype for Business などにおいて

Exchange Online を有効にしなければ一部機能に制限があることが明らかとなった。また、サービス導入時
点で Office 365 の仕様や機能について十分な理解が不足していたこともあり、正式サービス開始以降に、運用部門が想定していなかった使い方を利用者が行っ

図 1 旧環境の構成ていることが確認できたが、後から設定を変更する

ことは既存利用者への影響から困難であった。さら

4.2

構成

に、SSO-KID とパスワードは外部に出せないことから

4.1 節で述べた要件を満たしつつ 3.2 節で述べた課

UPN には SSO-KID 以外の文字列を用いる必要があっ題を解決するため、全学共通認証基盤から Azure AD

たが、準備期間が短く十分な検討ができなかったことへの連携や認証のシステムを再構築し、また、テナン

から、旧環境テナントでは前述の通り Office 365 専用

トについても新たなテナントを作成して移行する方法の UPN を採用していた。しかし、その UPN は全学基を採用した。これは、旧環境の部分改修だけでは問題

本メールアドレスと混同しやすく、また、他ユーザーの抜本的解決が非常に困難であり、正式サービス開始を指定する際などの利便性が高くなかった。これらのからの期間が短ければ利用者への影響は比較的小さい

ことから、Office 365 テナントの設計や構成についてと判断したことによる。本節では、九州大学における再検討が求められていた。

新しい Office 365 サービス環境（以下、新環境）の設

九州大学では、前述の通り全学基本メールサービス

計および構成について述べる（図 2）。

を独自システムで運用しているが、2019 年 1 月にその■テナント構成 Office 365 テナントは、学生、教職員システムの保守期限を迎える。そのシステム更新につを同じ単一のテナントに収容する。学生および教職員

いては Office 365 サービス再構築とは独立して検討さの一覧を学生には取得不可能にするという要件から、れていたが、選択肢として Exchange Online を利用す

学生と教職員とでテナントを分割する方法についてもる案も検討されていた。旧環境は全学基本メールサー検討を行ったが、同一テナントに収容しても要件が実

ビスとは完全に独立した設計だったが、検討の結果次現できること、テナントを分割すると構成や運用が複第で全学基本メールサービスが移行できる環境にし雑になることから、採用しなかった。

ておくことが望ましいと考えられた。なお最終的に、■ユーザー認証 SSO-KID とパスワードを Azure AD

全学基本メールサービスは 2018 年 12 月に Exchangeには保存しないという要件を満たし、かつ、Office 365

Online に移行する計画が決定されている。

へのサインインを全学共通 ID である SSO-KID とその4 設計
4.1 要件パスワードで可能にすることを目的として、Office 365のユーザー認証に Active Directory フェデレーション
サービス (AD FS) を用いたフェデレーション認証と呼九州大学で全学共通 ID として発行している SSO-

ばれる構成を採用する。オンプレ AD と、それを参照

KID は、秘密情報ではないが他者に安易に開示するもする AD FS サーバを構築し、オンプレ AD から Azureのではない。また、2 節で述べた通り、SSO-KID の一

AD へとユーザー情報を同期させ、Azure AD への認

覧の学外持出しは禁止されている。つまり、クラウド

証要求は AD FS サーバへとリダイレクトする。このサービスである Azure AD に保存されるユーザー情報

構成では、Azure AD にパスワードを保存する必要がには SSO-KID を登録できない。

ない。なお、SSO-KID を Azure AD に保存しないた

Office 365 では、テナント内のユーザー一覧を表示

めには後述の方策が必要である。上記目的の実現方法

する機能や、UPN や個人名、メールアドレスの一部かとして他に、Azure AD が対応している SAML を利用

らユーザーを検索する機能がある。しかし、学生が学したシボレス認証を用いる方法も考えられたが、今回生や教職員の一覧を取得可能だと問題である。また、は、Microsoft 製品として提供される AD FS を用いる

九州大学の学生 ID は基本的に連番で付与されることから、任意の学生 ID だけから個人情報が容易に判明することには問題がある。それゆえ、学生によるユー

Azure ADザー一覧の取得や学生 ID から個人情報の取得ができSharePoint Online の記憶容量はテナント全体での総量

全学共通
ID管理
システム

が制限される。このようなテナント全体で共有する資更新

同期

全学共通認証基盤

参照

Online の記憶容量はユーザーごとに確保されるが、

オンプレ

AD

参照

ことのないよう注意する必要がある。

図2

ス
セン
ライ

AD FS

源が、構成員による無思慮な利用によって浪費される
新環境の構成割当

認証

サインイン, 利用

License
Sync

Office 365 では、OneDrive for Business や Exchange

フェデレーション

ないようにする必要がある。

Office 365

参照

端末

方が Office 365 のサポート情報が得られやすいとの判

作では、sAMAccountName 属性は Azure AD に同期

断から、AD FS を採用した。

され、また、代替 ID を利用した場合、オンプレ AD■サーバ構成上記の認証方法は、以下のシステム構の userPrincipalName 属性は Azure AD の onPremis-

成により実現する。旧環境のオンプレ AD を構築して

esUserPrincipalName 属性に同期されることから、そいた仮想化基盤は導入時の保守期限を 2018 年度中にのままでは Azure AD に全ユーザーの SSO-KID が保迎えることから、IaaS である Microsoft Azure 上にシ

存されることになる。これを避けるため、上記の SSO-

ステムを構築することとした。SINET が提供するクラKID を含む属性や他の同期不要な属性について、同期

ウド接続サービスと Azure ExpressRoute を利用して、規則エディターによりフィルター処理を構成すること

九州大学の内部ネットワークサブネットを Azure 上ので、Azure AD に同期されないようにする。ここで、代仮想ネットワーク (VNet) として作成し、その VNet 上

替 ID 構成を用いる場合は、代替 ID、今回は mail 属性がの仮想マシンによりシステムを構築する。それに先立変更になった場合でも、オンプレAD と Azure AD 間でち、全学共通認証基盤が構築されている仮想化基盤のユーザーを永続的に一意対応させるために、Azure AD

上に、全学共通 ID 管理システムと直接連携する Activeの sourceAnchor 属性をオンプレ AD の何らかの属性

Directory ドメインコントローラを準備し、AD DS をと同期する必要がある。新しい Azure AD Connect で稼働させる。このオンプレ AD は今後 Office 365 以外

は ConsistencyGuid 機能により、ユーザーの初回同期の学内サービスによる利用も想定している。次に、上時に自動的にオンプレ AD の ms-DS-ConsistencyGuid

記のドメインコントローラをレプリケーションする

属性に値を書き込み sourceAnchor 属性として使用すサーバ 1 台、AD FS を稼働する冗長構成のサーバ 2 台

ることができる。しかし今回は、Active Directory をを Azure VNet 上に配備する。これらはインターネッ

再構築などした場合でも継続的に Azure AD と同期でトからのアクセスを禁止する。最後に、インターネッ

きることを考え、ms-DS-ConsistencyGuid 属性に UID

トからのアクセスを許可する WAP サーバ 2 台を冗長と固定文字列を結合した文字列をバイナリ値として登構成で配備する。

録する。

■Active Directory 登録内容

全学共通認証基盤から■ライセンス割当

旧環境では全学共通 ID 管理シス

オンプレ AD のユーザー情報に登録する内容は、他テムの機能を用いてライセンス割当、削除すべき構成のサービスで今後利用することも考慮して検討した。

員の一覧を作成していたが、この方式には様々な課題

Active Directory でユーザーオブジェクトの相対識別があることが明らかになっていた。そこで、全学共通

名として用いられる CN (Common-Name) 属性には、

ID 管理システムからはオンプレ AD ユーザーの属性に全学共通 ID 管理システムの UID を登録する。ユー

値を設定するだけとし、別途、オンプレ AD ユーザー

ザーのログオン名を表す sAMAccountName 属性にはの属性値を元に、対応する Office 365 ユーザーにライ

SSO-KID を、userPrincipalName 属性には SSO-KID

センスを割当、削除する構成を採用する。その実現に、の後に@kyushu-u.ac.jp を加えた文字列を登録する。

サイオステクノロジー社のツール LicenseSync を利用

メールアドレスを表す mail 属性には全学基本メールする。全学共通 ID 管理システムから各オンプレ AD

アドレスを、mailNickname 属性には全学基本メールア

ユーザーの特定の属性に対して、ライセンス割当情報

ドレスのローカルパートを登録する。しかし、この状に対応するコード値とコード更新フラグを設定する。

態で単純に Azure AD Connect を用いてオンプレ AD

上記 LicenseSync は、一定時間ごとに AD ユーザーのから Azure AD へと同期すると、Office 365 の UPN

コード更新フラグを確認し、更新があれば Office 365

はオンプレ AD の userPrincipalName 属性が使われるのライセンス割当内容を変更する。

ことから、UPN に SSO-KID が含まれることになる。
そこで、Azure AD Connect の設定において、Office

365 の UPN にオンプレ AD の userPrincipalName 属

5 実装・配備・移行
5.1

移行計画

性以外を用いる代替 ID と呼ばれる方法を採用する。

旧環境と新環境とを一定の期間に並行運用し、旧環全学基本メールアドレスは他者への開示が前提であ境に保存されているコンテンツは利用者に各自で新環るので、Office 365 の UPN として全学基本メールア

境へ移行してもらうこととした。新環境は 2017 年度

ドレスを用いることにし、代替 ID として mail 属性

内に稼働させて試験運用を行ったのち、2018 年 4 月かを指定する。さらに、Azure AD Connect の既定の動ら正式サービスとして提供し、旧環境は 2018 年 7 月

末でサービス提供を廃止することとした。

更になることを連絡した。

2018 年 1 月以降は DirSync による同期が停止する

ここまでの作業により本来は対象ドメインをテナため、それ以降は全学共通認証基盤での登録内容の変ントから削除できるはずであるが、実際にはドメイン

更が Azure AD に反映されない。特に、新たな構成員の削除に失敗した。これは、当該テナントでは全ユー

は新環境の提供開始まで Office 365 が利用できない。

ザーで Exchange Online が無効であるにもかかわらそこで、新規構成員については要求に応じて手動でず、理由は不明だが一部ユーザーに Exchange Online

Office 365 アカウントを作成することとした。

に関する情報が登録されており、その中に削除対象

5.2 新環境テナントの準備

ドメイン名が含まれることが原因だと分かった。しか新環境のテナントにはドメインとして、九州大学

し、Exchange Online は有効化されていないので、どのトップドメイン名である kyushu-u.ac.jp、全学基本のような手段でも該当する情報は削除できない。そこ

メールアドレスのドメイン名に利用される s.kyushu-

で、当該ユーザーに対して一旦 Exchange Online を有

u.ac.jp, m.kyushu-u.ac.jp を登録することとした。しか効化して情報を削除したのち再度 Exchange Online をし、全学基本メールアドレスで利用しているドメイン

無効化することで、問題を解決した。

名の登録には以下の追加作業を要した。

5.3

Microsoft 社は、教育機関が発行するメールアドレス

テナント設定5.3.1 一般ユーザーによるユーザー情報取得の禁止のドメイン名が Office 365 テナントに登録されていな

Office 365 では既定の動作として、全ユーザーの情

い場合、そのメールアドレスを持つ者が自身で登録し報はグローバルアドレス一覧 (GAL) に登録され、GALて Office 365 を利用できるセルフサインアップというは全ユーザーが参照できる。これを回避するテナント

サービスを提供している。セルフサインアップに用い全体の設定項目は存在しないが、個別ユーザーについられたドメイン名は、セルフサインアップ用に自動作て GAL への登録可否を設定できる。オンプレ AD か成されるテナントに登録され、同じドメイン名を用いら同期されているユーザーの場合、オンプレ AD ユーてセルフサインアップを行ったユーザーはそのテナン

ザーの msExchHideFromAddressLists 属性に False をトに登録される。s.kyushu-u.ac.jp と m.kyushu-u.ac.jp

設定すれば、そのユーザーは Office 365 テナントのは旧環境テナントには登録していなかったことから、

GAL に登録されない。ただし、その同期には、オン

いずれについても既にセルフサインアップ用テナント

プレ AD ユーザーに mailNickname 属性を設定する必に登録されていることが分かった。

要があることに注意されたい。今回、他の構成員の情

これらのセルフサインアップ用テナントの登録ドメ

報を学生が取得することを不可能にするために、全学

インから上記ドメイン名を削除する作業を以下の手

共通 ID 管理システムから全オンプレ AD ユーザーの順で行った。まず、s.kyushu-u.ac.jp および m.kyushu-

msExchHideFromAddressLists 属性に False を設定すu.ac.jp をドメイン名とするメールアドレスでセルフサるようにした。

インアップを行う。そのメールアドレスで Office 365

OneDrive for Business などではユーザーを検索するにサインインしたのち、管理画面にアクセスしてドメ機能があるが、これは前述の GAL とは独立であり、イン名の所有権確認の手続きを行うと、そのユーザー

既定では UPN や個人名、メールアドレスの一部からは当該テナントの管理者権限が得られる。ここで、ドユーザーを検索できる。この状態だと、容易に全ユー

メイン名の所有権確認には DNS の TXT レコードの変ザーの一覧を作成できる。SharePoint Online の設定

更が必要である。次いで、対象ドメイン名を削除可能に、メールアドレスか UPN の完全一致の場合にだけにするために、全ユーザーの登録情報からそのドメイ検索可能とする SearchResolveExactEmailOrUPN 項目

ン名を削除する必要がある。セルフサインアップ用テがある。これを True に設定することで、検索による

ナントについても onmicrosoft.com のサブドメインがユーザー一覧作成を回避した。

割り当てられているので、全ユーザーの UPN について

Office 365 テナントの既定の設定では、一般ユー

対象ドメイン名から onmicrosoft.com サブドメイン名

ザーであっても Azure ポータルに接続して Azure AD

へと変更する。ただし、この作業を実施すると、利用にアクセスできる。これを防ぐため、Azure ポータル

者はセルフサインアップしたメールアドレスで Officeで条件付きアクセス機能の設定を行った。しかしこの365 にサインインできなくなるので、事前に登録され設定だけでは、一般ユーザーが PowerShell などを用ているメールアドレス宛にサインイン用アドレスが変いて Azure AD に直接アクセスすれば、全ユーザー情報を取得できる。Office 365 テナント全体設定には、

DNS ドメイン名付きの文字列、または、“⟨NETBIOS

一般ユーザーによる他のユーザー及びグループの情報

ドメイン名⟩Y⟨sAMAccountName属性値⟩” を用いる。

の取得を制御する UsersPermissionToReadOtherUsers-

今回の構成では userPrincipalName 属性値には “⟨SSO-

Enabled 項目がある。これを False に設定することで、KID⟩@kyushu-u.ac.jp” が登録されている。しか一般ユーザーが Azure AD からユーザー一覧やユー

し、他のサービスと同様に、利用者は SSO-KID だけ

ザー情報を取得できないようにした。

を入力すれば良いようにしたい。そこで、AD FS サ

5.3.2 一般ユーザーによるグループ作成の禁止

インイン画面のカスタマイズ機能において、SSO-KID

Office 365 には Office 365 グループという機能があり、Office 365 グループを作成すると、それに伴い、の後に自動的に@kyushu-u.ac.jp が補完されるように

JavaScript を使用した。

Exchange Online の共有メールボックスのメールアド

AD FS の認証において、Azure AD Connect で代替レスが作成され、また、SharePoint Online のチームサ

ID を設定する場合には注意が必要である。Azure AD

イトが作成される。Office 365 テナントの既定設定でConnect のウィザードを用いて代替 ID を設定するとは、一般ユーザーが Office 365 グループを作成できる。

自動的に、Azure AD Connect で代替 ID として設定ししかし、一般ユーザーに Office 365 グループの自由なた属性の値を用いて AD FS にサインインできるよう作成を許すと、組織ドメイン名のメールアドレスが自に、AD FS の代替ログイン ID が構成される。今回の由に作成でき、管理上の問題がある。また、SharePoint

場合は、代替 ID に指定した mail 属性に登録される全Online のチームサイトは既定では容量の上限が設定

学基本メールアドレスで AD FS にサインインできる。

されず、テナント全体の共有資源を浪費される可能しかし、容易に収集できるメールアドレスを用いたサ性がある。そこで、一般ユーザーによる Office 365 グ

インインはセキュリティ保護の観点から不可能にしたループ作成を禁止する設定を行った。テナント全体でいので、Azure AD Connect の設定後に、手動で AD FS

グループ作成を禁止するためには、Azure AD ディレの代替ログイン ID を無効に設定する必要があった。

クトリ設定の EnableGroupCreation 項目を False に設

フェデレーション認証を用いる場合、Office 365 の定する必要がある。なお、Office 365 テナント設定にサインイン画面で@の後ろにフェデレーションドメ

は、一般ユーザーによるセキュリティグループの作成

イン名を持つ文字列を入力すると AD FS のサインを制御する項目もあるが、これは Office 365 グルー

イン画面にリダイレクトされる。ウェブブラウザでプの作成とは独立した設定である。この点について、Office 365 にサインインする際の利用者の手間を軽Microsoft 社のオンライン文書では記述が不明確であ減するために、Office 365 サインイン用のスマートるので注意を要する。

リンクを作成した。このスマートリンクの URL にア

上記の設定により、一般ユーザーによる Office 365

クセスすると、最初に AD FS のサインイン画面が表

グ ル ー プ の 作 成 は 禁 止 で き る 。し か し 、Exchange示される。さらに、スマートリンクの URL は複雑でOnline や SharePoint Online には、グループ作成用インあるので、スマートリンクにリダイレクトする URL

タフェースが表示されたままであり、これを操作した

https://office365.iii.kyushu-u.ac.jp/login を用意した。

時点でエラーが表示される挙動を示す。これは一般の試験運用中に、Skype for Business アプリケーション

利用者にとって不親切だと考えられるので、Exchange

でのサインインは挙動が異なることが判明した。「サOnline と SharePonint Online において、一般ユーザー

インイン アドレス」欄には、AD FS のサインインに用に Office 365 グループを作成させない設定を行った。

いる文字列ではなく、Office 365 の UPN を入力する必

ただし、これらを個別に設定するだけでは、テナント

要がある。その後で表示される AD FS のサインイン

全体で Office 365 グループの作成を禁止するには不十

画面は前述の通りである。

分であり、上述の Azure AD に対する設定が必須であ

5.5 AD レプリケーション

ることに注意されたい。

5.4 サインイン手段の整備

今回、移行作業の最初の段階では、Azure の VNet
上に配備したオンプレ AD ドメインコントローラにおAzure AD にてフェデレーション認証を用いて AD

いて、レプリケーションを実施しない独立した状態でFS にリダイレクトされるフェデレーションドメイン

稼働させ、テスト用ユーザーを作成した状態で Azure

として、前記 3 個のドメイン名を設定した。AD FS

AD と同期させて動作を確認した。次いで、全学共通

ではサインインに、userPrincipalName 属性値である

ID 管理システムと連携するオンプレ AD ドメインコン

トローラからレプリケーションさせて試験運用を行っ

予期間を経て、全学共通認証基盤から削除され、それた。しかし、今回この段階で問題が発生した。

に伴いオンプレ AD ユーザーも削除される。オンプレ

Microsoft 社は静的 NAT を含め NAT 経由での Ac-

AD から削除されたユーザーは Azure AD Connect にtive Directory の動作検証を行っておらず、実際に NAT

よって Azure AD から削除される。今回、年度末に非経由ではドメインコントローラのレプリケーションは構成員となったオンプレ AD ユーザーが削除された時動作しない。全学共通 ID 管理システムと連携するオ

点で、AD 同期に問題が発生した。Azure AD Connect

ンプレ AD ドメインコントローラは、今回 Azure 上のでは、誤った削除から保護するために削除できる件数

システム構築を発注した業者とは別に、全学共通認証の閾値が既定で 500 に設定されており、閾値以上の基盤の運用業者に依頼して仮想化基板上に設計構築し削除を試みた場合にはエラーが発生し Azure AD からていたが、このドメインコントローラの全通信は仮想

ユーザーは削除されない。閾値の上限を解除、または、化基盤で NAT を経由する構成となっていた。しかし、削除件数以上に設定するまで削除エラーは回復せず、そのことを九州大学の担当者は把握できておらず、原削除エラーが発生している間は一切の AD 同期が行わ因の特定が困難であった。

れない。今回は一時的に閾値の上限を解除することで5.6 AD 同期

問題を解消した。

今回、オンプレ AD のレプリケーションを設定した

5.7

ProPlus ライセンスの移行

のち最初の Azure AD への同期では、約 3 万弱のオブ

九州大学の EES には Office 365 ProPlus のライセン

ジェクトに対する処理が発生した。その際に、Azure

スが含まれるが、それは構成員人数分のライセンスでAD が現在ビジー状態でありエラーが発生した旨を知あるので、複数の Office 365 テナントに割り当てるこ

らせる「ID 同期のエラーレポート」メールが管理者とはできない。それゆえ、旧環境から新環境への移行

アドレス宛に計 500 通以上送信された。Microsoft サ

にあたり、ライセンスをテナント間で移行させる必要ポートへの問合せに対する回答に従い経過を観察したがあった。ただし、テナント間でライセンスを移行さところ、翌日には問題が解消して同期が完了した。こせる場合は、ライセンス移行手続き開始後最低 30 日

れが Azure AD 側の一時的な問題だったのか、大量の間は猶予状態として移行元テナントでライセンスを利同期を行ったことが原因だったのかは不明である。

用できる。

今回の試験運用は、一部ユーザーにだけ Office 365

一方、利用者が移行元テナントからインストールしへのサインインを許可した状態で行ったが、ユーザー

た ProPlus については、移行元テナントに紐付いたラのサインイン禁止設定において問題が発生した。当イセンスが失効すると別テナントでライセンス認証で初、Office 365 テナント側で個別ユーザーのサインイ

きるのではなく、利用者自身の作業によりライセンス

ンを禁止する操作を行ったが、その後サインインが自情報を削除する必要がある。ここで、Microsoft Office

動的に許可されていることが判明した。一般に、オン

アプリケーション利用時の Office 365 へのサインイ

プレ AD から Azure AD に同期された内容であってもンと、ライセンスが所属するテナントとは全く独立

Office 365 テナント側で行った変更は維持されるが、オであり、アプリケーションで Office 365 からサイン

ンプレ AD でユーザー情報に変更があると、Azure AD

アウトしてもライセンス認証は解除されない。OS が側の設定は上書きされ Office 365 テナント側で行った

Microsoft Windows の場合、インストール済みのライ変更は失われる。ここで、オンプレ AD ユーザーの有センス情報を削除するには、複数手順のコマンドラ

効性を示す Enabled 属性が Office 365 のサインイン許

イン作業が必要である。これは一般の利用者には難可設定に同期される。今回は、試験運用中にオンプレ

易度が高いと判断し、Office を一旦アンインストール

AD ユーザーへのライセンスコードの設定作業などをしてから再インストールする手順を案内した。OS が行ったことから、オンプレ AD の Enabled 属性が同期

macOS の場合には、Microsoft 社が提供するライセン

され、Office 365 のサインインが許可されたと考えら

ス認証を抹消するツールが利用できる。しかし、ライれる。最終的に、オンプレ AD ユーザーの Enabled 属

センスの再認証には注意を要する。ウェブブラウザな性を False に設定することで問題を回避したが、このどで移行元テナントなど、ライセンス認証先としたい

手段はオンプレ AD が他のサービスでも利用されていテナントとは別のテナントにサインインしている状態

る場合には選択できない。

で、ライセンス認証のない Office アプリケーションを

九州大学の構成員ではなくなった者は、一定の猶起動すると、そのサインイン中のテナントを対象に自動的にライセンス認証を行ってしまう。場合によって協調作業を行う利用者間では一般的に双方の全学基本

はウェブブラウザを終了していてもサインイン状態がメールアドレスを把握していると思われることから、維持されていると、同様の挙動を示す。

Office 365 でユーザーを指定する際の利便性も大いに

5.8 ユーザーによる移行作業向上したと考えられる。

新環境の正式サービス開始前に、旧環境のサービス

旧環境では、Office 365 サービス運用部門が関知

廃止と新環境のサービス開始について全学通知によりしていない多数の Office 365 グループが作られてい周知を図り、また、サービス開始直後に、旧環境へのた。Exchange Online は無効化していたことからメー

サインイン経験のある全ユーザーに対して新環境へ移ルに関する不都合は生じていなかったが、SharePoint

行する必要がある旨をメールで案内した。その後、旧Online のチームサイトが作成され記憶容量が消費され環境へのサインイン数を観察していたが想定を下回るていた。新環境では一般ユーザーによる Office 365 グ

減少数だったことから、旧環境のサインイン画面に移ループの作成を禁止したことで、それに関する資源の行案内を表示する設定を行い、また、4 月以降に旧環消費を運用部門が管理できるようになった。

境を利用したユーザーに対して再度メール通知を行った。その上で、当初の予定通り 2018 年 7 月末に、旧6 今後の計画と課題

環境テナントの全ユーザーに対しサインインを禁止す

九州大学では、現在独自システムで稼働しているる処理をおこなった。しかしながら、2018 年 8 月以

全学基本メールサービスを 2018 年 12 月に Exchange

降、Office 365 にサインインできなくなった、PC に

Online に移行する予定である。現時点では、新環境テ

インストールした Office を利用できなくなったといナントで Exchange Online を有効にしているが、メーう多数の問合せが寄せられ、また、旧環境テナントのルは現行のメールサーバに配送される状態である。今OneDrive for Business にアクセスしたいという要望も後、全学基本メールサービスの受け入れに対する準多数寄せられた。サインイン不能や Office 使用不能の備を行う必要がある。現行の送信用 SMTP サーバで問合せに対しては新環境への移行を案内し、OneDrive

は、From フィールドに任意のアドレスが記載された

for Business へのアクセス要望については個別にサイメールの送信を許可しているが、Exchange Online で

ンインブロックを解除する処理を行った。特に Office

は Azure AD のユーザー情報に登録されたメールアド

365 ProPlus と OneDrive for Business については通常

レス以外を記載したメールは送信できない。そこで、の利用時にはユーザーが Office 365 テナントを意識し別途 SMTP サーバを学内に稼働させる予定である。

ていないと考えられることから、より十分な周知期間と周知活動が必要だったと思われる。

新環境テナントの現在の設定では、全ユーザーは他のユーザーの一覧を閲覧できない。しかし、教職員が旧環境テナントで主に利用されていたサービスは教職員一覧を閲覧することには問題がなく、むしろ閲

OneDrive for Business であった。前述の通り、旧環境

覧できる方が望ましい。これは、Exchange Online ののファイルは利用者各自で新環境に移行してもらうこ

アドレス帳ポリシー機能により GAL を分割することととした。しかし、OneDrive for Business ではテナンで実現可能であり、今後の対応課題である。

ト間でファイルを共有できるよう設定しても、テナン

Microsoft 社は Skype for Business から Teams へのトをまたがったファイルのコピーはできず、テナント移行を計画していると発表している。このことから九間で直接ファイルを移行する方法は見出せなかった。

州大学でも Teams の利用について検討中である。しかそれゆえ、移行方法として、旧環境から手元に一旦ファし、Teams の活用には Office 365 グループの作成が必

イルをダウンロードしたのち新環境へとアップロード

要である。Office 365 グループ作成の運用方法についする方法を案内せざるを得なかった。ただし、この方て今後検討を進める。

法では旧環境ファイルのバージョン履歴は失われる。

5.9 効果

参考文献

新環境ではユーザー認証を全学共通 ID の SSO-KID[1] Yoshiaki Kasahara, Takao Shimayoshi, Masahiroに統合したこと、簡便なサインイン手段を整備したこ

Obana, and Naomi Fujimura. Our experience withとにより、Office 365 へのサインインの利便性は著しintroducing microsoft office 365 in kyushu univer-く向上したと考えられる。また、Office 365 の UPN

sity. In Proceedings of the 2017 ACM Annual Con-を全学基本メールアドレスとしたが、ファイル共有や

ference on SIGUCCS, pp. 109–112, 2017.