当社はIT技術のオンライン教育を得意としたセミナー専門会社です。

ITエンジニアの技術力UPをお約束します。

Microsoft Teamsの認証後のエラー対処「HTTP 400 エラー」「400 Bad Request Error」

Microsoft Teamsの認証後のエラー対処「HTTP 400 エラー」「400 Bad Request Error」


Teamsを使うシュチエーション

先日、普段使うことの無いMicrosoft Teamsを使用する事があり、認証が通るがその後のコールバック処理でTeamsのダッシュボードに遷移せずに「HTTP 400 エラー」や 400 Bad Request Errorが出て全然使えない問題が生じた。ことの発端は、常に会議の1時間前にオンライン会議のログインテスト(映像、スピーカー、マイク)を行う儀式を必ずするのだが、顧客から送られてきたリンク接続先がまさかのMicrosoft Teamsのリンクだった。いつもならZOOMなんだけどね。まさかのログイン認証後にエラーが生じる問題が発生しそこからが問題解決にたどり着くまで一苦労だった。結果的には3時間で解決したがこんな問題もあるんだなーと。認証方法を変えたらログインできたので同じような方がいましたら参考に。

問題となるエラー

勝手にTeamsが昨年秋ごろにPCへインストールされたんだけど、使わないのでアンインストールしていた。今回は会議があるので再度インストールしないといけない。インストール自体は簡単なのですぐ終わるのだが、仕事柄、複数のアカウント(お客さんの代行作業)を持っているのが仇となり問題につながった。インストールしたTeamsは勝手にお客さんのアカウントでログイン状態になっていた。それはまずいのでサインアウトして自分の会社のマイクロソフトアカウントを使ってログインするのだが、何故かMicrosoft Authenticate認証は成功するのに、その後のコールバック転送でTeamsにダッシュボード画面を表示させる段階で「HTTP 400 エラー」「400 Bad Request Error」になってしまう。

問題解決作業の挫折

パスワード変更を試みたり、パソコンを再起動をしたりしたが全く問題は解決せず、マイクロソフトのフォーラムなどで似たような現象をもった人たちがいたようだが大部分は解決できていないようだ。

結局、実際のオンライン会議はWEBブラウザー経由でどうにかなったが、Teamsってブラウザ経由だとイマイチなんだよね。カクカク動画が動くし、音飛びもよくするし。

再度エラー調査にトライ、そしてダッシュボード表示に成功

終わったあとに再度考え直してみました。認証は通っているがダッシュボードに移行しないのはユーザアカウント&端末でプロファイルはTeamsのセンター側で保持されているのだが、何らかのバグで認証の成功ステータスをプロファイルのDBに書き換えできていないのだろう。ならば、認証の救済で別の認証方法が他に3種類ほど選択できるのでそれを試すとしよう。もしかするとプロファイルの書き込み項目が変われば通る可能性はあるかもね!

この予測は多かれ少なかれあたってたんじゃないかな。結果は大成功でした。最初はMicrosoft Authenticaterがスマホに表示する3つの数字とTeamsの認証(MFA)で生成される数字の一致を確認しスマホ側の一致する数字のボタンをタップする方法は認証は成功してもTeamsへコールバックでエラーが生じていました。しかし今度はSMSで登録したスマホへワンタイムパスワードを送る方式に変えたところ転送が一瞬うまく行ってダッシュボードが表示されたタイミングでTeamsが落ちてしまった。でもここまで来たなら恐らく次の起動でうまくダッシュボードにいけるだろうと再度Teamsを起動したらようやくダッシュボードにたどり着きました。やっと成功です。

※下記は画面遷移(認証後のコールバック)で失敗した時の認証方式です。認証自体はもちろん成功しています。

※下記は画面遷移(認証後のコールバック)で成功した時の認証方式です。

問題のトリガーはなんだったのか?

