第17回Office 365勉強会に登壇します

今週の土曜日に品川の日本Microsoftで開催される第17回Office 365勉強会に登壇させて頂きます。

今回は、既に導入がかなり進んでいるということもあって、なかなか改めて話題に上がることも少ないExchange Onlineにスポットを当ててみようということで、Exchange Online特集になっております。

私のセッションでは、
「意外と知らない最近のExchange Online」
ということで、ここ数年で追加された、もしくは追加予定のExchange Onlineの新機能や仕様変更についてお話ししたいと思います。

お時間のある方は是非ご参加頂けると幸いです。

Microsoft MVPを再受賞しました

おかげさまで、MicrosoftのMVPアワードをOffice Servers and Servicesの分野で受賞しました。
2012年にOffice 365で初受賞して以来、5年連続での受賞となります。

これも偏にblogやコミュニティ運営などでご協力を頂いている皆さまの応援のおかげと感謝しております。

これからもよろしくお願い致します。

MVP_Logo_Horizontal_Secondary_Blue286_RGB_300ppi

ExpressRoute for Office365の期待とギャップ

先日、Microsoftより以下のようなメッセージが示されました。

Azure ExpressRoute is not required or recommended for Office 365 except where mandated to use direct networking for regulatory purposes or where a network assessment for Skype for Business connectivity requires it

また、先日のde:codeのイベントのExpressRoute for Office 365関連の講演においても、しきりに「ExpressRouteはセキュリティ向上のためのソリューションではありません」というメッセージを出しており、少し自分的に違和感を覚えておりました。

今回はExpressRoute for Office 365と聴いてイメージする物と、実際のサービス導入後の構成のギャップについて少し整理したいと思います。

まず、標準のOffice 365の構成が下図の左側だとします。ExpressRouteでOffice 365に直接接続出来るようになると聴くと、何となく以下の問題が解決されるように思えます。(右側のイメージ)

  1. インターネット上に機密情報を置くことへの不安
  2. インターネットアクセスが急増することによる回線、NW機器やProxyサーバーなどのパフォーマンスの不安
  3. インターネットアクセスのログのモニタリングやOffice365側のURL/IPアドレスの増減に対応する運用負荷に関する不安

20160601_01

確かにExpressRoute for Office 365を入れると、いくつかの問題点は解消されるのですが、実際にはいくつかの点でギャップが発生します。

簡単に纏めると以下の図上の3点になると思います。

20160601_02まず、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に統合する旨の情報は流れておりましたが、遂に今朝、古い同期ツールを利用しているユーザーに対して以下のようなメールが届きました。

20160414_01

利用の継続のためには、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アワードについて知りたい方はこちら

MVP_Logo_Horizontal_Secondary_Blue286_RGB_300ppi

初受賞が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度その設定をポーリングします。20150724_01

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をプライマリに昇格させようと思います。
20150724_02

fs02をプライマリに昇格させるには、fs02でPowerShellを起動して、以下のコマンドを実行します。

Set-AdfsSyncProperties -Role PrimaryComputer

前述の通り、クラスターなどとは違ってAD FSファームのプライマリやセカンダリはDBの同期のためだけに利用されている物になりますので、これだけで完了します。

続いて、fs03など更に別のセカンダリが存在している場合は、今までfs01に向けてポーリングしていた物をfs02からポーリングするように設定する必要があります。fs03などでプライマリのFQDNを指定した以下のコマンドを実行してポーリング先を変更します。

Set-AdfsSyncProperties -PrimaryComputerName fs02.contoso.com

これで、fs02へのプライマリの役割のスイッチオーバーが完了です。

さて、この状態でようやくfs01の故障対応が完了してサーバが立ち上がってきたとします。fs01の設定は以前のままになりますので、立ち上がってきた状態は以下の感じになります。
20150724_03

このままスイッチバックをすると、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は利用されなくなったので必要に応じて別の環境で作成してエクスポートした物を利用します。
20150707_01 20150707_02 20150707_03 20150707_04 20150707_05 20150707_06

基本的にはローカルコンピュータにインポートして、インポート先を自動的に証明書ストアを選択するとしておけば、MMCで確認すると[証明書(ローカルコンピュータ)]-[個人]-[証明書]に表示されると思います。
20150707_16

これで準備は完了です。

 

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

20150707_08

続いて、こちらの情報を指定してSet-AdfsSslCertificateコマンドレットを実行します。この瞬間、AD FS#1の通信は新しい証明書に切り替わりますので、テストクライアントにHostsを設定するなどして、切り替わり後の証明書に問題がないことはこのタイミングで見ておいた方が良いでしょう。

