皆さんこんにちは。国井です。

昨年、ご質問いただいていた内容ですっかりお答えが滞っていたものがありました。
2016年最初の(技術的な)投稿は、ADFSサーバーの多要素認証に関するご質問をいただいておりましたので、そちらに回答していこうと思います。

前提

ADFSサーバーによる多要素認証について知りたい方は
ADFS+Office365でブラウザーアクセスのみ多要素認証を設定 にて
過去に紹介しておりますので、こちらをご覧ください。

Q1. 証明書利用者信頼ごとに多要素認証を設定したい

この質問の意図は、Office365のシングルサインオンのときには多要素認証を設定したいけど、ADFSサーバーのデバイス登録時には多要素認証を使いたくない、というところです。

答えは簡単です。
ADFS管理ツールの[認証ポリシー]-[証明書利用者信頼ごと]を開けば、
証明書利用者信頼別に多要素認証の設定ができます。

Q2. Office365にブラウザーからアクセスする場合のみ多要素認証を設定したい

前提のところで紹介した投稿でも書きましたが、ADFSサーバーの多要素認証は
要求規則言語を使って詳細な条件設定ができます。
しかし、条件を自分で指定するためには、「Office365にブラウザーからアクセスする場合、どのようなアクセスになるのか？」という特徴を知らなければなりません。以前の投稿では

社内ネットワークからブラウザーを使ってアクセス：/adfs/ls/wia

インターネットからブラウザーを使ってアクセス：/adfs/ls/

というURLを取るので、このことを理解したうえで条件を書けばよいとお話ししました。
では、iOSのSafariからアクセスした場合などはどうなるでしょうか？
結論から言うと、ブラウザーアクセスである限り、
OS種類を問わず、/adfs/ls/または/adfs/ls/wiaになります。
(ただし、iOSやAndroidだと社内ネットワークからのアクセスでも
Windows統合認証にはならないので、/adfs/ls/wiaは使わないと思います。)

そのことを事前に調べたいというときはADFSの監査ログを使って調べるという方法があります。実際にiOSのSafariからOutlook on the Webのサイトにアクセスしたときのログがこちら。

x-ms-endpoint-absolute-pathの欄を見ると、/adfs/ls/になっていることがわかります。補足ですが、OWA for iPhoneからのアクセスも結果的にはブラウザーアクセスですから
x-ms-endpoint-absolute-pathは/adfs/ls/になります。

ADFSの監査ログについてはMVP渡辺さんのブログが役立ちますので、
そちらを参考にしていただければと思いますし、
ログの見かたやアクセス制御に必要な情報収集の仕方、トラブルシューティングなどについてはトレーニングの中でも扱っておりますので、ご興味がありましたらぜひ。

今日はここまでにしましょう。
次回の投稿をお楽しみに。

皆さんこんにちは。国井です。

クリエ・イルミネートさんとの協業で提供している「Office 365認証ベストプラクティス」コースですが、現在発表されているスケジュールはすべて満席になっており、ご迷惑をおかけしておりました。

やっと、2016年4月からのスケジュールも発表させていただくことができるようになりました。
日程は以下のとおりです。

2016/04/13(水) ～ 2016/04/15(金)
2016/07/27(水) ～ 2016/07/29(金)
2016/10/19(水) ～ 2016/10/21(金)
2017/01/18(水) ～ 2017/01/20(金)

2016年4月以降のトレーニングでは、Office 365だけでなく、他のクラウドサービスとの連携方法や、以前より要望の多かったAzure仮想マシン上へのADFSサーバーの構築方法なども含めて3日間で提供することになりました。
提供するコース内容の詳細についてはクリエ・イルミネート社のニュースリリースでご案内しておりますので、合わせてご覧ください。
また、お申し込みも同じくクリエ・イルミネート社のサイトより行えます。

今後はトレーニングで様々な知識やノウハウをお伝えしていくことはもちろんですが、同時に個別のご相談にもお受けできる体制を整えていく予定でおりますので、どうぞご期待ください。

■　■　■

今年は、Office 365のシングルサインオン環境を構築し、運用されている会社さんにとって、そのメリットがさらに生かせるようになる、そんなステージに進んでいくのではないかと思っています。
2016年のID管理のゆくえをこのブログと共に一緒に見守っていきましょう！

皆さんこんにちは。国井です。

Azure AD (Office 365) との間でディレクトリ同期やシングルサインオンの設定を行うために使用する Azure AD Connect (AAD Connect) ですが、1回できれいにインストールできない場合があります。

例えば、こんな感じ。

本当だったら、エラー画面でも確認できるとおり、ログが生成されるので、ログを見ながらトラブルシューティングしていきます。

ですが、、

ここから先は私の完全な主観ですが、
一度、Azure AD Connectアンインストール→Azure AD Connect再インストール、という操作を行っていただくと、1回目のインストールと2回目のインストールは同じ操作なのに、2回目は成功するってことがよくあるんですよね。。
(ちなみに、[再試行]でインストールが成功したことは一度もないです。どういうときに役立つのかな？)

あと、特にAzure仮想マシン上で実行すると、この手のトラブルは多い気がします。

なので、もしAzure AD Connectでインストール失敗することがあったら、詳細なトラブルシューティングをするよりも、まずは再インストールを試してみたほうが手っ取り早いかもしれません。

実際、前述のエラー画面では、ログを見てみると

ADFSをインストールしようとしていて、ADFSサーバーのインストール後にできるはずのレジストリキーがないことが原因でAzure AD Connectが終了してしまっていたりするので、「それって単純にタイムアウトしてしまっただけ？」と思うのです。

そんなわけで、Azure AD Connectアンインストールしたのち、Azure AD Connect再インストールし、ウィザードを実行。

すると、2回目もエラーで終了。
ログを見ると、1回目と同じく、インストール後にできるはずのレジストリキーがないことが原因でAzure AD Connectが終了しています。しかし、1回目と異なるのはADFSサーバーのインストールが完了(フェデレーション構成は実行されていないけど)し、ログで指摘していたレジストリキーが後からできていたこと。
(ログで指摘していたレジストリ項目はHKLM\Software\Microsoft\ADFSでした。)

だったら、もう一度Azure AD Connectアンインストール→Azure AD Connect再インストールを実行してみたら、どうなるだろう？ということで、もう一度、Azure AD Connectアンインストールしたのち、Azure AD Connect再インストールし、ウィザードを実行。

