Microsoft 365 の Suite 商品は、よく「全部入り」という表現をされることがあります。確かに、Microsoft 365 Suite は、旧称が Secure Productivity Enterprise であり主に以下のサービスをバンドルした商品になっています。
例えば、最上位の Microsoft 365 E5 であれば、Offiece 365 E5 と EMS E5 と Windows 11 Enterprise E5 のバンドル商品です。
ぱっと見、これさえあれば何でもできる様に思えますが、常に色々な機能が追加されているクラウドサービス。Microsoft 365も例外ではなく Microsoft 365 E5ライセンスだけではカバーされない領域も最近多くなってきました。
この記事では「全部入り」のSKUを改めて作るとしたらどうなるかということを考えてみました（なお、価格は記事作成時点の公開情報を元にした参考情報となっています）
Continue reading登録キャンペーンによる先進的で強力な認証の推進 | Japan Azure Identity Support Blog (jpazureid.github.io) でも案内されていますが、Entra ID の登録キャンペーン（より強力な多要素認証として Microsoft Authenticator のインストールをユーザーに依頼する管理者機能）が既定で有効化されはじめてます。
従来より、SMSや電話番号での認証は相対的にセキュリティレベルが低く、Microsoft からは非推奨になっていましたのでこの機能自体は良い物だと考えているのですが、環境によっては注意が必要なケースがありますので紹介します。
そもそもこの機能は 2 年近く前から存在していて、管理者により有効化することができたのですが、今回の変更によって「①既定で有効化される」「②ユーザー判断でスキップできる回数に上限が設定される」ことになりました。
有効になった状態でログインし、電話での多要素認証を実施すると、以下の様な画面になります。[次へ] を押すと Microsoft Authenticator の設定画面に推移し、[今はしない] を押すと通常のログイン後の画面に推移します。
ポイントとしては、[今はしない] というのは3回しか押すことができないということです。
特に注意が必要なのは、以下の様なシナリオです。
これらに該当する場合は、3回スキップする前に以下の画面で Microsoft Authenticator が利用できない環境のユーザー（今回の例だと、唯一の管理者アカウント）を登録キャンペーンから除外するという設定を入れてください。
※対象が不特定多数の場合は、状態を [Microsoftマネージド] から [無効] にして組織全体で無効化することも可能です
ただ、前述の通り SMS や電話での多要素認証はセキュリティレベルが低く、既に非推奨となっております。Microsoft Authenticator が利用できない環境でも安全に多要素認証が利用できる OTP デバイスや FIDO2 セキュリティキーなどが手頃な価格で市場でも出そろってきておりますので、これを機にご検討いただくことも良いのでは無いかと思います。
また、不幸にも既に 3 回スキップしてしまった場合は、内部調整の上、特例で一度だけMicrosoft Authenticator を登録して貰ってログイン後、上記で登録キャンペーンの無効化とMFA情報から削除を実施するか、あるいは Microsoft サポートに連絡して対処を依頼して下さい。（本人確認などで時間はかかると思いますが）
3回スキップすると、次回から以下の画面から [次へ] を押して Microsoft Authenticator をインストールしないと先に進めなくなります。
この記事は Office 365 Advent Calendar 2019 に参加しています
2019年の11月18日と19日、Office 365でExchange OnlineとTeamsを中心とした大規模な障害が立て続けに発生しました。
数日後、Blogサイトに設置してある Google Analytics経由で以下の様な通知メールが来ました。
サイトにログインしてみると、確かに18日と19日に普段の5倍近いのアクセスが来ているようです。
Office 365の障害に関しての情報を有用だと感じている方も多いようですので、既にソーシャルで色々な意見も出ていましたが、今回は私のOffice 365サービスの品質に関して感じていることを項目毎にいくつか書いてみたいと思います。
なお、なるべくエビデンスを示しつつ書こうと思ったのですが、古い記事などで見当たらなくなった物も多く、私の記憶を頼りに書いている部分も多いです。誤っている項目に関しては直ちに修正させて頂きますのでご指摘頂けると幸いです。
私自身、クラウド事業者で似たようなHostedクラウド（Exchange Server、SharePoint Server、Skype for Business Server）の開発運用に携わっていますが、ここはどうしても敵わないと思っていることがいくつかあります。
まず、基本的に全て自分で作っていること。ベースのクラウドも、そこで動くOSも、その上で動かすアプリケーションも自分たちで作って管理しているというのは有事の時の対応速度や、品質向上の観点からすると天と地ほどの差があります。
以前は、Office 365も月に1度だったり主立った物は 3ヶ月に1度の更新頻度でしたので、バグが見つかってもその次の更新のタイミングに合わせないと…などが有りましたが、今は全体に影響の出るような物は随時修正、更新されています。
また、「誤っていたら直す」「より正しい物が出てきたらそれに変更する努力をいとわない」という体質も凄いと感じてます。
具体的に言うと、例えば私の記憶では Exchange Online は最初リリース時はシンガポールDCがメインのデータセンタで、香港DCはバックアップセンタとして位置づけられていたと思います。
サービスイン当初は、シンガポールDCが
だったのに対して、香港DCは
のCIDRだけ利用していました。開始半年くらいして、影響がないと想定していたネットワーク作業でサービス影響がでました。こちら、恐らくプライマリDCからバックアップDCへの切り替えの試験を裏でしていたと思うのですが、主にDNS回りなどで想定外の事象になったようです。
その後、Exchange Onlineはシンガポールと香港を 50:50 で両 Active として利用するようになり、障害やメンテナンスに起因したデータセンタの切り替わりもシームレスに行われるようになりました。（オンプレミスの Exchange Server も同様の設計にすることがベストプラクティスになりました。）
また、同じく初期の方の障害の中でデータセンタ内部での大規模なネットワーク障害がありました。細かいメカニズムは説明されませんでしたが、L2ドメインの制御に起因する障害のようで、その後の構成変更でL2ドメインを極小化する施策をとりました。
既に何百万ユーザーもいた中で、この規模の根幹からのアーキテクチャ変更を基本的にダウンタイム無しで行うことができたというのは本当に凄いことだと思います。
日本企業で同じ事をやろうとすると、そもそも社内でも止められるケースが多いでしょうし、いざやろうとメンテナンス通知を出したとしても、お客様から「今の状態に満足しているからそんなリスクのあることして変更しないでくれ」という強い要求が来て押し切られてしまう、仕方なく「このサービスは何とかこの構成で乗り切って、次期サービスは新しいアーキテクチャでやろう」となるケースが多いのではないかと。
Microsoftも、BPOS → Office 365と3年周期で来たところでしたので、また3年で新しいブランドを作ってそちらで実現するという選択肢もあったかと思うのですが、「Office 365」というブランドで今後もずっと継続して行きたい、継続的に改善・改良を繰り返して行きたいという強い意志を感じました。
最後に、SLA がきちんとしていること。これは、単なる努力目標＆返金規定として機能しているのではなく、ユーザーとの間で現実的に達成可能な数値として定められている点です。
こちら、特に Microsoft Azure の SLA の方が顕著ですが、おそらく「何でこの稼働率を保証できるのか」と聞かれた場合に、 Microsoft はかなり明確にそれを如何に達成できるのかというのを論理的に説明ができるのだと思います。この為、達成できなかった場合の返金率は日本の企業の物に比べると高いです。
| 月間稼働率 | サービスクレジット（返金率） |
| 99.9%未満 | 25％ |
| 99%未満 | 50% |
| 95%未満 | 100% |
ちなみに、今回は Exchange Online の方はきっと99%未満になると思うのですが、結構な財務インパクトですね。これだと本気で品質改善しようと思うでしょうね。
余談ですが、日本のホスティング事業者は例えお客様と合意したSLAの範囲内の故障でも、画一的に決められた影響数と影響時間に基づき、障害発生時に総務省報告の義務があります。大規模障害時はお客様対応も勿論非常に大変なのですが、この監督官庁対応も非常に大変な稼働の発生するお仕事です。
なので、正直どうせ完璧を目指す再発防止策を出し続けないといけないなら、 SLAを非常に高い数字にしてしまって、万一の場合は返金すれば…と思って、例えば稼働率 100%の SLA を定めるというのも少し仕方ないかなという気もします。
ただ、ソフトウェアを使っているので、勿論想定外のバグは発生する物であり、その想定発生率が0%、例え発生したとしても100%冗長化の切り替えが成功するという前提はちょっと苦しいですよね。
色々と問題が発生する度に徐々に良くなってきているので、正直あまり残っていないのですが、少しだけ書きます。
まず、障害の認識のトリガーがですが、自社で設定したモニタリングで引っかからず、複数ユーザーからの障害申告をもって障害検知しているケースがまだ結構あると感じています。
申告に関しても「複数のユーザーからの」という条件が未だにあるらしく、今回の Exchange Online の障害に関しても、結果として発生から検知・アナウンスまで結構な（個人的な感覚で1時間以上）タイムラグがあったのではないかと思っています。
正直、その辺のデータは一杯取っているのでしょうから、地域毎のコールセンターのコール数、サポートリクエストの起票数、Web（BingやGoogle）の検索数、Twitterなどのソーシャルの発言のトレンドから「何か起こっているかも」の兆候も見いだすことができるでしょうし、RPAなどを活用して、より広い範囲で End-to-End のクライアント接続試験なども行う事ができるのはないかと期待しています。
また、メンテナンスや構成変更などの実行時間についてですが、以前は告知はしないものの、タイムゾーン毎に毎週金曜日の夜間帯がメンテナンスウィンドウとして定められていて、その時間に更新していたような記憶があります。
よくサポートリクエストの調査結果から、クラウド側のバグであることが分かったケースも、修正プログラムは完成したが、全世界に適用するまでに2-3週間かかると言われるケースなどもあり、そういった決まった短い時間だけだと対応が難しいのかも知れませんが、何か有った場合の検知やその切り戻しを迅速にする意味からもクラウド内への適用はもう少し安全かつ迅速にできる仕組みにしていって欲しいですね。
今回の障害発生時に、自分でやった動作の振り返りです。
今回は、Teamsの障害の方は [サービスの正常性] ごと落ちるという凄い展開でしたが、Twitterでの情報収集は総じて有用でした。
定期的に国毎で検索してトレンド見ていくと、結構エンドユーザー観点でも有用なデータがプロアクティブに取れるかも知れませんね。
そのうちチャレンジしてみたいと思います。
以前紹介した Yubikey の多要素認証には、Yubico AuthenticatorでのOTPの表示が必要だったため、ソフトウェアのインストールが制限されている環境（特にサーバ環境や Thin Client環境など）など利用ができないケースが有ります。
今回は、OTPの表示機能を備えた一般的なハードウェアトークンで、Azure ADに対応しているToken2のデバイスを利用した多要素認証について紹介します。
Token2のプロダクト群の特徴は、従来型のハードウェアトークン(Classic Token)に加えて書き換え可能トークン(Programmable Token)が有るという点です。また、形状もよく見かけるようなキーホルダー型の物とカード型の物が有ります。 価格も1個あたり €10 ～ €20 程度と比較的リーズナブルです。
YubiKeyでの運用で気を付けなければならないのは、キー自体を忘れたときの管理です。代替の方式として個人のスマートフォンでの電話やMicrosoft Authenticatorや固定電話などが設定できる環境であればそれで代替してもいいですが、今回はセキュリティの強度が高いとして推奨されている予備のYubiKeyを用意する方法について、どう利用するかの例を紹介します。
もちろん、各個人に2個ずつ YubiKey を配布し、一つは会社の机の中に入れておくなども可能かと思いますが、5000円程度するデバイスなので数がまとまると結構な「合鍵」代となってしまい、二の足を踏んでいるところをよく見かけます。
ただ、ここで合鍵代をケチったばかりに職場へのスマートフォン端末持ち込みを許可させたりというのも本末転倒ですよね。
以前の投稿で紹介したように、Yubikey (+ yubico Authenticator)による登録は各ユーザーがセルフサービスで実施することができて、気軽に利用できます。
しかしながら、この手順は一般ユーザーにとっては若干複雑です。また、いくつか問題が発生する可能性のあるポイントもあります。例えば、以下の様な物です。
Continue readingこの blog は Office 365 Advent Calendar 2018 に参加しています。
Office 365の管理者アカウントの利用に多要素認証を検討されている（もしくは既に実装済み）というユーザーは多いかと思います。
現状、Microsoftでは利便性を重視してスマートフォンでのアプリケーション Microsoft Authenticator を利用したアプリ通知による認証を推していますが、環境によっては利用が難しいケースがあります。
Continue reading11/23に開催された第23回Office 365 勉強会に登壇しました。
今回のテーマは「O365勉強会的、AzureAD勉強会」。主催者メンバーの中での企画段階では、色々とBlogでお世話になっていて、今年Microsoft MVPになった @Miya_Microsoft さんにOffice 365勉強会に来て貰いたいというのが最初で、以前そういえば国井さんの事をインスパイアしてたなぁ…と思い、2人セットでブッキングできそうなテーマとして選びました。（毎回ではないですが、結構ユルい感じでテーマ決めとかしてます）
当日の様子はこちら : 第23回 Office 365 勉強会 #o365jp まとめ
私のセッションでは、「Azure ADのテナント設計」ということで、Office 365管理者としてはおそらく意識せずに使っているAzure ADのテナントについて、今後AzureやD365などの他のサービスが利用するようになってきた場合にも、どうしていったら良いかきちんと考えられるよう、注意事項や指針などについて話をさせて頂きました。
アンケートなどでも良い反応を頂けたようですので、またこのBlogなどでもこの辺の話題について詳細やアップデートなど発信していければと思っています。
いつもお世話になっている北端さん、太田さんと共著させて頂いた書籍「Office 365管理者のための逆引きPowerShellハンドブック」が11/15に発売されることになりました。
コマンドの説明であればオンラインヘルプや Technet を見れば十分に事足りると思い、サンプルスクリプトなどもなるべく実務よりで Tips が多くなるように書きました。
書き切れなかったことや補足、訂正したいことなども今後色々出てくると思うので、内容については今後この Blog 内でフォローしていきたいと思っていますので、こちらも参照いただければと思います。
11/5-7 の Tech Summit 2018で先行販売されるとのことですので、イベントに参加される方はよろしければ手に取ってみて下さい。
年度明け最初の週末に向けた2018/4/6(金)の夕方、比較的広い範囲のOffice 365の一部テナントでログインに関連する障害が発生しました。
幸か不幸か、私の個人用のテナントや会社で使っているテナントは影響を受けていなかったのですが、色々と気づくことも有ったのでメモ代わりに記しておきたいと思います。