「エンタープライズアプリケーション」と「アプリの登録」の違いについて

こんにちは、Azure Identity チームの宮林です。 今回は Azure Active Directory の管理項目にある、「エンタープライズアプリケーション」と「アプリの登録」のそれぞれの違いについて紹介します。 初めてアプリケーションの登録を行おうとした際にどちらで設定すれば良いのかと、気になった方も多いのではないでしょうか。 この記事では、そのような疑問に対する答えとして、それぞれの違いについて説明します。   「エンタープライズアプリケーション」と「アプリの登録」の違い   アプリケーションをテナント (Azure AD) に登録する際に「エンタープライズアプリケーションの登録」と「アプリの登録」それぞれの方法では、登録する目的が異なります。 端的に説明すれば以下のようになります。   「エンタープライズアプリケーション」:既存の SaaS アプリケーション (オンプレミスの環境で提供しているサービスを含む) をテナントに統合する場合に用いる。 「アプリの登録」:開発したアプリケーションの公開、もしくは利用するために用いる。   (ここで、統合が指す意味は、SaaS アプリケーションに対する シングルサインオン (SSO) の構成や、ユーザーのプロビジョニング構成を行うことなどを指します。) それぞれの項目で、アプリケーションの登録を行う場合の目的の違いついて、詳細を説明します。   「エンタープライズアプリケーション」からアプリケーションの登録を行う場合   例えば、GitHub、Salesforce、Slack や G Suite など、Azure Marketplace もしくは、Azure ポータルより [Azure Active Directory] – [エンタープライズアプリケーション] – [+新しいアプリケーション] を選択した際に表示されるページで公開されている、事前に統合された SaaS アプリケーションをテナントに追加して利用するために使用します。 それぞれの SaaS…


Office 365 の TLS 1.0/1.1 無効化に伴うAzure AD Connectの対応

こんにちは。 Azure Identity サポートの谷です。 以下のサイトで案内している Office 365 での TLS 1.0 と 1.1 の無効化に伴う、Azure AD Connect での対応についてまとめました。   Office 365 への TLS 1.2 の実装に対する準備 https://support.microsoft.com/ja-jp/help/4057306/preparing-for-tls-1-2-in-office-365   Azure AD Connect でも TLS 1.2 による接続を有効にする必要があります。 Azure AD Connect では、Azure AD Connect、OS (および更新プログラムの適用状況)、.Net Framework のバージョンに依存し、それぞれ対応が異なります。 TLS 1.2 を Azure AD Connect の通信で使用するためのサマリは以下の通りです。   各バージョン毎での対応 ======================================== □ OS として TLS…


Azure Active Directory への接続で使用する IP アドレス範囲の変更

日々ブログをご愛読してくれている皆様、Azure Identity チームの宮林です。 先日、新着情報にて広報された、2018 年 9 月 10 日までに変更が行われる Azure Active Directory の IP アドレス範囲についてお知らせいたします。 IP アドレス範囲の変更とありますが、去年から追加となった範囲内への変更となりますので、すでにご対応済みの場合は影響がございません。 以下のページで告知している Azure Active Directory の新着情報の抜粋と、Q&A 形式で IP アドレス範囲の変更に伴う影響について補足します。   Azure Active Directory の新着情報 https://docs.microsoft.com/ja-jp/azure/active-directory/fundamentals/whats-new 以下抜粋 ——————————————————————- 2018 年 7 月 Azure Active Directory の IP アドレス範囲の変更 タイプ: 変更の計画 サービス カテゴリ: その他 製品の機能: プラットフォーム Microsoft では、Azure AD に対してより大規模な IP…


Azure AD におけるロール管理の新しい方法