すると、3度目にして、ついにAzure AD Connectによるディレクトリ同期ツールとADFSサーバーのインストールが完了しました。

こんな感じで、Azure AD Connectのインストールは、どういうわけか、複数回のインストールによって、インストールがうまくいくことが多いのです。(注：私の主観です)
そのため、Azure AD Connectによって、ADFSサーバーを含めたシングルサインオン環境の構築ができるようになりましたが、今まで通り、ADFSサーバーとWebアプリケーションプロキシを手動で登録する方法を使ったほうが適切なケースもあるように思います。

皆さんこんにちは。国井です。

Azure AD Connectを実行した際に起こるトラブルについて、前回投稿しましたが、
こんなトラブルもありましたよ、というのを備忘録として載せておきます。

Azure AD Connectでは、ディレクトリ同期ツールのインストールだけでなく、
ADFSサーバーやWebアプリケーションプロキシのインストールも同時に行うことができます。
その際、ウィザードの中でADFSサーバーの名前を指定しますが、なぜかサーバーへの接続ができないのです。

この場合、ADFSサーバーとなるコンピューターで

Enable-PSRemoting –Force

を実行してあげることで、Azure AD Connectでのサーバー登録ができるようになりました。

おわり

皆さんこんにちは。国井です。

Azure Active Directory Connect(AAD Connect)を使って、ディレクトリ同期を行う際、同期したくないユーザーやグループってあると思います。このことについては、以前にもOffice 365管理者のためのディレクトリ同期ツール入門(3)という投稿の中でも紹介させていただきましたが、その当時はDirSyncだったので、今回はAAD Connectを使って一部のユーザーを同期させない方法を紹介したいと思います。

■Synchronization Rules Editor

Synchronization Rules Editorとは文字通り、同期のルールを定義したもので、
ディレクトリ同期ツールで実行される、すべてのルールはこのツールで設定されたルールに基づいて行われます。そのため、このツールの中で、それぞれの環境に合わせたルール設定をすればよいのです。

■ルール設定

AAD Connectをインストールしたサーバーで、スタート画面からSynchronization Rules Editorを起動し、表示されるツールから[Add new rule]をクリックして、新しくルールを作成します。
(既存のルールを変更してはいけません。必ず新規にルールを作成して定義してください)

新しくルールを作成するウィザードで、
Connected SystemにはActive Directoryのドメイン名
Connected System Object Typeにはuser
Metaverse Object Typeにはperson
Link Typeにはjoin
Precedenceには50(100以下なら、最優先のルールになります)

と入力・設定します。
余談ですが、Connected SystemとはFIM/MIMのコネクタスペースに相当します。

続いて、Scoping Filterでは、同期させないユーザーの条件を入力します。
ここでは、
department – NOTEQUAL – 営業
としているので、部署が営業以外のユーザーはすべて同期しないという意味になります。

最後のTransformationでは、
Constant – cloudFiltered – True
と条件を入れています。cloudFiltered属性をTrueにセットすることで、
Azure AD に同期しないで！という設定になります。

以上で完了です。
ディレクトリ同期を今すぐ実行する方法 – AADSync版でも紹介した方法で、ディレクトリ同期を今すぐ実行すれば、一部のユーザーだけが同期することが確認できます。

皆さんこんにちは。国井です。

お客さんに教えていただいて、びっくりしたのですが、
先日よりAzure ADでディレクトリ同期を行う際、
Azure AD Connectのインストールによって、自動的にアクティブ化されるので、
自分でアクティブ化設定する必要がなくなったのですね。

今までですと、
Azure AD Connectのようなディレクトリ同期ツールを使って
ディレクトリ同期を実行する際、事前にAzure管理ポータルから
[アクティブ化]という設定を行う必要がありましたが、

Azure AD Connectをインストールすると、

ご覧のように、勝手にアクティブ化が設定されている！
前から、この設定、いちいち行うのが面倒だなと思っていただけにありがたいです。

直近では、Azure AD Connect自体、新しいバージョンが提供されて、だいぶ変わっているようなので、次回の投稿はAzure AD Connectを紹介したいと思います。

皆さんこんにちは。国井です。

ここのところ、EMS(Enterprise Mobility Suite)と呼ばれる、Azure ADやMicrosoft Intuneなどが含まれるサービス群の導入を検討されるお客様や導入提案を行おうとしている方々へのお手伝いをさせていただいており、ブログの更新も滞っておりました。

今日ご紹介するのはOffice 365のディレクトリ同期で導入されている会社さんも多いと思われる、dirsyncについてです。dirsyncと呼ばれるディレクトリ同期ツールは既に後継のバージョンであるAAD Connectがリリースされており、「dirsyncがサポートされなくなる」と言い出す日もそのうち来るのではないかと考えています。(MSさんだって営利企業なのだから当然の流れですよね)

そこで、今のうちから考えておきたいのがdirsyncからAAD Connectへのアップグレード。
アップグレードには、大きく分けて2つの方法があります。

・インプレースアップグレード
・サイドバイサイドアップグレード

執筆時点でリリースされているAAD Conectのバージョン1.1.110.0では、インプレースアップグレードをサポートしており、dirsyncがインストールされているサーバーにAAD Connectをインストールすると、自動的にアップグレードを開始します。

インプレースアップグレードの場合、以下の画面のような、「dirsyncで特定のOUのみ同期する」というような設定もそのまま引き継いでくれるので、とても便利です。

ただし、インプレースアップグレードで怖いのは万が一、インストールに失敗したとき。
dirsyncにも戻せないですし、少しリスクが高いと考える人もいるでしょう。

そのような場合には、サイドバイサイドアップグレードという方法があります。

サイドバイサイドアップグレードは、今あるdirsyncサーバーには手をつけずに、2台目のサーバーに新しくAAD Connectをインストールする方法です。この方法であれば、AAD Connectのインストールが確認できてから、dirsyncをアンインストールできます。ただし、ひとつだけ気をつけたいのはdirsyncとAAD Connectは同時起動できないことです。そのため、AAD Connectをインストールするときのウィザードで、インストール後の同期が自動的に行われないよう、設定変更しておきます。
(さらにステージングモードにしておけば、確実に同期は行われなくなります)

その他、ウィザード実行中の注意点としては、
ADFS環境の場合、既にADFSサーバーはインストール済みなので、[ADFSとのフェデレーション]は選択しないこと、

