登録キャンペーンでログイン不可にならない為に

登録キャンペーンによる先進的で強力な認証の推進 | Japan Azure Identity Support Blog (jpazureid.github.io) でも案内されていますが、Entra ID の登録キャンペーン(より強力な多要素認証として Microsoft Authenticator のインストールをユーザーに依頼する管理者機能)が既定で有効化されはじめてます。

従来より、SMSや電話番号での認証は相対的にセキュリティレベルが低く、Microsoft からは非推奨になっていましたのでこの機能自体は良い物だと考えているのですが、環境によっては注意が必要なケースがありますので紹介します。

そもそもこの機能は 2 年近く前から存在していて、管理者により有効化することができたのですが、今回の変更によって「①既定で有効化される」「②ユーザー判断でスキップできる回数に上限が設定される」ことになりました。

有効になった状態でログインし、電話での多要素認証を実施すると、以下の様な画面になります。[次へ] を押すと Microsoft Authenticator の設定画面に推移し、[今はしない] を押すと通常のログイン後の画面に推移します。

ポイントとしては、[今はしない] というのは3回しか押すことができないということです。

特に注意が必要なのは、以下の様なシナリオです。

  • 組織に存在している管理者アカウントが 1 つしか存在しない
  • 利用環境や社内の規程上 Microsoft Authenticator を利用できない(スマートフォン持ち込み不可の場所でしか利用できないなど)
  • たまにしか使っていない

これらに該当する場合は、3回スキップする前に以下の画面で Microsoft Authenticator が利用できない環境のユーザー(今回の例だと、唯一の管理者アカウント)を登録キャンペーンから除外するという設定を入れてください。
※対象が不特定多数の場合は、状態を [Microsoftマネージド] から [無効] にして組織全体で無効化することも可能です

Azure管理ポータル
[Azure Active Directory] – [セキュリティ] – [認証方法] – [登録キャンペーン]

ただ、前述の通り SMS や電話での多要素認証はセキュリティレベルが低く、既に非推奨となっております。Microsoft Authenticator が利用できない環境でも安全に多要素認証が利用できる OTP デバイスや FIDO2 セキュリティキーなどが手頃な価格で市場でも出そろってきておりますので、これを機にご検討いただくことも良いのでは無いかと思います。

また、不幸にも既に 3 回スキップしてしまった場合は、内部調整の上、特例で一度だけMicrosoft Authenticator を登録して貰ってログイン後、上記で登録キャンペーンの無効化とMFA情報から削除を実施するか、あるいは Microsoft サポートに連絡して対処を依頼して下さい。(本人確認などで時間はかかると思いますが)

3回スキップすると、次回から以下の画面から [次へ] を押して Microsoft Authenticator をインストールしないと先に進めなくなります。

Teamsのデータセンタを日本に変更する

2023/2/8 の早朝 5:25 に、シンガポールの Azure データセンタの 1 つで発生した電源障害に起因し、Teams で広域障害が発生しました。(本記事の記載時点で PIR 待ちの状態です) 私が個人で契約しているテナントでも Meeting / 通知などの機能に影響が発生しておりました。

ここで、一つ疑問が生じました。あれ、そういえば日本にデータセンタができたときに、東南アジアに残るか日本リージョンに移るかで日本リージョンに移るという選択を当時したのではなかったっけ…調べてみました。

どうやら、Teams の基本的な処理を行うサーバは APAC エリアに配置されていたが、2018/8/27 に日本リージョンにもできた。それ以降に開通した顧客は日本にTeamsも配置される。ご多分に漏れず私のテナントもそうなってました。
Microsoft Teams のデータ所在地に日本とオーストラリアを追加 – Windows Blog for Japan

私のテナントのデータ保存場所

また、Teamsはバックグラウンドでチャットやファイルなど、多くのデータが SharePoint Online や OneDrive for Business、Exchange Online に配置されておりますが、こちらは認識通り日本に配置されてます。

現状の構成ですと、日本あるいは APAC で何かしらの広域障害が発生した場合、どちらの障害でも Teams としては影響を受ける形になりますので、この機会に全部日本に持ってきて、巻き込まれる可能性を減らそうと思います。