以上似たような現象が発生した方は、参考にされたし。

  • Teams導入時に勝手にログインされたお客さんのアカウントはOffice 365のアカウントです。(正常にログインできてる。別のアカウントでエラー出た後も、再度お客様アカウントは問題なくログインできる)
  • 私の会社のMS アカウントは一般ユーザ登録のアカウントです。
  • 認証は普段からよく頻繁に使うMFA認証(Microsoft Authenticater)で認証は成功するがダッシュボードで失敗(HTTP 400 Error)する。
  • 認証成功して恐らくプロファイルDBの書き換えで失敗している。PC側のプロファイル、それともセンター側のプロファイル!?(きっとバグだと思う。)

タグ: , , , ,

Google Search Consoleの404エラーに潜む謎とセキュリティアタックの実態


Google Search Consoleの404エラーはSEO上重要なファクターです。Googleは404エラーは評価無視扱いとされ、色々な説がネットで流れていますが結果論から言ってしまうとエラーの割合が多いと順位が確実に下がります。つまり直接理由ではなくて間接的な要因から順位が下がってしまいます。ここには隠された謎があります。というのは通常404エラーは検索結果のリンク表示をクリックしたときに「ファイルがありません」というものを表すのですが、実はそれだけでは無いのです。ここをじっくり見ると攻撃の跡が見られます。つまり、隠されたページやバグを見つけようとして、あの手この手で存在していないURLを作り出してアクセスしてきていることがわかります。GSの管理画面でクロール>クロールエラー>URLエラーの項目を是非チェックして見てください。おかしいなと思うURLがあるはずです。ほぼそれが攻撃の形跡だと思います。

404エラーは一見すると無害のように思えて、有害の場合もある。

先に述べたように有りもしないページは勝手にアタックさせておけばと考えるのですが、意外と短い時間で連続アクセスされるとサイトによっては重くなる要因です。ページが重くなったら機会損失ですし、今は表示速度は評価の一つです。その他404エラーは間接的に色々なファクターを持っており、Googleがインデックスを刷新するタイミングを作る意味もあります。いい意味でコンテンツの切り替えがあって404エラーになってしまう場合もあります。これは健全な404エラーで全く問題ないのですが、ここにさらにページの生存期間が加わってくるとややこしいことに。

1ヶ月程度でネタが更新されてゆくサイトはページのURLが変わってしまうと損。

ページがきちんとGoogleに認識するまでの期間は意外と時間がかかります。私の感覚では更新ページが少なければ1日、2日で認識されるのもありますがページ数が多いと2週間から1ヶ月弱までかかる場合も多い。それで1ヶ月程度でネタが更新されてゆくともうお分かりでしょうが認識されず生涯を終えるページもあるわけです。

評価してもらうにはできるだけ長くインデックスにエージングしてもらう構造が必要。

つまり新しい記事ネタでもページURLは変わらずページBODYのみ定期的にダイナミックに変わるものが最も有利な構造と言えます。最初からデータベースでBODYコンテンツをダイナミックに作ればよいのでしょうが、図体のでかいサイトは簡単に変更できません。今はスクレイピングの技術やJavascriptの技術があるから置換したり局所的にはめ込みを更新するのは簡単なことです。私は実験で自分自身が持っている幾つかのサイトを完全ファイル構造を変えて刷新することをやってみましたがやはり全てのGoogle検索サーバが完全同期するまでには半年以上かかりました。その間は何度もGoogle Search Consoleの中で重複や404エラーの先祖返り評価を表示されることがあり、改めてGoogleの検索サーバの同期はものすごい時間がかかるので、ディレクトリ構造やファイル名をあんちょこにコロコロ変えるのは得策ではないとわかりました。

404エラーはゼロになる必要はないが、定期的にエラーをチェックしエラーの原因を掴みましょう

エラーはサイトの健康のバロメータであることはわかったかと思います。エラーが少ないにこしたことはありません。多いということはそれだけ無駄が潜んでいたり、セキュリティアタックを受けてたりと色々なことがわかります。セキュリティアタックなら攻撃パターンが分かれば対処は難しくありません。意外なところで便利な404エラーですね!皆さんも要チェック!

タグ: , , , , ,