クラウドエンジニアブログ

Azure AD 証明書ベース認証を試してみた

織田 悠也

こんにちは。ヘルプデスクの織田です。
今回は、2022年2月にパブリックプレビューとしてリリースされた Azure AD 証明書ベース認証 (Azure AD CBA) について、検証結果を交えて紹介していきたいと思います。



「Enterprise Mobility + Security 導入支援サービス」はこちら

「Office 365 ヘルプデスク」はこちら


Azure AD CBA とは? (Azure AD CBA のここがすごい!)

Azure AD CBA は、ブラウザやアプリケーション認証の際、X.509 のユーザー証明書を利用して、Azure AD に対して直接認証を行う機能です。
この機能を活用するメリットは、以下が考えられます。

  • フィッシングに強い証明書ベースの認証が利用でき、セキュリティの強度があがる
  • Azure AD に対する認証方法のバリエーション増加
  • ADFS サーバーなしで証明書ベースの認証を実現

最大の注目ポイントは、ADFS サーバーを構成せずに証明書ベースの認証が実現可能になった点であるかと思います。
証明書ベースの認証を実現するために ADFS の認証基盤を構成していたお客様においては、Azure AD CBA への移行が実現できれば、ADFS 利用にかかっていたコストを削減できます。

【参考: Azure AD の証明書ベースの認証に関する概要 (プレビュー)


「Enterprise Mobility + Security 導入支援サービス」はこちら

「Office 365 ヘルプデスク」はこちら


利用にあたっての前提条件

Azure AD CBA の利用にあたっての前提条件は、以下の通りです。

<前提条件>

  • Azure AD に少なくとも1つの認証局 (CA) と中間の認証局を登録すること
  • Azure AD に対して認証するために、クライアント認証を目的とした X.509 ユーザー証明書を端末にインストールすること

つまり、端末に信頼できる認証局から発行されたクライアント認証用の証明書をインストールし、その認証局を Azure AD に登録する必要があるということです。

尚、説明は割愛させていただきますが、Intune に登録された端末の場合、Intune 機能を利用して、クライアント証明書を配布することが可能です。

では、Azure AD CBA を利用した証明書認証の動作を確認していきたいと思います。

「Enterprise Mobility + Security 導入支援サービス」はこちら

「Office 365 ヘルプデスク」はこちら


Azure AD CBAを構成してみた① (Azure AD に認証局を登録)

前提条件で記載した通り、クライアント認証で利用する X.509 証明書を発行した認証局を Azure AD に登録する必要があります。
登録作業にあたって必要な情報は、以下の通りです。

  • 認証局のルート証明書
  • 認証局の CRL 配布ポイント

上記の情報が確認できたら、Azure AD PowerShell を利用して、Azure AD に認証局を登録していきます。

<Azure AD への認証局登録手順>
1. Windows PowerShell を管理者権限で起動します。

2. 以下のコマンドを実行して、Azure AD の PowerShell モジュールをインストールします。 (モジュールバージョンは 2.0.0.33 以降)

Install-Module -Name AzureAD

3. 以下のコマンドを実行して、管理者アカウントの資格情報を入力し、Azure AD テナントに接続します。

Connect-AzureAD

4. Azure AD に認証局を登録するために、登録する認証局の [ルート証明書 (ファイルパス指定)] と [CRL 配布ポイント URL] を設定し、以下のコマンドを実行します。

$cert=Get-Content -Encoding byte “[認証局のルート証明書(ファイルパス指定)]“
$new_ca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation
$new_ca.AuthorityType=0
$new_ca.TrustedCertificate=$cert
$new_ca.crlDistributionPoint=“[CRL配布ポイントURL]"
New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_ca

5. “Get-AzureADTrustedCertificateAuthority” コマンドを実行して、認証局が登録されたことを確認します。

以上で認証局の登録は完了です。

「Enterprise Mobility + Security 導入支援サービス」はこちら

「Office 365 ヘルプデスク」はこちら


Azure AD CBAを構成してみた ② (Azure AD CBA 有効化 &認証 ポリシーの構成)

次に、Azure AD CBA を有効化および認証ポリシーを構成していきたいと思います。