dirsyncからの設定は引き継がないので、手動で同期するOUの設定などは改めて行うことがあげられます。

皆さんこんにちは。国井です。

Enterprise Mobility Suite (EMS) のパッケージで提供されているソリューションのうち、
Azure AD、Microsoft Intune、Azure RMS Premiumに関する評価ガイドと自習書がマイクロソフトさんからリリースされました。

■Microsoft Intune 評価ガイド
Microsoft Intuneを利用して、モバイルデバイスとしてWindows10、iOS、Androidを管理する方法についてステップバイステップで紹介しています。

■Azure 自習書シリーズ　Azure Active Directory による認証環境の構築
Azure ADによるドメイン(ディレクトリ)の作成から、ユーザーやグループの管理までの手順をまとめたドキュメントです。
ADFSサーバーを利用したシングルサインオン環境の構築手順も掲載されています。

■Azure 自習書シリーズ　Azure Active Directory によるアプリケーション管理/Azure RMS の管理

上の自習書で作成した環境をベースに、Azure ADにサインインしたユーザーがクラウドサービスにアクセスする方法や、Azure RMSを利用してドキュメントの保護(暗号化・アクセス制御)を行う方法を手順としてまとめたドキュメントです。

■　■　■

上記の自習書のうち、「Azure Active Directoryによる認証環境の構築編」では、
Azure AD Connectを利用して、ADFSサーバーをインストールする手順を掲載しており、
その中では、
１．Azure AD Connectによるディレクトリ同期ツールのインストール
２．Azure AD ConnectによるADFSサーバーのインストール

という順で、SSO環境の構築に必要なディレクトリ同期ツールとADFSサーバーを別々にインストールしています。
この方法は、会社のSSO環境の導入プロジェクトで、
フェーズ1ではディレクトリ同期までを実装したい、
そして、フェーズ2でADFSを利用したSSO環境を実装したい、
というようなプロジェクトの進め方をしたいときに有効な実装方法です。

一方、Azure AD Connectはディレクトリ同期ツールのインストールと、
ADFSサーバーのインストールは一度にまとめて実行することもできるようになっており、
インストール時に[ADFSとのフェデレーション]を選択すれば、まとめてインストールされます。

Azure AD Connectは、この数か月で猛烈な進化を遂げており、様々なオプションを
私たちに与えてくれてますので、SSO導入のプロジェクトを進める時は、
どのようなオプションがAzure AD Connectで選択できるかを一度確認しておくことをお勧めします。

皆さんこんにちは。国井です。

最近はAzure ADのセミナーやトレーニングで登壇させていただく機会が多く、
参加される方から、かなりの確率で「ブログ見てますよ」と言われます。
こうして声かけてもらうのはうれしいことで励みになります。
また、中にはブログのお問い合わせコーナーからお礼をいただいたり、お仕事のご依頼をいただいたりする方もいらして、
色々な反響を感じることが多く、本当に感謝の気持ちでいっぱいです。

■　■　■

今日は最近、ご質問でいただくことが多い、Azure ADディレクトリ(ドメイン)を削除する方法について載せておきます。
(あまりに何度も同じ話をすることが多く、説明が面倒になってきた、というのはナイショです)

Azure管理ポータル画面で、作成したAzure ADディレクトリの一覧はご覧いただけますが、

この画面から、削除ボタンをそのままクリックすると、

こんな感じで、削除を認めてくれません。

多くの場合、マイクロソフトアカウントを使ってAzure管理ポータルにサインインして、Azure ADディレクトリを管理しており、ユーザーの一覧を見ると、マイクロソフトアカウントが登録されていることが分かります。

Azure ADドメインに登録されているマイクロソフトアカウントを削除してしまえば、Azure管理ポータルからは(マイクロソフトアカウントが管理しているAzure ADディレクトリではなくなるため)消えてなくなります。しかし、Azure管理ポータルからはユーザーを削除させてもらえません。

そこで登場するのが、Windows PowerShell用Azure Active Directoryモジュール。
自分のコンピューターにモジュールをインストールし、実行して、
Connect-MsolServiceと入力して(Azure ADディレクトリの管理者アカウントで)サインインし、

Remove-MsolUserコマンドレットでマイクロソフトアカウントを削除します。
(あらかじめGet-MsolUserコマンドレットでユーザー名を確認しておくと便利ですね)

これで出来上がり。

Azure管理ポータルをリロードすると、

消えてなくなっていることが分かります。

Azure ADディレクトリを削除したか？と言われると、ちょっと違うけど、
簡単に操作するなら、こんな方法ではいかがでしょうか？というものを紹介させていただきました。

お試しあれ。

皆さんこんにちは。国井です。

Azure Active Directory Connect (Azure AD Connect)ツールの1.1.119.0というバージョンが2016年3月にリリースされました。

手順書を作成したり、セミナーでお話しさせていただいたり、している立場としてはユーザーインターフェイスが変わった、手順が変わった、というのはインパクトが大きく、特にVer.1.1台の変更は結構大きいものだったので、少しまとめておきたいと思います。

■同期のスケジュールと実行

ディレクトリ同期のスケジュールは長らく3時間に1回でしたが、今回から30分に1回に変わりました。

設定は

Get-ADSyncScheduler

コマンドレットで確認することができます。

一方、今すぐ実行するときは

Start-ADSyncSyncCycle

コマンドレットで実行することができます。
また、同期実行するのに、Full-Syncだの、Delta-Syncだの、
Synchronization Serviceツールでも見ない限り、気にすることはなかったですが、
ちゃんと、スイッチで使い分けられるようになっています。

Start-ADSyncSyncCycle –PolicyType Delta
Start-ADSyncSyncCycle –PolicyType Initial

Synchronization Serviceで設定変更したときは、設定変更を正しく反映させるためにも
Deltaではなく、Initialを選択すべきかと思います。
また、同期中は設定変更ができません。Synchronization Serviceで設定変更して、OKボタンを押そうとすると、こんなエラーが出ることがあります。以前は3時間に1回の同期タイミングだったので、見かけることは少なかったと思いますが、今は30分に1回ですから遭遇する可能性も高いと言えます。

■スキーマ拡張

今までAPIベースでしかできなかった、スキーマ拡張もセットアップウィザードから簡単にできるようになりました。