Set-AdfsSslCertificate -Thumbprint 新しい証明書のThumbprint

20150707_09

このコマンドは、主にAD FS管理ツールによって実施されない2つのことを実施しています。特に後者の方は手動でやると面倒なので、コマンド 1発で済ませられるのは便利ですね。

  • SSL証明書のバインドの変更(手動の場合netshコマンドで変更する)
  • SSL証明書の秘密鍵に対してAD FSサービスがアクセスできるよう権限設定を行う(手動の場合証明書管理ツールから変更する)

いきなり証明書を切り替えるのには若干違和感はありますが、1番の工程より先に3番の工程を実施した場合、セカンダリ側のAD FSで秘密鍵へのアクセス権限の問題でAD FSの133番のエラーが出ます。
20150707_13

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

20150707_10

ファーム内の各サーバで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コマンドレットでは差し替えてくれないので手動で差し替えます。
20150707_11

コマンドは最初に設定した際と同じく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}

20150707_12

7.Web Application Proxy #1のSSL証明書更新(Set-WebApplicationProxySslCertificate)

続いて、WAP(旧AD FS Proxy)側に移ります。こちらもまずは各コンピュータのSSL証明書の差し替えから入ります。コマンドレット名が変わりますが基本的には同じです。

Set-WebApplicationProxySslCertificate -Thumbprint 新しい証明書のThumnbprint

20150707_14

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

20150707_15

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メール」アプリケーションを利用します。[開始する]を選択すると、アカウントの設定画面が開きます。
Screenshot_2015-06-12-10-48-39 Screenshot_2015-06-12-10-48-48 Screenshot_2015-06-12-10-48-57

ここで、Eメールアドレスとパスワードを入力します。
Screenshot_2015-06-12-10-49-26

【注意】ここでは、[手動セットアップ]を選択します。

[次へ]を押して自動セットアップを行っても自動的にサーバ情報を取得してアカウントが設定できるのですが、IMAPを利用したプロファイルになってしまい、メールの送受信はできますが、それ以外の機能やサーバ側でのポリシー管理ができなくなってしまいます。
Screenshot_2015-06-12-14-22-04 Screenshot_2015-06-12-14-22-06 Screenshot_2015-06-12-14-22-09 Screenshot_2015-06-12-14-23-06 Screenshot_2015-06-12-14-23-18 Screenshot_2015-06-12-14-23-25 Screenshot_2015-06-12-14-23-41 Screenshot_2015-06-12-14-24-16

手動セットアップを選ぶと、アカウントの種類を選択する画面になります。ここれは、[Exchange ActiveSync]を選択します。
Screenshot_2015-06-12-10-49-32

ドメイン\ユーザー名と表示されている部分は、\に続いて先ほど入力したメールアドレスの@の前の値が入っていますので、Office 365にログインする際に使っているUPN(ユーザー名@ドメイン名)の形式のアカウント名を入れます。また、サーバは@の後の値が入っていますので、ここを手動で[outlook.office365.com]を入力します。入力が完了したら、[次へ]を押します。
Screenshot_2015-06-12-10-50-12 Screenshot_2015-06-12-10-51-00

スマートフォンの制御をアプリケーションに許可するので、[OK]をクリックします。
Screenshot_2015-06-12-10-51-24

アカウントの基本設定を行います。プッシュ通知(常時接続)かつメモを除く全ての情報が同期されるように設定されてますので、必要に応じてこのデフォルトの値を変えます。
Screenshot_2015-06-12-10-51-32 Screenshot_2015-06-12-10-51-42

作成されたアカウントのプロファイルに識別用の名前を付けます。
Screenshot_2015-06-12-10-51-57

最後に、Office 365のポリシーによって制御することのできる操作の権限の許可(いっぱい有ります)を確認して[有効にする]をクリックします。まあ、リモートワイプができるくらいなので基本は全ての制御権限をOffice 365に渡すと思った方が良いと思います。
Screenshot_2015-06-12-10-52-06 Screenshot_2015-06-12-10-52-18 Screenshot_2015-06-12-10-52-36 Screenshot_2015-06-12-10-52-51

これで設定は完了です。良いOffice 365ライフを!
Screenshot_2015-06-12-11-06-27

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
}

スクリプトを作っていく上では、「英語か日本語以外に設定している人がいないだろうから…」という思い込みで作るのでは無く、こうしたエラーを引き起こす原因となる例外の発生確率を少しでも減らす努力をしていくと、最終的に管理者の負担軽減に繋がるのではないかと思います。