こんにちは、Azure & Identity サポート チームの栗井です。 本記事は、2018年7月末に公開された A new way to manage roles and administrators in Azure AD を元にしています。 これまで、 Azure AD の全体管理者などのロールを割り当てられているユーザー一覧を取得することができなかったのですが、最近の更新により、簡単に確認できるようになりました。 元記事を参考に、ユーザーへのディレクトリロールの新しい割り当て・管理方法について、画面キャプチャを含めてご紹介します。   Azure AD におけるロール管理の新しい方法   ユーザの役割の確認や管理者権限の割り当てを、これまでより簡単におこなうことができます。 以下が、新しい機能の特徴です。 ビルトイン (既定) のディレクトリロールの一覧と、それぞれの詳細を確認可能 役割の管理や設定がより簡単に 関連ドキュメントへのリンク追加 言い換えますと 「全体管理者は何人いるのか?」「このユーザーに割り当てられているのは何の役割か?」がすぐ分かるようになりました。 概要画面から、新機能「ロールと管理者」がご利用できます 概要   ビルトイン ディレクトリ ロールの一覧とそれぞれの簡単な説明は 「ロールと管理者」をクリックすることで確認できます。これも最近追加されました Azure AD と連携するアプリケーションの管理を目的とした新しいロールも含まれます。 現在サインインして操作を実施しているユーザー自身に何かしらのロールが割り当てられている場合、画面上部に表示されます。「ロール」をクリックすると、自身に割り当てられているロールと、それぞれの概要の一覧を確認できます。 「ロールと管理者」下の、各ロールと説明の一覧   また、ロールの行をクリックすると、そのロールに割り当てられているユーザーの一覧が確認できます。 ロールに割り当てられているユーザー(メンバー)一覧   各ロールによりどのようなことができるのかという質問をよく頂きますが、それぞれのロールに何の権限があるのか、その詳細を一覧でみられるようになりました。同じ画面で、関連記事のリンクも見ることができます。ロールを最大限有効に使うためにぜひご活用ください。 画像に示すように、ブレードの「説明」をクリックするとこの画面が見られます。もしくはロールの一覧画面から、各行の右側にある「・・・」をクリックをすることでも、同じ画面に辿り着くことができます。…


「ユーザーはアプリケーションを登録できる」の設定について

こんにちは、Azure Identity チームの宮林です。 今回は Azure  Active Directory における、アプリケーションの登録の制限について紹介します。   Azure Active Directory では、お客様が開発したアプリケーションを登録することで、Azure Active Directory に登録されているアカウントを利用したシングルサインオンを実現することが可能です。既定では、一般ユーザーでも、[アプリの登録] から自身で開発したアプリケーションを自由に登録することができます。一般ユーザーによるアプリケーションの登録は、Azure  Active Directory 内の [ユーザー設定] にある「ユーザーはアプリケーションを登録できる」で制御が可能です。下記画面のとおり本設定は既定で「はい」となっており、この状態での運用をお勧めします (お勧めしている理由は後述します)。 一方、ゲスト ユーザーは、「ユーザーはアプリケーションを登録できる」が「はい」となっていた場合でもアプリケーションを登録することができません。     ユーザーがアプリケーションを登録できる状態を推奨する理由 管理者としては、一般のユーザーにアプリケーションを登録できるようにしておくことについて抵抗感を持たれるようなことがあるのではないかとも思います。 しかし、この設定を「いいえ」に設定してユーザーによる登録を制限した場合には、ユーザーは自身で Azure Active Directory のテナントを作成して組織の管理が及ばないテナントにアプリケーションを登録して作業を行う可能性が高くなります。このような状況は、いわゆるシャドー IT を促進してしまうことに繋がるため、「ユーザーはアプリケーションを登録できる」の設定を「はい」にすることを推奨しています。 組織で管理されているユーザーがビジネスを目的として組織アカウントを使用してアプリケーションを利用されることで、管理者はどのようなアプリケーションが、どのユーザーによって利用されているか確認することができます。また、その利用が適切でない場合には、ユーザーに注意を促すこともできますし、ユーザーが組織を離れた場合にも、その組織アカウントを削除することでアプリケーションへのアクセスも停止させることができるなど一元管理のメリットを得られます。 アプリケーションの追加に関して、以下の公開情報を併せてご参照ください。   アプリケーションを Azure AD に追加する方法と理由 https://docs.microsoft.com/ja-jp/azure/active-directory/develop/active-directory-how-applications-are-added   アプリケーションの登録を制限する方法 Azure Active Directory の [ユーザー設定] で、「ユーザーはアプリケーションを登録できる」を「いいえ」に変更することによって、一般ユーザーによるアプリの登録を行えなくすることが可能です。このとき、一般ユーザーがアプリケーションの登録を行おうとすると、十分な権限が無い旨のエラーが表示されます。 なお、「ユーザーはアプリケーションを登録できる」を「いいえ」に設定した場合は、以下のロールを持つアカウントからのみ、アプリケーションの登録が可能です。 全体管理者 アプリケーション管理者…