セットアップウィザード(セットアップ完了後であれば、デスクトップに保存されているショートカット)からオプション機能で、[ディレクトリ拡張機能の属性の同期]を選択し、

[ディレクトリ拡張]から属性を追加するだけ。

ディレクトリ同期を行うと、Azure ADに属性が追加されます。
追加された属性はGraph Explorerから参照できます。
追加した属性はextension_…で始まる属性名になっています。

■将来のアップグレードを自動で実行

簡単設定限定の機能のようですが、将来、新しいバージョンのAzure AD Connectが登場したときに自動的にアップデートする機能が追加されました。

Get-ADSyncAutoUpgrade

コマンドレットでアップグレードの可否を確認できます。

その他、私自身は確認していないですが、Synchronization Rules Editorでカスタマイズしたルールはエクスポートして別のサーバーへ移行することもできるようになっています。(Ver.1.1台よりも前からできていた？？)
https://azure.microsoft.com/ja-jp/documentation/articles/active-directory-aadconnect-upgrade-previous-version/

ディレクトリ同期ツールに限らず、Azure ADは変化が速くて、ついていくのが大変ですね。

皆さんこんにちは。国井です。

突然ですけど、Azure AD Premiumで提供されている、パスワードリセットライトバック機能って便利ですよね。

外出先にいるユーザーがパスワードを忘れたときに、クラウド上からパスワードをリセットして新しいパスワードに設定し、さらにはディレクトリ同期でオンプレミスのActive Directoryのパスワードまでリセットしてくれるという優れものです。

しかし、ADFSサーバーを利用してSSO環境を構築している場合って、
パスワードリセットするときの下の画面って、ユーザー名を入力すると、勝手に画面推移して、

ADFSサーバーの認証画面に移動してしまうので、パスワードリセットするときのリンクはどこ？ってことになります。
↓こんな感じ

そんな時はADFSサーバーのサインインページをカスタマイズして、[アカウントにアクセスできない場合]リンクを追加しましょう。
[アカウントにアクセスできない場合]リンクをクリックするとアクセスする先となるURLは
https://passwordreset.microsoftonline.com/
なので、このURLリンクを持つ注釈をWebページに追加してあげればいいのです。

設定方法は、、と書こうと思ったら、Active Directory Team Blogに掲載されていたので、参考にしてみましょう。
最初に、ADFSサーバーのサインインページ群がDefaultという名前のプロファイルで作成されているので、
これをコピーして新しいプロファイルを作成します。

New-ADFSWebTheme -Name PasswordReset -SourceName default

Export-ADFSWebTheme -Name PasswordReset -DirectoryPath C:\Theme

ここまでの操作でC:\Themeフォルダーにプロファイルが保存されました。
(C:\Themeフォルダーは先に作成しておいてくださいね)

続いて、C:\Theme\script\onload.jsファイルをメモ帳で開き、最終行から
Active Directory Team Blogの
Step 2: Tweak onload.js to add the linkに掲載されいているスクリプトをそのままコピーしましょう。
コピーできたら、上書き保存。

後は、カスタマイズしたファイルを含むプロファイルをADFSサーバーに適用するだけです。

Set-AdfsWebTheme -TargetName PasswordReset -AdditionalFileResource @{Uri=’/adfs/portal/script/onload.js’;path=”c:\Theme\script\onload.js”}

Set-AdfsWebConfig -ActiveThemeName PasswordReset

これで完成です。
ADFSサーバーのサインインページにアクセスすると、ご覧のとおり。

リンクをクリックすると、ちゃんとパスワードリセットのページにリダイレクトされます。

ここまでのところでお気づきの方もいらしたかと思いますが、
(Office365のSSOの場合)ADFSサーバーのサインインページが表示されるのは、(基本的に)Webアプリケーションプロキシを経由するときだけです。つまり、ADFSサーバーでサインインページのカスタマイズを行えば、その設定はWebアプリケーションプロキシにも反映されるということです。

では次に、せっかくだから表示も「Can’t access your account?」ではなく、[アカウントにアクセスできない場合]にしましょう。
設定は、onload.jsファイルに追加した内容からCan’t access your account?の文字列を[アカウントにアクセスできない場合]に置き換えるだけです。そうすれば、ご覧のように日本語に切り替わります。

このときに気をつけたいのは、onload.jsファイルを保存するときに、名前を付けて保存でUTF-8形式で保存することです。単なる上書き保存してしまうと、ご覧のように文字化けしますので、ご注意ください。

皆さんこんにちは。国井です。

マイクロソフトのEnterprise Mobility Suite (EMS) のビジネスをトレーニングという面から
サポートをさせていただくことが最近多いのですが、「EMSとはなんですか？」というシンプルに問いに対して、私はいつも「クラウドのセキュリティを強化するためのもの」と答えるようにしています。

そのため、「なぜセキュリティ対策にEMSが必要なのか？どのように効果を上げるのか？」という問いに、なんでも答えられるようにするため、セキュリティに関しても当然知識を貯えなければならないと思って情報収集を色々と行っております。

そんな折、先日「サイバーセキュリティ～ハッキングと防御 ビギナー編」を受講する機会がありました。

別にお金をもらってレビューを書いてくれと頼まれたわけでもないのですが、
(バナー的なものを上につけてみたのですが、お金をもらっているっぽくて、かえって怪しい？)なかなか楽しいe-Learningだったので、「トレーナー視点」でレビューを書いてみようと思いました。

■　■　■

自分もトレーニングのビジネスを生業としているので、e-Learningビジネスはウォッチしているのですが、成功したといえるものは少なく、ビジネスと成り立たせることは本当に難しいです。
理由は色々とあるのだろうけど、とりわけ「残念だなあ」と思わせるのが、受講管理システムとかプラットフォームに力を注ぎすぎていて、肝心のコンテンツがつまらないケース。
例えるなら、純金の額縁に国井の描いた絵が飾られているようなものです。
(注釈：国井の「えごころ」は酷く、学生の時に1日かけて書いた絵を学校の先生に見せたら、「真面目にやれ」と怒られたくらい)

その点、サイバーセキュリティ～ハッキングと防御 ビギナー編のe-Learningは飽きさせない工夫がなされていて、「コンテンツがつまらない」と感じさせないのです。
では、トレーナー視点で、その理由を探ってみたいと思います。

リラックスして話が聞ける

