おかげさまで、MicrosoftのMVPアワードをOffice Servers and Servicesの分野で受賞しました。
2012年にOffice 365で初受賞して以来、5年連続での受賞となります。
これも偏にblogやコミュニティ運営などでご協力を頂いている皆さまの応援のおかげと感謝しております。
これからもよろしくお願い致します。
Category Archives: Office365
ExpressRoute for Office365の期待とギャップ
先日、Microsoftより以下のようなメッセージが示されました。
また、先日のde:codeのイベントのExpressRoute for Office 365関連の講演においても、しきりに「ExpressRouteはセキュリティ向上のためのソリューションではありません」というメッセージを出しており、少し自分的に違和感を覚えておりました。
今回はExpressRoute for Office 365と聴いてイメージする物と、実際のサービス導入後の構成のギャップについて少し整理したいと思います。
まず、標準のOffice 365の構成が下図の左側だとします。ExpressRouteでOffice 365に直接接続出来るようになると聴くと、何となく以下の問題が解決されるように思えます。（右側のイメージ）
- インターネット上に機密情報を置くことへの不安
- インターネットアクセスが急増することによる回線、NW機器やProxyサーバーなどのパフォーマンスの不安
- インターネットアクセスのログのモニタリングやOffice365側のURL/IPアドレスの増減に対応する運用負荷に関する不安
確かにExpressRoute for Office 365を入れると、いくつかの問題点は解消されるのですが、実際にはいくつかの点でギャップが発生します。
簡単に纏めると以下の図上の3点になると思います。
まず、ExpressRoute for Office 365を利用しても、主にCDNから配信されてくるデータはインターネット経由でしか取得できないため、①ExpressRouteの他にもインターネット接続を必要とする という点がございます。これにより、インターネット接続経由でOffice 365の一部の通信は継続するため、その運用管理負荷は無くなりません。
また、ExpressRoute経由で接続するのはテナントではなくIPアドレス単位になる為、②他社テナントにもExpressRouteを経由して接続できてしまいます。構成によっては、自社の管理下にあるFirewallやProxyなどをバイパスして外部のクラウドに接続できてしまうことになります。
更に、ExpressRouteを契約しても接続元IPの制限ができるようになる訳では無いので、③ExpressRouteを経由しないインターネットからもこれまで通り利用できてしまいます。
勿論、②はSharePoint OnlineであればテナントごとにURL空間が異なるので、そこを意識して.pacファイルで制御するなどすれば、ある程度は制御できると思いますし、③はAD FSを入れれてクラウドIDの利用を制限すれば社外からの認証を抑制することもできます。
ただ、こう言ったFit & Gapを整理していくと、Azureとは違ってOffice 365にExpressRoute接続すべき（したい）シーンというのは、かなり限定されるのではと個人的に感じます。
6/1に第15回Office365勉強会を開催します
既に満席になってしまっておりますが、6/1(水)の夜に株式会社ラック様の会議室をお借りしてOffice 365勉強会を開催します。
第15回 Office 365 勉強会 ～日本企業にとって必要なOffice 365のセキュリティ～
今回は動画配信は無しで、日本有数のセキュリティベンダであるラック様がパブリッククラウドであるOffice 365を利用するに至った経緯や苦労した点など、プレスリリースでは語れなかった深い部分まで聴かせて頂ければと思っております。
開催が迫ってまいりましたが、まだキャンセル待ちの方も多くいらっしゃいますので、参加ができなくなった方は忘れずキャンセルを入れて頂ければ幸いです。
以下の記事の対談をされていらっしゃるお二人に登壇をお願いしておりますので、事前に見られておくとスムーズに話が入ってくるかと思います。
【参考Web記事】
パブリック クラウドは危険? セキュリティのプロ、ラックの CTO に聞いてみた
【2分バージョン】セキュリティのプロはなぜパブリッククラウド Office 365 を選んだのか
DirSync、AADSyncのサポート切れ
Office 365とオンプレミスのActive Directoryを同期させるツールは標準で「ディレクトリ同期（DirSync）」「Azure AD Sync（AADSync）」「Azure AD Connect（AADConnect）」の3つの種類があります。
予てよりAADConnectに統合する旨の情報は流れておりましたが、遂に今朝、古い同期ツールを利用しているユーザーに対して以下のようなメールが届きました。
利用の継続のためには、2017年4月13日まで（通知から1年）にAADConnectにアップグレードしろということです。
幸い、32bit版のサポート切れに伴う64bit版への移行の際と違い、Server OSの要件が変わらないのと、ディレクトリ同期ツール自体が3時間に1度しか同期せず、比較的サービス断を伴う作業がしやすいので、そこまで障壁は高くないですね。
公開情報は以下にありますが、こちらでも何か注意点など見つかったら報告します。
Azure AD Connect: Windows Azure Active Directory 同期 (DirSync) のアップグレード
Microsoft MVPアワード再受賞しました
Microsoft MVPアワードをOffice 365の技術分野において再受賞しました。
（MVPアワードについて知りたい方はこちら）
初受賞が2012年になりますので、4年連続で頂いた形となります。これも、Office 365勉強会に来てくれた参加者の方や本blogを読んで頂いた皆さま、Office 365コミュニティで情報交流をさせて頂いている皆さまのおかげだと感謝しております。
日本DCも開設され、Windows 10やOffice 2016、ExchangeやSharePointの新バージョンや周辺のオンラインサービスの拡充など、Office 365にとって更に重要な年になってくると思いますが、これからのOffice 365の普及やUsageなどの向上のお役に立てればと思います。
AD FS 3.0におけるスイッチオーバー
複数台のAD FSにおいて冗長化を行う場合、AD FSファームを構成して冗長化を行います。
今回は、運用中においてサーバの障害やメンテナンスなどでAD FSファームのスイッチオーバーが必要になる際の手順などについて書きたいと思います。
まずは、おさらいとしてAD FSファームについて記載します。AD FSは、1台のプライマリAD FSサーバと複数台のセカンダリAD FSから構成されるAD FSファームを構成できます。
AD FSファームを構成すると、セカンダリは自身のデータベースに対する直接の書き込み（設定変更）を禁止し、指定したプライマリサーバからその情報を同期します。デフォルトでは、300秒（5分）に1度その設定をポーリングします。
Windows Server 2012 R2のAD FSファームは、証明書利用者信頼（Relying Party trusts）が5以下の場合は最大10台、それ以上の証明書利用者信頼の場合は最大5台のAD FSサーバでの構成がサポートされます。
Office 365のみを利用する環境であれば、「Device Registration Service」「Microsoft Office 365 Identity Platform」の2つが証明書利用者信頼として登録されることになりますので、10台で構成すれば10万を越えるような大規模な環境でも理論上は構成できることになります。（実際の環境では、DR環境にある別のデータセンタのAD FSサーバの台数も含めての台数になるので、もう少し収容ユーザー数は少なりますが）
また、構成可能なオブジェクト数は要求プロバイダー信頼と証明書利用者信頼で最大100がサポートされています。実環境としては使い切ることは無さそうですね。
さて、こんなケースを考えてみます。プライマリ AD FSのfs01が故障しました。復旧までにはかなり時間がかかる見込みです。この状態でも、ユーザーからfs02への認証要求は通常通り継続できますので問題は無いのですが、fs02はセカンダリなので設定変更などのオペレーションを実施することができません。
AD FSの設定変更を可能にするために、fs02をプライマリに昇格させようと思います。
fs02をプライマリに昇格させるには、fs02でPowerShellを起動して、以下のコマンドを実行します。
Set-AdfsSyncProperties -Role PrimaryComputer
前述の通り、クラスターなどとは違ってAD FSファームのプライマリやセカンダリはDBの同期のためだけに利用されている物になりますので、これだけで完了します。
続いて、fs03など更に別のセカンダリが存在している場合は、今までfs01に向けてポーリングしていた物をfs02からポーリングするように設定する必要があります。fs03などでプライマリのFQDNを指定した以下のコマンドを実行してポーリング先を変更します。
Set-AdfsSyncProperties -PrimaryComputerName fs02.contoso.com
これで、fs02へのプライマリの役割のスイッチオーバーが完了です。
さて、この状態でようやくfs01の故障対応が完了してサーバが立ち上がってきたとします。fs01の設定は以前のままになりますので、立ち上がってきた状態は以下の感じになります。
このままスイッチバックをすると、fs01は故障発生前の古い情報のままになってしまいますので、まずはfs02のセカンダリとして設定して情報が同期されるのを待ちます。
Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName fs02.contoso.com
最後に、fs01に再度スイッチバックを行います。
<fs01> Set-AdfsSyncProperties -Role PrimaryComputer <fs02> Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName fs01.contoso.com <fs03など> Set-AdfsSyncProperties -PrimaryComputerName fs01.contoso.com
AD FSファームの仕組み（静的なDB同期）が分かってしまえば挙動については比較的単純なのでご理解頂けると思います。
AD FS 3.0におけるSSL証明書更新
Windows Server 2012 R2に搭載されているAD FS 3.0も、だいぶ導入が増えてきたように思えます。最初の方に導入された方は導入から1年経過してSSL証明書の更新などを迎えられているユーザーもいらっしゃるかと思います。
今回は、あまり公開されている情報も無く、トラブルも多く聞かれているので、AD FS 3.0のSSL証明書更新についてまとめていきたいと思います。（なお、こちら基本的には以前勉強会で実施したLT「ADFSの証明書入れ替えではまった話」をブラッシュアップした物になります）
まずは、AD FSならびにWeb Application Proxyの各サーバに新しい証明書をインポートします。Windows Server 2012 R2から、AD FSの動作にはIISは利用されなくなったので必要に応じて別の環境で作成してエクスポートした物を利用します。
基本的にはローカルコンピュータにインポートして、インポート先を自動的に証明書ストアを選択するとしておけば、MMCで確認すると[証明書（ローカルコンピュータ）]-[個人]-[証明書]に表示されると思います。
これで準備は完了です。
1.AD FS #1のSSL証明書更新（Set-AdfsSslCertificate）
AD FS#1（AD FSファームを構成しているプライマリ機をAD FS#1と便宜上表記します）において、PowerShellを起動します。
まず、新しい証明書のThumbprintを取得します。調査方法は色々ありますが、オフィシャルで案内されている証明書管理ツールからだとスペースが入ったりして面倒なので、dir（これはGet-ChileItemのエイリアスです）コマンドで表示してしまうのが一番楽です。有効期限や発行元などの情報を元に、新しい証明書を特定してThumbprintをメモ帳などにコピーします。
Get-ChildItem cert:\LocalMachine\My\ | FL
続いて、こちらの情報を指定してSet-AdfsSslCertificateコマンドレットを実行します。この瞬間、AD FS#1の通信は新しい証明書に切り替わりますので、テストクライアントにHostsを設定するなどして、切り替わり後の証明書に問題がないことはこのタイミングで見ておいた方が良いでしょう。
Set-AdfsSslCertificate -Thumbprint 新しい証明書のThumbprint
このコマンドは、主にAD FS管理ツールによって実施されない2つのことを実施しています。特に後者の方は手動でやると面倒なので、コマンド 1発で済ませられるのは便利ですね。
- SSL証明書のバインドの変更（手動の場合netshコマンドで変更する）
- SSL証明書の秘密鍵に対してAD FSサービスがアクセスできるよう権限設定を行う（手動の場合証明書管理ツールから変更する）
いきなり証明書を切り替えるのには若干違和感はありますが、1番の工程より先に3番の工程を実施した場合、セカンダリ側のAD FSで秘密鍵へのアクセス権限の問題でAD FSの133番のエラーが出ます。
2.AD FS#2以降のSSL証明書更新（Set-AdfsSslCertificate）
同様の操作を、AD FS#2（#3や#4などがある場合はそちらも）についても行います。
3.AD FS#1でAD FSのサービス通信証明書の変更（Set-AdfsCertificate -CertificateType Service-Communications）
続いて、AD FSのサービス通信証明書を変更します。従来でいうSSL証明書の入れ替えの作業の工程です。GUIから実施してもいいですが、せっかくWindows Server 2012 R2の環境なのでPowerShellから実施してみます。
Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint 新しい証明書のThumbprint
ファーム内の各サーバでAD FSサービスを再起動するように指示がありますので、順に行います。
4.AD FS#1でAF FSサービスの再起動
最初にプライマリを実施します。
5.AD FS#2以降でAD FSサービスの再起動
続いてセカンダリ。セカンダリは5分おきにプライマリに設定変更をポーリングしてますので、念のため5分程度待ってから実施します。
これで基本的な項目は完了です。
6.全AD FSでKB2973873の再対応
Lync MobileなどからAD FS接続ができないという問題（KB2973873）のために、netshでSSL証明書のバインドを手動で修正している場合は、こちらの方はSet-AdfsSslCertificateコマンドレットでは差し替えてくれないので手動で差し替えます。
コマンドは最初に設定した際と同じくnetshコマンドで行いますが、上書きができないので削除～再指定を行います。AD FSのAppidは確認した限りでは固定の様ですが、エラーが出たら上記のKBをご確認いただき適宜修正下さい。
netsh
HTTP
DELETE SSLCert IPPORT=0.0.0.0:443
ADD SSLCert IPPORT=0.0.0.0:443 Certhash=新しい証明書のThumnbprint Appid={5d89a20c-beab-4389-9447-324788eb944a}
7.Web Application Proxy #1のSSL証明書更新（Set-WebApplicationProxySslCertificate）
続いて、WAP（旧AD FS Proxy）側に移ります。こちらもまずは各コンピュータのSSL証明書の差し替えから入ります。コマンドレット名が変わりますが基本的には同じです。
Set-WebApplicationProxySslCertificate -Thumbprint 新しい証明書のThumnbprint
8.Web Application Proxy #2以降のSSL証明書更新（Set-WebApplicationProxySslCertificate）
7番と同様です。
9.Web Application Proxy のアプリケーションの設定更新
Web Application Proxyで公開されているアプリケーション（通常はAD FSのみになりますが）について、外部証明書として設定されている証明書を差し替えます。Set-WebApplicationProxyApplicationに必要な引数はGUIDで入力が面倒なので、Get-WebApplicationProxyApplicationしたものをそのままパイプしてしまう方が楽ですね。
Get-WebApplicationProxyApplication | Set-WebApplicationProxyApplication -ExternalCertificateThumbprint 新しい証明書のThumnbprint
10.全Web Application ProxyでKB2973873の再対応
6番と同様の工程をWAP側でも実施します。
という訳で、今回はAD FS 3.0のSSL証明書の入れ替えについてご紹介しました。IISが無くなった分、AD FS 2.0と比較して少し面倒ですが、手順さえ確立できれば後は作業です。
それにしても、AD FSは証明書関係は色々ありますね…、鬼門でしょうか。
関連記事： ADFS証明書の更新について （2008 R2の際の記事になります）
Xperia Z4でOffice 365（Exchange Online）
Sonyから、待望のフラッグシップモデルのスマートフォンXperia Z4が発売されました。
今回は、スマートフォンを利用する上で一番よく利用すると思われるExchange Onlineの設定方法を紹介します。
Exchange Onlineに接続するには、標準の「Eメール」アプリケーションを利用します。[開始する]を選択すると、アカウントの設定画面が開きます。
ここで、Eメールアドレスとパスワードを入力します。
【注意】ここでは、[手動セットアップ]を選択します。
[次へ]を押して自動セットアップを行っても自動的にサーバ情報を取得してアカウントが設定できるのですが、IMAPを利用したプロファイルになってしまい、メールの送受信はできますが、それ以外の機能やサーバ側でのポリシー管理ができなくなってしまいます。
手動セットアップを選ぶと、アカウントの種類を選択する画面になります。ここれは、[Exchange ActiveSync]を選択します。
ドメイン\ユーザー名と表示されている部分は、\に続いて先ほど入力したメールアドレスの@の前の値が入っていますので、Office 365にログインする際に使っているUPN（ユーザー名＠ドメイン名）の形式のアカウント名を入れます。また、サーバは@の後の値が入っていますので、ここを手動で[outlook.office365.com]を入力します。入力が完了したら、[次へ]を押します。
スマートフォンの制御をアプリケーションに許可するので、[OK]をクリックします。
アカウントの基本設定を行います。プッシュ通知（常時接続）かつメモを除く全ての情報が同期されるように設定されてますので、必要に応じてこのデフォルトの値を変えます。
作成されたアカウントのプロファイルに識別用の名前を付けます。
最後に、Office 365のポリシーによって制御することのできる操作の権限の許可（いっぱい有ります）を確認して[有効にする]をクリックします。まあ、リモートワイプができるくらいなので基本は全ての制御権限をOffice 365に渡すと思った方が良いと思います。
これで設定は完了です。良いOffice 365ライフを！
PowerShellで全ユーザーの予定表権限を変更
全ユーザーの予定表の権限を変える場合、ユーザーの言語設定やOWAログオンの有無などによって、設定をするべきフォルダ名が username:\Calendar になったり username:\予定表 になったりします。
これって結構スクリプト化する上では悩みの種なんですよね。
仕方が無いので、[予定表]で設定できなければ[Calendar]だろうと決め打ちしてスクリプトを作ったりするケースがよく有ります。例えば、全ユーザーのCalendarもしくは予定表フォルダの権限をReviewerに変更する場合、
$mbxs = Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited
foreach ($mbx in $mbxs){
$alias = ${mbx}.alias
try{ Set-MailboxFolderPermission -Identity "${alias}:\予定表" -User "default" -AccessRights Reviewer -ErrorAction Stop }
catch { Set-MailboxFolderPermission -Identity "${alias}:\Calendar" -User "default" -AccessRights Reviewer -ErrorAction Stop }
}
とやったりしますが、微妙にこれでもエラーになってしまう場合が有って、例えば中国語など別の言語圏のフォルダ名になってしまっている場合や、フォルダ名の破損・重複などで[予定表1]などがデフォルトの予定表フォルダとして指定されてしまっている場合です。
中国語とかならともかく、[予定表1]とかはさすがに分からないですよね…。こういった場合、いくつか方法はありますが、私の場合は Get-MailboxFolderStatistics を利用します。これは、ルート以下のそれぞれのフォルダのアイテム数や格納サイズを出してくれる物ですが、この中に FolderType という属性があり、それが Calendar の物が予定表のフォルダ名です。
あとは、このIdentityの値が [ユーザ名\フォルダ名] の形式なので、Set-MailboxFolderPermissionの指定形式 [ユーザー名:\フォルダ名] に変換すれば大丈夫です。
$mbxs = Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited
foreach ($mbx in $mbxs){
$alias = ${mbx}.alias
$path = (Get-MailboxFolderStatistics $alias | ? {$_.FolderType -eq "Calendar"}).Identity -replace "\\",":\"
Set-MailboxFolderPermission -Identity $path -User "default" -AccessRights Reviewer
}
スクリプトを作っていく上では、「英語か日本語以外に設定している人がいないだろうから…」という思い込みで作るのでは無く、こうしたエラーを引き起こす原因となる例外の発生確率を少しでも減らす努力をしていくと、最終的に管理者の負担軽減に繋がるのではないかと思います。
ADFSでOneDrive for Businessのアクセス制御
Office 365の導入を検討しているユーザーから良く聞かれることの一つに、「会社のネットワークの中からだけOffice 365が利用できるようにできるか」ということがあります。
Microsoftやベンダの立場としては「AD FSで制御できます」と答えるべき所だとは思うのですが、この時点でのこの回答は正しくも有り、そして間違ってもいます。私は、そういった場合「AD FSで認証に関する制御を行う事ができますが、それで要望されていることを満たすかどうかはお客様の要件次第です」と回答しています。
これは、AD FSを利用したOffice 365へのアクセスの仕組みが、「認証」「認可」に役割が分かれていることに関係します。AD FSは「認証」を行い、Office 365（の各アプリケーション：例えばOneDrive for Business）は「認可」を行います。
AD FSでは、認証を行う時にID/PASSが合っているということの他に、条件を付けることができます。例えば、今回のケースでは「アクセス元が社内ネットワークからである」というという条件を加えることができます。これにより、インターネットからのアクセスでは「認証」されることがないので、Office 365の利用を制御できることができます。
これなら要件が満たせるのでは？ということになりますが、これは1つ観点が抜けています。Office 365では、AD FSで認可を受けてきているということは認識してますが、それがどういった条件の下で認可を受けてきたかどうかは情報として要求しておらず（アカウント名とImmutableIDというユーザーを一意に識別する特別な符号のみ）、認識しません。この為、今アクセスしてきているユーザーのアクセス元が社内ネットワークからであるかどうかは分からないのです。
具体的に言うと、一度社内ネットワーク内でAD FSで認証し、Office 365にアクセスした後に、そのままの状態（例えば、ブラウザを開いたまま）でその端末を外に持ち出した場合、アクセスが一定期間継続できてしまうのです。
これでどの程度の期間アクセスが継続できるのか（再度認証が必要になるのはどういった条件か）というのはOffice 365側で決められているので、AD FS側で制御することができません。タイトルに戻るのですが、OneDrive for Businessのスマートフォン用アプリでは、私が試した限り一度AD FSで認証をかけるとその後AD FSに認証されるというケースはほぼ無いように見えます。（常時接続するので、アイドルタイムアウトしない為ではないかと思いますが）
従来の考え方ですと、そもそも社内端末を社外に持ち出して使うこと自体認められていないので問題ないという形になったのかもしれませんが、今後BYODやスマートフォンなどからの利用が進んでいくと、端末が社内NW、社外NWと行き来したりするというケースは普通に出てきます。
こういったケースが併用される環境では、IPアドレスをベースにしたアクセス制御よりはMDM（モバイルデバイス管理）などで端末単位での認証をしていく方が現実的になっていくのかもしれませんね。