“Baseline policy: Require MFA for admins” について

こんにちは、Azure ID チームの宮林です。 今回は下記のとおり、6/22 より Public Preview となった “Baseline policy: Require MFA for admins” についてお知らせいたします。   Baseline security policy for Azure AD admin accounts in public preview! https://cloudblogs.microsoft.com/enterprisemobility/2018/06/22/baseline-security-policy-for-azure-ad-admin-accounts-in-public-preview/ ベースラインの保護とは (プレビュー) https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-conditional-access-baseline-protection   (こちらが対象のポリシーとなります)   “Baseline policy: Require MFA for admins” とは “Baseline policy: Require MFA for admins” は、特権ロールを持つアカウントに対して多要素認証 (MFA : Multi Factor Authentication) を必要とさせるポリシーです。将来的にすべての Azure…


Azure MFA を求められるタイミングについて

こんにちは、Azure ID チームの田中です。 Azure AD では、ユーザー名、パスワードによるサインインだけでなく、多要素認証(MFA) を簡単に構成することができます。 私たちのサポートチームでは多要素認証(MFA) についてよくお問い合わせをいただくのですが、 今回はMFA を有効化しているのにも関わらず、MFA を求められないことがあるということで、Azure MFA を要求されないケースについて、その理由を含めて紹介します。   MFAとは? Multi-Factor Authentication の略で、ユーザー名・パスワードの認証にプラスして別の認証を求める機能を指します。 例えば社内ネットワーク以外からのアクセスであれば、ユーザー名とパスワードだけではなく、SMS 認証を強制することが可能になり、セキュリティをさらに高めることができます。 Azure の機能では電話認証(電話・SMS)、Authenticator アプリを使用した認証を提供しています。   ・参考情報 Azure Multi-Factor Authentication とは https://docs.microsoft.com/ja-jp/azure/active-directory/authentication/multi-factor-authentication   Azure MFA を再び要求されないのは果たして安全なのか 初回 MFA を要求された後に MFA を求められなくなるシナリオとしては大きく分けて2つあります。   A. MFA の画面で多要素認証の記憶がオンになっている B. 各種トークンが使用されている   ここではそれぞれのシナリオについて、その理由と解決策、セキュリティ面をご説明致します。   A. MFA の画面で多要素認証の記憶がオンになっている ユーザーが Azure AD…


Azure AD と AD FS のベスト プラクティス: パスワード スプレー攻撃の防御

こんにちは、Azure Identity サポートの宮林と高田です。 本記事は、米国時間 2018 年 3 月 5 日に公開された Azure AD and ADFS best practices: Defending against password spray attacks の抄訳です。Azure AD と AD FS に関してパスワードスプレー攻撃を取り上げた情報がまとめられており、日本のサポート チームとして皆様にぜひ内容を共有したく日本語化しました。     皆さんこんにちは。 パスワードを用いたログインを採用している限り、第三者がそれを推測しようとすることは避けられません。このブログでは、最近非常に頻繁に行われるようになったパスワード スプレーと呼ばれる攻撃手法と、それに対する防衛のためのベスト プラクティスについて説明します。 パスワード スプレー攻撃では、攻撃者が多くの人が設定するような一般的なパスワードで、複数の異なるアカウントに対してログインを試行することで、パスワードで保護されたリソースにアクセスを試みます。 通常、これらは 1 つの組織や 1 つの認証基盤に留まることなく行われます。例えば、攻撃者は Mailsniper などの一般にも入手可能なツールを用いて、複数の組織の全てのユーザーを列挙し、それらのアカウントすべてに対して “P@$$w0rd” や “Password1” などのパスワードを試します。 攻撃のイメージとしては、以下のようなものが挙げられます。    Target User  Target Password  User1@org1.com  Password1…