e-Learningでも、ライブのトレーニングでも、受講者の方々を緊張させずにリラックスさせて
(これ、専門用語で「アイスブレイク」と言います)、なおかつ集中して受講してもらうことには本当に苦労するのですが、このコースでお話をしている蔵本さんは、いとも簡単にやってのけてしまいます。
お話しする内容もさることながら、セキュリティを語る正義の味方のくせして怪しい風貌(蔵本さん、ごめんなさい！)と関西弁はズルいですよね。
このときばかりは、東京生まれの自分を悔やんだものです。。

実際に試せるコンセプト

e-Learningの欠点って、一方的に話を聞かされるので、飽きちゃうってことなんですよね。
(以前、ある会社の方が第1章から第10章までのe-Learningを作って、社内の人に受講させたら、1章ごとに10％の人が脱落するって言ってました。→これって、10章終わる頃には全員脱落ってこと？？)
サイバーセキュリティ～ハッキングと防御 ビギナー編は仮想マシンを自分で用意すれば、蔵本さんが実演しているデモと同じことをできる点です。
もちろん、仮想マシンとか、Windows 7とか、誰でも簡単に用意できるものではないけど、
話を聞く→実践する、という学習ステップをきちんと踏んでいるので、「聞かされる」とか、「わかった気になる」みたいなことは無いのかなと思いました。
e-Learningって、やっぱり受講者の方が受動的な状態になっているところから、いかに能動的な状態に持っていくかが大事なんですよね。

話が短い時間に区切ってある

1つの話が1時間って言われたら受講するほうも「心してかかる」って感じになりますよね。
それだと「後で聞こう」ってなるので、スキマ時間とかでも聞けるようになっててほしいんですよ。
サイバーセキュリティ～ハッキングと防御 ビギナー編(というか、Udemyのコンテンツすべてがそうなんですが)5分ぐらいに分割してあるんですよね。ものによっては1分ちょっとなんてものもあるので、ちょこちょこ進められるのがうれしい。

でも、間が空くと話忘れちゃうから「前回までの●●」みたいなのは、あってもいいかなと思いました。
(お話しされている回もあったのですが..)

ちなみに、e-Learning業界の雄(と勝手に私が名付けている)Khan AcademyのSalman Khanさんのコンテンツも昔は10～15分程度だったんですけど、最近はもっと短くしているそうですよ。

中身の話はほとんどしなかったけど、Yahooニュースとかでも取り上げられているようなので、詳しくはそちらを見ていただくとよろしいかと。

色々雑多な話になりましたが、e-Learningとしては、とても良い出来の内容でした。
こうした内容のコンテンツがもっと注目され、ビジネスとしても成功するようになってくれると、e-Learning自体も盛り上がっていいのに、と思いました。

皆さんこんにちは。国井です。

今日は2016年4月に開催されたOffice365認証ベストプラクティスコースのフォローアップの内容です。
コースの中で、ADFSで使われるクレームルールについて詳しく知りたいというご意見をいただきました。ADFSサーバーを利用して、Office365のシングルサインオン環境を構築しても、トークンの中に含まれるクレームの中身が見えるわけではありません。

そのため、もしクレームの中身を見たいということであれば、私がいつもお勧めしているのは
Windows Identity Foundation SDK 3.5の中に含まれているサンプルアプリケーションを利用することです。

実装方法は、、と説明しようと思ったら、マイクロソフトさんのWebサイトで紹介していたので、ご覧いただくことをお勧めします。

Windows Server 2012 R2 の AD FS 用のラボ環境をセットアップする
https://technet.microsoft.com/ja-jp/library/dn280939.aspx

既にOffice365のシングルサインオン環境が構築されているのであれば、
上記Webサイトの「手順 3:Web サーバー (WebServ1) とサンプルの要求ベースのアプリケーションを構成する」の部分をご覧いただき、手順に沿って進めていただければサンプルアプリケーションを実装できます。
ここでは、Webサイトで紹介している手順のうち、ポイントとなるところをいくつか紹介しておきます。

ポイント1：ADFSサーバーにサンプルアプリケーションをインストールしない

現行のバージョンのADFSはIISを使いません。そのため、ADFSサーバーにIISをインストールし、SSLサイトを構築すると、443番ポートがADFSとIISの2つのアプリケーションから利用することになってしまい、正しく動作しない可能性があります。そのため、ADFSサーバーではないサーバーを別途用意していただくのが賢明でしょう。(ちなみに私の環境はテスト環境なので、ドメインコントローラーにIISをインストールして動作させました)

ポイント2：ユーザープロファイルの読み込みを有効にしておく

IISの設定で、アプリケーションプールの詳細設定を開き、[ユーザープロファイルの読み込み]をTrueにしておきます。私の環境では、この設定を行わない場合、うまく動作しませんでした。

ポイント3：URLの指定は正確に

フェデレーションユーティリティを実行するとき、証明書利用者信頼を設定するとき、それぞれで指定するURLを厳密に見ています。例えば、https://test/claimappとhttps://test/claimapp/は別々のURLとして認識しますので、注意深く設定してください。

以上のポイントを踏まえて、サンプルアプリケーションを実装すれば、ADFSサーバーから発行されたトークン内のクレームがサンプルアプリケーションを通じて確認できるようになります。

こちらは証明書利用者信頼で、クレームを何も設定しなかった場合

こちらは証明書利用者信頼のクレームルールで、Active DirectoryのUPN属性をmailaddressクレームとして設定した場合

ご覧のようにmailaddressクレームにUPNの値「administrator@example.com」と入っていることが分かりますね。

このように、サンプルアプリケーションをADFSサーバーに実装しておけば、クレームルールを設定した時に、どのような結果が得られるのか視覚化できるので、おすすめです。

最後にポイントをもう一つだけ。
トークンは一度取得すると、ブラウザーを終了しない限り、同じトークンを使い続けます。
そのため、証明書利用者信頼でクレームルールの設定を変更したときは、必ずブラウザーを再起動して結果を確認してください。

■追記
Azure ADから発行されたトークンに含まれるクレームの中身を見たい場合は
ブチザッキさんの「Azure Websites の認証/承認機能」や
私の過去の投稿「Azure ADアカウントを利用したADFSのクレームベース認可」を参考にしていただくとよいと思います。

皆さんこんにちは。国井です。