リクエストは Microsoft 365 管理センターから行います。移行リクエストができるテナントの場合、[設定] – [組織設定] – [組織のプロファイル] に [データ所在地] という項目が表示されており、ここからリクエストを行うことができます。

Microsoft 365管理センター – 組織の設定 – 組織のプロファイル

これでリクエストは完了です。あとは完了まで待つだけですね。

CSP事業者の代理管理の実装例(Tips)

前回までの記事(CSP事業者の代理管理を読み解く①CSP事業者の代理管理を読み解く②)ではCSP事業者の持つ代理管理権限について紹介させて頂きました。とても強い権限ですので、きちんとCSP事業者側としてもしっかり管理していくべき事項であることがご理解頂けたかと思います。

事業者側、ならびにユーザー側から守るべきポリシーなどは、公式から クラウド ソリューション プロバイダーのセキュリティに関するベスト プラクティス – Partner Center | Microsoft Docs 上げられていますので、俯瞰的な情報はそちらを参照して頂くとして、この記事では、より具体的にこの機能をこう使うと便利に実装できるよということをいくつか紹介していきたいと思います。

Continue reading

CSP事業者の代理管理を読み解く②

前回の記事では、CSP事業者の2種類の代理管理権限であるDAPとAOBOについて紹介しましたが、今回は、それらに関してもう少し具体的な実装方式について書いていきたいと思います。

前回も一部紹介しましたが、これらの代理権限はCSPパートナーのAzure ADテナントと顧客のAzure ADテナントの間で今の図のようなイメージで構成されます。

概念図(パートナー・顧客間)
Continue reading

CSP事業者の代理管理を読み解く①

Cloud Solution Partner(CSP)を経由してMicrosoftのクラウドサービスを利用する場合、料金請求の他にサポートに関してもCSP事業者から提供するために代理管理権限がCSP事業者に対して付与されます。

この権限に関しては、通常は最初のライセンス購入をする前の付与される形になりますが、あまり意識せず付与して、その後も運用されているケースも多いかと思うので、ここではその詳細について実装から読み解いていきたいと思います。

Continue reading

Microsoft認定資格を失効させてみた

この記事は Microsoft Learn Advent Calendar 2021 にエントリーしています。

Microsoft認定資格の期限

現在、ロールベースと呼ばれる新しいMicrosoft認定資格(初級レベルの物は除く)に関しては、取得から1年という有効期限が定められています。

最初に発表された時は、Azureは2年、Microsoft365系は3年と言われていましたが、2021年4月に、オンラインで無料受験できる更新アセスメントの発表とともに2021年6月30日以降に取得した資格は有効期間が1年と改定されました。

今回、2019年4月に取得し有効期間が2021年10月(更新試験公開までの期間として+半年延長された)の資格があったので、失効させてどうなるかを確かめてみました。

Continue reading

Office 365勉強会 #34に登壇しました

2021/11/13(土) に開催された第34回 Office 365勉強会「Office 365 勉強会サポートとのうまい付き合い方」に登壇させて頂きました。

以前、社内でサポート関連の勉強会をしたという話をTwitterでしたのですが、その話を聞いていた目代さんがテーマ設定をして決定しました。

Continue reading

例外処理 [タスクが取り消されました。]

クラウドサービスに対して PowerShell で何かしらの処理を大量に実行しようとすると、ネットワークや一時的な高負荷、スロットリングなど、何かしらの要因で一定の割合で失敗することがあります。

このため PowerShell で処理を行う場合においては例外処理をきちんと書いておくことが重要です。

例えば、CSP顧客のAzureサブスクリプションの使用量を取得する Get-PartnerCustomerSubscriptionMeterUsage を実行すると、以下の様な [タスクが取り消されました。] というエラーが返ることがあります。

Continue reading

CSPのAzure明細をPowerShellで整形する

新年度になりましたね。私も業務の所掌範囲とか変わって色々と新しいことに取り組み始めようと思います。