<Azure AD CBA の有効化および認証ポリシー構成手順>
1. Azure AD 管理センター (https://aad.portal.azure.com/) にサインインします。

2. [Azure Active Directory] - [セキュリティ] - [認証方法] を開きます。

3. [ポリシー] - [証明書ベースの認証 (プレビュー)] を開きます。

4. [Basics] タブで、[有効にする] を “はい” に変更し、証明書ベースの認証を有効化するユーザーもしくはグループを指定します。

5. [Configure] タブで、認証規則を指定し、[保存] を選択します。
※ 今回の検証では、単一要素認証で、X.509 ユーザー証明書の認証フィールドは、[UserPrincipalName] で設定しました。

Azure AD CBA の有効化および認証ポリシーの構成は以上です。
認証ポリシーの構成では、Azure AD に登録した認証局がタブに表示され、感覚的に設定することができます。

尚、現在サポートされている X.509 ユーザー証明書の認証フィールドは、以下のみとなっています。

  • SAN Principal Name > userPrincipalName
  • SAN Principal Name > onPremisesUserPrincipalName
  • SAN RFC822Name > userPrincipalName
  • SAN RFC822Name > onPremisesUserPrincipalName

【参考:How to configure Azure AD certificate-based authentication without federation (Preview)

「Enterprise Mobility + Security 導入支援サービス」はこちら

「Office 365 ヘルプデスク」はこちら


認証動作をテストしてみた

Azure AD CBA の構成が完了しましたので、証明書ベースの認証が正しく動作するかをテストしていきたいと思います。
テストでは、X.509 ユーザー証明書をインストールした端末とインストールしていない端末で、マイアプリのページ (https://myapps.microsoft.com) にアクセスした際、認証結果がそれぞれどうなるかを確認していきます。

X.509 ユーザー証明書 未インストール端末での認証テスト

マイアプリのページ (https://myapps.microsoft.com) にアクセスし、[証明書を使用してサインする] を選択します。
※ [証明書を使用してサインする] は、テナントで Azure AD CBA を有効化すると表示されるようになります。

“申し訳ありませんが、サインイン中に問題が発生しました。” とメッセージ表示され、認証に失敗します。

Azure AD のサインインログを確認してみると、X.509 の証明書認証に失敗していることがわかります。
これにより、証明書がインストールされていないことで認証に失敗したと評価できます。

X.509ユーザー証明書 インストール端末での認証テスト

マイアプリのページ (https://myapps.microsoft.com) にアクセスし、[証明書を使用してサインする] を選択します。

認証に利用する証明書の選択画面が表示されるので、対象の証明書を選択します。
※ 証明書の選択は、初回のみで2回目以降は確認が求められませんでした。

認証に成功し、マイアプリの画面に、証明書の認証のみでアクセスができました。

Azure AD のサインインログでも、認証成功のログが記録されておりました。

「Enterprise Mobility + Security 導入支援サービス」はこちら

「Office 365 ヘルプデスク」はこちら


さいごに

今回は、新たにプレビューリリースされた Azure AD CBA を紹介していきましたが、いかがでしたでしょうか。

信頼できる認証局の X.509 ユーザー証明書の準備ができていれば、構成自体は比較的容易にできると感じました。

まだまだ、認証オプションが少なく、現時点では ADFS で実現していたことをそのまま代替はできないと思われますが、マイクロソフト社は、Windows スマート カード ログオン、第二認証要素としての CBA、信頼できる発行者リストの制限撤廃等、更なる機能追加を予告しておりますので、近い将来 ADFS を利用した証明書認証に取って代わることは間違いないかと思われます。

ADFS による証明書認証を構成している環境の管理者様は、Azure AD CBA の新機能追加等の動向をチェックいただくことをお勧めしたいと思います。

以上、ご拝読ありがとうございました。

関連ページ

「Enterprise Mobility + Security 導入支援サービス」はこちら
「Office 365 ヘルプデスク」はこちら

【総合】お問い合わせ

製品・サービスに関するお問い合わせはお気軽にご相談ください

ピックアップ

セミナー情報
クラウドエンジニアブログ
clouXion
メールマガジン登録