MSテクノロジーを利用して多要素認証と言えば、Azure MFAサービスを利用したモバイルアプリや電話を利用した多要素認証を思い浮かべる方も多いと思いますが、ADFSサーバー固有の多要素認証機能に証明書を利用した方法があります。多要素認証と言えば「面倒くさい」というイメージが強いですが、証明書を利用した方法であれば、証明書がインストールされているか、いないかを自動的にチェックするので、ユーザーさんに手間をかけさせずに多要素認証を実行できるメリットがあります。

ADFSサーバーを利用した証明書ベースの多要素認証というと、
Active Directory証明書サービスを利用して、
エンタープライズCAをインストールして、
自動的に証明書をインストールして、

という一連の作業手順が定型化しており、しかもそれが唯一の方法であると信じていました。

しかし先日、お客さんと証明書を利用した多要素認証の実装方法について話をしていて、エンタープライズCAを使わないで多要素認証を実装したいとの要望を受け、改めて確認してみることにしました。

結論から先に言えば、

エンタープライズCA以外の認証局から発行した証明書でも多要素認証の証明書として活用することはできます。

では、実装方法を確認してみましょう。

前提条件

ADFSサーバーによる証明書ベースの多要素認証の実装方法については、
過去に「ADFSによる多要素認証の設定」という投稿で紹介していますので、ご覧ください。

証明書の用意

エンタープライズCAで発行される証明書以外の証明書であれば何でもいいのですが、
私の環境では、次のような証明書発行要求を作成して、スタンドアロンCAで証明書を発行することにしました。
(スタンドアロンCAの作成方法などは割愛します)
まずは、以下のファイルをメモ帳で作成し、

[NewRequest]
Subject=”DC=com,DC=example,OU=Employee,CN=hamada,E=hamada@xxx.adfs.jp”
Exportable=FALSE
KeyLength=2048
MachineKeySet=FALSE
SMIME=FALSE
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.2

(OIDはクライアント認証を目的とした証明書を発行しなさい、という意味です。
あ、あと大事なことですが、E=…の欄は利用ユーザーと同じ名前になるように構成してください)
発行要求テキストファイルができたら、コマンドプロンプトで

certutil -new 発行要求テキストファイル名 発行要求ファイル名

で発行要求ファイルを作成して、

スタンドアロンCAのWebサイトから発行要求ファイルの内容をコピペして、発行を要求します。
スタンドアロンCAで発行を許可して、

発行した証明書をクライアントコンピューターからスタンドアロンCAのWebサイトにアクセスして、[保存された要求証明書] をクリックしてインストールします。

これで証明書のインストールができました。
インストールされた証明書はcertmgr.mscツールから確認できます。

認証局とADFSサーバーの連携設定

続いて、ADFSサーバーの多要素認証に利用可能な認証局の設定を行います。
最初に認証局のルート証明書を用意しておきましょう。
スタンドアロンCAの場合、CAのWebサイトから[CA証明書、証明書チェーン、またはCRLのダウンロード]からダウンロードできます。

ダウンロードした証明書はroot.cerという名前で保存しておきます。
保存したファイルはADFSサーバーにコピーし、コマンドプロンプトから次のコマンドを実行します。

certutil –f –addsotre “NTAuth” root.cer

実行すると、ルート証明書がADFSサーバーの証明書ストア内にあるNTAuthストアに格納されます。

これで準備は完了です。
Office365のポータルサイトにアクセスすると、シングルサインオンで自動的に多要素認証画面に推移し、

さらに、ポータルサイトへ自動的に画面が推移します。

この方法が活用すれば、ドメイン参加していないPCにも証明書を利用した多要素認証が実装できるので、デバイス認証の代わりとしても利用できますね。

お試しあれ。

皆さんこんにちは。国井です。

7月6日(水)にゾーホージャパンさん主催のセミナーで、基調講演を担当させていただくことになりました。

■Active Directoryあなたのお悩み解決セミナー
https://www.manageengine.jp/news/event_seminar_ad.html

私の基調講演では、「Active Directoryに必要な適切な運用とは？」と題して、
Active Directoryを運用する上で、よくある課題と、解決策を紹介します。

ゾーホージャパンさんのソリューション紹介や、私も参加する質問＆個別相談会と、盛りだくさんの内容で開催しますので、Active Directoryの運用を担当されている方は是非ご参加いただければと思います。

セミナーでお会いできることを楽しみにしています！

皆さんこんにちは。国井です。

最近、「Windows Server Active DirectoryからAzure Active Directoryに移行したいのですが」というご相談を伺うようになってきました。
Azure Active DirectoryをWindows Server Active Directory的な感じで使いたいと考えた場合、ひとつの課題として出てくるのがPowerShellでADを扱いたいというテーマだと思います。
もちろん、Azure Active Directory (Azure AD)にはPowerShellツールが用意されているけれど、コマンドレットで用意されていないようなことにチャレンジしたいとなると、APIレベルでのアクセスが必要となります。
Azure ADではGraph APIを利用することでAPIレベルでのAzure ADへのアクセスができますが、インフラ屋の私としてはできればVisual Studioを使わないで実現したい。
そんなときに覚えておきたいのが、PowerShellを使ってGraph APIを扱う方法です。

では、順番に見てみましょう。

■ADALライブラリのロード

PowerShellからGraph APIを扱う場合、ADAL(Active Directory Authentication Library)を活用します(ADALそのものの説明は別の機会に)。ADALのライブラリ(ADALのLはライブラリのLじゃない？という突っ込みはしないでね)はいくつかの方法で入手できますが、一番手っ取り早いのはAzure PowerShellをインストールする方法です。Azure PowerShell をインストールすると、C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\Servicesフォルダーにライブラリファイルが生成されます。この中からMicrosoft.IdentityModel.Clients.ActiveDirectory.dllファイルを使います。ですので、Azure PowerShellをインストールしたら、該当するフォルダーにファイルがあることを確認しておいてください。

■Graph APIアクセスを受けるためのAzure AD アプリの作成

クライアントからGraph APIでAzure ADにアクセスする場合、アクセスを受け付けるためのアプリをAzure AD側に追加する必要があります。このアプリはAzure管理ポータルから管理対象となるAzure ADドメインにアクセスし、[アプリケーション]から[追加]をクリックし、アプリケーションを追加します。

追加時に[組織で開発中のアプリケーションを追加]を選択すると、ウィザードが始まり、 [アプリケーション情報の指定]で適当な名前を入力します。