早速、MicrosoftのCSP事業者向けに毎月発行される請求書の明細のCSVファイルをExcelで加工するということを業務マニュアル見ながらしたのですが、面倒くさい上にピボットで集計したところ何かおかしい。

主に以下の点がおかしいという結論に。

  1. 調整ファイルのCSVの中に2種類の情報が入っていて、途中でカラムが変わる
  2. 調整ファイルの合計額が請求書の額と微妙に一致しない

前者に関しては単に分割すれば良いだけですが、後者に関しては過去の請求書も含めて調べた結果、以下のロジックであることが分かりました。

  • 税抜利用額において、小数点以下が存在するレコードが有るが、実際それは利用されない。
  • 2019年の秋くらいまでは多くの小数点以下の値があったが、以降は1円未満の利用(つまり0円請求)の場合にのみ小数点以下が存在
  • 税抜利用額の各項目に対して消費税が計算され、それが切り捨て
  • 切り捨てされた税抜合計額+消費税合計額がCSP事業者への請求

明細書のCSVが請求書と合わないのは問題なので、補正した値を経理処理上作成しないといけないのですが、数十万レコードとか有るとExcelでやるのも一苦労なので、PowerShellでやっちゃうことにしました。

PowerShellのImportExcelモジュールを使うと、PowerShellからxlsxファイルをそのまま作れます。アウトプットが複数シート必要なExcelなので今回はこれを利用します。

自分用のスクリプトなので汚いですが…。

$inputcsv = ".\AzureBillingUsage.csv"
$outxlsx = ".\CSPAzureBill.xlsx"
$tempfile = $env:TMP + "\_" + (Get-Date -Format yyyyMMddHHmmss) + ".csv"

### CSP請求書を上部のSummaryと下部のDaily Usageの2つのCSVに分ける ###
$bills = Get-Content $inputcsv -Encoding UTF8
$lines = $bills.Count

# Daily Usageの前の行まで出力
for ($i=1;$i -lt $lines;$i++){
    if($bills[$i] -eq "Daily Usage"){
        break
    }
    if($bills[$i] -ne ""){
        $bills[$i] | Out-File $tempfile -append
    }
}
$usages = Import-csv $tempfile
Remove-Item $tempfile

# Daily Usageの次の行から出力
for ($i++;$i -lt $lines;$i++){
    if($bills[$i] -ne ""){
        $bills[$i] | Out-File $tempfile -append
    }
}

### [Summary]シートの作成 ###
# PretaxChargesに小数点以下が存在するが、請求書上は切り捨てた額の総額で計算されているので、
# それを考慮したPreTax、PostTaxを計算
foreach ($usage in $usages){
    $pre  = [Math]::Truncate($usage.PretaxCharges)
    $post = $pre + $usage.TaxAmount
    $usage | Add-Member PreTax  $pre -force
    $usage | Add-Member PostTax $post -force
}

$usages | Export-Excel -Path $outxlsx -WorksheetName Summary