[アプリケーションのプロパティ]で、サインオンURLにhttp://localhostと入力し、アプリケーションID/URIには適当なURLを入れておきます。 URIは単なる識別子なので、一意でありさえすれば、実在する必要はありません。 (ここではhttp://dc.example.com)としておきます。

アプリケーションが出来上がったら、構成タブをクリックします。 (下の画面ではロゴを変えてしまってます)

画面をスクロールしたら、まずクライアントIDが表示されるので、控えておいてください。それから[キー]は通信をするうえで必要になるものなので、作成しておいてください。 (下の画面は作成後のものですが、作成前には作成ボタンがありますので、そちらを使います)

それから上の画面で、[他のアプリケーションに対するアクセス許可]では、Graph API経由でのアクセスを許可する範囲を定義します。以下のように設定しておけば、Azure ADのユーザー情報は少なくとも引っ張ってくることができます。(それ以上の操作が必要なときは追加でアクセス許可を与えてください)

ここまでできたら、保存してAzure AD側の設定を完了します。

■PowerShellスクリプトの作成と実行

スクリプトでは、ADALのロード、アクセスするテナントの指定、AuthenticationContextオブジェクトの作成、そして行いたい操作の順に記述していきます。ここでは、Azure AD の監査レポート(auditEvents)を列挙する操作を行っています。
ちなみに下敷きにしたスクリプトはブチザッキさんの「Azure Management REST API用のBearerトークン」です。

#ADALのロード
$adal = “${env:ProgramFiles(x86)}\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\Services\Microsoft.IdentityModel.Clients.ActiveDirectory.dll”
$adalforms = “${env:ProgramFiles(x86)}\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\Services\Microsoft.IdentityModel.Clients.ActiveDirectory.WindowsForms.dll”
[System.Reflection.Assembly]::LoadFrom($adal)
[System.Reflection.Assembly]::LoadFrom($adalforms)

#アクセスするテナントの指定
$resource = “https://graph.windows.net”
$clientId = “<クライアントID>”
$clientSecret = “<キー>”
$serviceRootURL = “https://graph.windows.net/<テナント名>.onmicrosoft.com”
$authString = “https://login.windows.net/<テナント名>.onmicrosoft.com”

#オブジェクトの作成とトークンの取得
$authContext = New-Object “Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext” -ArgumentList $authString
$clientCredential = New-Object -TypeName “Microsoft.IdentityModel.Clients.ActiveDirectory.ClientCredential”($clientID, $clientSecret)
$authenticationResult = $AuthContext.AcquireToken($resource, $clientCredential)
$authHeader = $authenticationResult.CreateAuthorizationHeader()

#Azure ADから監査レポート一覧を取得
Invoke-RestMethod -Uri “$serviceRootURL/reports/auditEvents?api-version=beta” -Headers @{Authorization=$authHeader} -ContentType “application/json” | select -ExpandProperty value

 

以上の流れを覚えておけば、最終行の太字の部分だけ別の操作を書くことで様々な情報をAzure ADから取得できます。また、最終行の太字で書いた部分を reports/auditEvents?api-version=beta&$filter= と書けば条件設定も可能です。
例えば、1日前以降(24時間以内)のログだけ表示させたければ、最後の行を次のように書き換えます。

$1dayago = “{0:s}” -f (get-date).AddDays(-1) + “Z”
Invoke-RestMethod -Uri “$serviceRootURL/reports/auditEvents?api-version=beta&$filter=&$filter=eventTime gt $1dayago” -Headers @{Authorization=$authHeader} -ContentType “application/json” | select -ExpandProperty value

どんなことを書けば、何が取得できるかについては機会を改めて紹介できればと思いますが、少なくともこの流れを覚えておくと、何かと役に立つのではないでしょうか。

■参考情報

条件設定に利用可能なプロパティ(属性)一覧
https://graph.windows.net/<Azure ADテナント名>.onmicrosoft.com/$metadata

Using the Azure AD Graph Reporting API from PowerShell – Good Workaround! レポート結果から不適切なログが生成されている場合には管理者にメールを送信するまでの流れを紹介しているので便利
https://goodworkaround.com/2015/07/08/using-the-azure-ad-graph-reporting-api-from-powershell/

Azure Active Directory Reporting API の概要 – このブログを書いた後で気が付いたのだけど、同じようなことを紹介してくれています。
https://azure.microsoft.com/ja-jp/documentation/articles/active-directory-reporting-api-getting-started/

皆さんこんにちは。国井です。

私はよくAzure ADのお話をするときに、Azure ADにID基盤を一元化することに関するメリットを強調するのですが、そのときに次のようなスライドをよく使います。

右側にAzure ADで認証することによってアクセスできる先が書いてあるのですが、このうち、社内ネイティブアプリの部分はAzure RemoteAppを使って、オンプレミスで動かしているアプリを切り出して認証もAzure ADを使ってみてはいかがでしょうか？という話をします。

では、ADFSサーバーを使ってシングルサインオン環境が構築されているところで、Azure RemoteAppを動かしたら、どんな動きになるのでしょうか？今日はAzure RemoteAppとADFSの組み合わせによる認証の動作について、紹介します。

クラウドサービスへのアクセスがブラウザーであれば、WS-Federationでいうところの「パッシブプロファイル」の仕様に従って動作するのですが、Azure RemoteAppクライアントはインストールして利用するリッチアプリケーションです。
そのため、ブラウザーからOffice 365にSSOするときみたいに、[ローカルイントラネット]ゾーンにフェデレーションサービス名を登録して、Windows統合認証を利用して、、みたいなことはできず、パスワード入力は必ず求められてしまいます。社内ネットワークからドメインに参加しているコンピューターからアクセスしたとしても例外なくパスワードを入力させられます。

Azure RemoteAppのSSO環境を導入してみようというモチベーションも下がったところで(笑)、実際の動きを見てみましょう。
まず、Azure RemoteApp用のWindows クライアントをインストール・起動し、以下の画面から[開始する]をクリックすると、

最初にサインイン画面が表示されます。
シングルサインオンのユーザー名を入力すると、

サインインページにリダイレクトされることがわかります。
(パケットキャプチャなどをしていると、外部からのアクセスはWebアプリケーションプロキシ、社内からのアクセスはADFSサーバーにリダイレクトされているようです。←ちょっと腑に落ちないポイントがあり、本当かな？と思っています。もし、間違っていたら、どなたかご指摘いただけると助かります)
パスワードを入力してサインインすると、

アクセスできます。

繰り返しますが、ブラウザーからOffice365のサイトにアクセスするとき、
社内からのアクセスであれば、パスワードを入力することなく、アクセスできたのに、
Azure RemoteAppクライアントでは社内からのアクセスであるにもかかわらず、パスワードの入力は求められます。

その他、多要素認証を使う人にとって気になるのがADAL対応ですが、
Azure RemoteAppクライアントはADAL対応になっています。そのため、Azure RemoteAppからでも多要素認証もちゃんと処理してくれます。

最後になりますが、どうしてもAzure RemoteAppでSSOがしたい！ということでしたら、HTML5クライアントを利用するのはひとつの解決策だと思います。HTML5クライアントはブラウザーアプリケーションですので、ブラウザーでOffice365にサインインするときと同じ動きになります。

皆さんこんにちは。国井です。

おかげさまで、このブログも今月で8年目を迎えることになりました。
当初は、2009年にTechEd Japanで登壇したForefront Identity Managerのセッションのフォローアップを目的として始めたブログですが、今ではID管理・連携の分野にまで範囲を広げて扱うようになると同時にページビュー(PV)も増え、おかげさまで「ブログ見てますよ」と声をかけていただく機会も増えてきました(PVを増やすことを目的としているわけではないですが、それでも多くの人に見ていただけるのは、ありがたいですね)。
それと同時に、私の名前に検索をかけてブログにアクセスされる方も結構多いので、ちょうど良い機会ですし、ブログ内の筆者紹介ページに新しく自己紹介と私の仕事について掲載していおきました。よろしければご覧ください。

http://azuread.net/about/

皆さんこんにちは。国井です。

当ブログでもご紹介させていただいている
「Office 365とクラウドサービスの認証ベストプラクティスコース」の7月27-29日開催分が満席になり、追加席を設けたのですが、それも6月6日11時時点で残り1席になってしまったので、追加で2016年9月14-16日の開催を設けることになりました。

教室のキャパシティの事情もあるのですが、何よりも一人ひとりの方のご要望に合わせてカスタマイズしながらコースを進めたいと思っております。そのため、このようなご不便をおかけしますが、よろしければ、2016年9月14-16日の開催もどうぞご検討ください。

よろしくお願いいたします。

皆さんこんにちは。国井です。

オンプレミスのActive DirectoryとAzure ADの間でID情報を同期するだけでなく、ADFSサーバーのインストールやSSO環境の構築など、何かと便利な機能を提供してくれるAzure Active Directory Connect (AAD Connect) ツール。だけど、事前準備が整っていないとAAD Connectはあっさりエラーを表示して私たちを切り捨ててくれます。。そんなときにエラーの原因から何が問題でどのような対処をすればよいか？私が見かけたパターンを公開します。

必須コンポーネントのインストールエラーが表示されるパターン

これは、見たまんまのエラーで、エラーメッセージに書いてあるフォルダー内のファイルを削除しましょう。
ちなみにこれが起こるのは、AAD Connectを複数回実行することが原因です。

Install ADFS Certificateエラーが表示されるパターン

これはわかりやすいエラーで、証明書の構成に問題があるパターンです。
用意すべき証明書がADFSサーバーで使用可能なSSL証明書ではない場合に表示されました。

Configure Web App Proxyエラーが表示されるパターン

結構よく見かけるような気がしますが、私が遭遇したパターンはADFSサーバーで使用するSSL証明書がオレオレ証明書という場合。この場合、Webアプリケーションプロキシの[信頼されたルート証明機関]にSSL証明書の情報(認証局の情報)が登録されていない場合に表示されました。
ADFSサーバーの[信頼されたルート証明機関]に登録されていなくても、ADFSサーバーのインストールエラーとはならないのに、Webアプリケーションプロキシのインストール(構成)時には、[信頼されたルート証明機関]が設定されていないと確実にエラーになります。

ちなみに、[信頼されたルート証明機関]にSSL証明書の情報が登録されていない場合は、手動でWebアプリケーションプロキシをインストールして、ADFSサーバーとの信頼関係を設定してもエラーになります。

Configure New ADFS Taskエラーが表示されるパターン

このパターンはADFSサーバーを過去にインストールしたことがあり、手動でADFSサーバーをアンインストールして、再度AAD Connectを実行すると表示されます。
原因はADFSサーバーをアンインストールしても、ADFSサーバーで使用するデータベースは削除されずに残っていることが原因で、新しいデータベースを作れないことにあります。
こういうときは、「ADFS3.0の再インストールするときの注意点」を参考にデータベースの手動削除を行いましょう。
(エラーメッセージを見ていると、他のエラーパターンでも表示されそうな気がするんですけどね)

Configure New ADFS Taskエラーが表示されるパターンPart2

このパターンも、メッセージは異なりますが、最初の「Configure New ADFS Task」エラーと同じです。対処方法は上記のとおり。

Configure New ADFS Taskエラーが表示されるパターンPart3

このパターンは、ADFSサーバーがリモートから追加された後、再起動が要求される場合に出るエラーです。
ADFSをインストールしたサーバーを一度再起動した後で、[再試行]をクリックしてあげると、エラーが解消されます。

Configure New ADFS Taskエラーが表示されるパターンPart4

これは、何が原因の時に表示されたか、忘れてしまいました。。ごめんなさい。

最後に

Azure AD Connectのエラーは多種多様です。
ここにあるエラー以外にも、単純にタイムアウトしただけ？というエラーもあり、
そうした原因の追及は、やっぱりログを見ることに尽きます。
エラー画面にログファイルへのリンクがついているので、クリックしてアクセスしてみましょう。
そうすれば、こんな感じでログファイルを参照できます。
ポイントは、ERRORというキーワードで検索すること。簡単でしょ？
(画像が小さいので、文字起こしすると
「AAD Failed. This may be due to replication delay.」とのことです。

えっ、タイムアウト？
と思ったら、Azure AD Connectを再実行してみましょう。
本当にタイムアウトだったら、2度目はうまく実行できるだろうし、
他に原因があれば、他のエラーを出してくれます。(←ちなみに私のケースはこっちのパターンでした)

■　■　■

誰かのトラブルシューティングに役立てばうれしいですし、
他にもこんなのがあったよ、とか教えていただけたら、もっとうれしいです。