### [Daily_Usage]シートの作成 ###
# Subscription ID毎にマージして、PostTaxとPreTaxの値を合計する
Import-csv $tempfile | Export-Excel -Path $outxlsx -WorksheetName Daily_Usage
$subs = $usages | group "SubscriptionId" | select `
  @{Name="DomainName";Expression={($_.group | select -first 1).DomainName}}, `
  @{Name="CustomerCompanyName";Expression={($_.group | select -first 1).CustomerCompanyName}}, `
  @{Name="CustomerId";Expression={($_.group | select -first 1).CustomerId}}, `
  @{Name="SubscriptionId";Expression={($_.group | select -first 1).SubscriptionId}}, `
  @{Name="TotalPostTax";Expression={($_.group | Measure-Object -sum "PostTax").sum}}, `
  @{Name="TotalPreTax";Expression={($_.group | Measure-Object -sum "PreTax").sum}} `

# 新規開通分に関して DomainName が空欄なケースがあり、その場合の対応。
# (事前に Install-Module -Name PartnerCenter -AllowClobber が必要)
if((($subs | ? {$_.DomainName -eq ""}) | measure).count -gt 0){
	Connect-PartnerCenter
	foreach ($sub in $subs){
		if($sub.DomainName -eq ""){
			$sub.DomainName = (Get-PartnerCustomer -CustomerId $sub.CustomerId).Domain
		}
	}
}

### [Subscriptions]シートの作成 ###
$subs | sort DomainName | Export-Excel -Path $outxlsx -WorksheetName Subscriptions -AutoSize -Show

### テンポラリファイル削除 ###
Remove-Item $tempfile
2020/05/07修正(2020年04月利用分の明細ファイルに対応)
・既定のファイル名を変更
・細かいフォーマット変更に対応
・文字コード変更

最初はPivotで作ろうかと思ったのですが、[小計の非表示]や[表として表示]が上手くいかなかったので、そのままPowerShellで整形させちゃいました。

PowerShellを利用してレポート用のCSVを作ってExcelで整形という業務って結構あるかと思いますが、Import-Excelモジュールを使うとその部分までコードで書けるようになるのでとても便利です。

皆さんも是非試してみて下さい。

Office 365 の障害と信頼性

この記事は 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が

  • 207.46.4.128/25
  • 207.46.58.128/25
  • 207.46.198.0/25
  • 207.46.203.128/26

だったのに対して、香港DCは

  • 111.221.69.128/25

のCIDRだけ利用していました。開始半年くらいして、影響がないと想定していたネットワーク作業でサービス影響がでました。こちら、恐らくプライマリDCからバックアップDCへの切り替えの試験を裏でしていたと思うのですが、主にDNS回りなどで想定外の事象になったようです。

その後、Exchange Onlineはシンガポールと香港を 50:50 で両 Active として利用するようになり、障害やメンテナンスに起因したデータセンタの切り替わりもシームレスに行われるようになりました。(オンプレミスの Exchange Server も同様の設計にすることがベストプラクティスになりました。)

また、同じく初期の方の障害の中でデータセンタ内部での大規模なネットワーク障害がありました。細かいメカニズムは説明されませんでしたが、L2ドメインの制御に起因する障害のようで、その後の構成変更でL2ドメインを極小化する施策をとりました。

[すごいネットワーク]DC内は「小型インターネット」

既に何百万ユーザーもいた中で、この規模の根幹からのアーキテクチャ変更を基本的にダウンタイム無しで行うことができたというのは本当に凄いことだと思います。

日本企業で同じ事をやろうとすると、そもそも社内でも止められるケースが多いでしょうし、いざやろうとメンテナンス通知を出したとしても、お客様から「今の状態に満足しているからそんなリスクのあることして変更しないでくれ」という強い要求が来て押し切られてしまう、仕方なく「このサービスは何とかこの構成で乗り切って、次期サービスは新しいアーキテクチャでやろう」となるケースが多いのではないかと。

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週間かかると言われるケースなどもあり、そういった決まった短い時間だけだと対応が難しいのかも知れませんが、何か有った場合の検知やその切り戻しを迅速にする意味からもクラウド内への適用はもう少し安全かつ迅速にできる仕組みにしていって欲しいですね。

「障害かな」と思ったら自分でやっていること

今回の障害発生時に、自分でやった動作の振り返りです。

  1. 検証環境、もしくは別PCや別ブラウザから再現試験を実施してみて「影響範囲」「発生条件」「再現性の有無」を確認する
  2. サポートリクエストを上げる準備をする
  3. Twitterで似たような症状のつぶやきが無いか検索する(例: 「Office365」「メール」「遅延」)
  4. 自分でもつぶやく
  5. FacebookのOffice365コミュニティを見る
  6. 正常性ダッシュボード([サービスの正常性])を見る
  7. サポートリクエストを上げる

今回は、Teamsの障害の方は [サービスの正常性] ごと落ちるという凄い展開でしたが、Twitterでの情報収集は総じて有用でした。

定期的に国毎で検索してトレンド見ていくと、結構エンドユーザー観点でも有用なデータがプロアクティブに取れるかも知れませんね。

そのうちチャレンジしてみたいと思います。