AD FS認証に生体認証などを追加してMFAを実現してみた

カバー

[！] この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

昨今、さまざまなサービスにおいて、多要素認証（MFA）を求められるのが当たり前になりつつあります。MFAを導入することで、アカウントを侵害されるリスクが半減するというGoogleのデータもあります。当社でも、出先からの業務システム利用にMFAを導入しています。この度、運用改善を目的として、オープンソースのソフトウェアからAD FSに、認証ソフトウェアを移行することになりました。このため、AD FS用のMFA機能が必要になり、いろいろと調べていたところに、同僚からadfsmfaという拡張機能を教えてもらいました。

adfsmfaとは

adfsmfaとは、プロバイダーの追加を必要とせずに、AD FSでMFAを実現できるオープンソースの拡張機能です。これを利用することで、通常のパスワードに加えて、メールアドレスに送信されたコードを要求するメール認証や専用アプリが生成した確認コードを要求するワンタイムパスワード認証を追加できます。adfsmfaには、他にも以下の特徴があります。

  • 日本語対応したUI
  • PowerShellとMicrosoft管理コンソール（MMC）による管理
  • RNG／AES／RSAによるシークレットキー生成
  • MFAメタデータをAD DS属性またはSQLサーバーに保管
  • WebAuthn・FIDO2に準拠した生体認証
  • セルフサービスのユーザー管理
  • Windows Server 2012R2／2016／2019／2022に対応

これまで利用できなかった生体認証が、利用者の利便性向上に大きく寄与すると考えて、adfsmfaの採用を決めました。

AD FSへのMFA機能追加

AD FSファームへの登録

AD FSファームの新しいMFAプロバイダーとして、adfsmfaを登録します。

以下は、AD FSサーバーが1台構成である場合の手順です。AD FSサーバーが複数存在する場合は、追加の手順が必要になるので、ドキュメントのインストール手順を参照してください。

  1. （2012 R2／2016の場合）AD FSサーバーに、.NET Framework 4.7.2以降をインストール
  2. GitHubリポジトリ ⧉のからadfsmfa.3.X.YYYY.Z.msiをダウンロード
  3. 各AD FSサーバーにローカル管理者でログインし、ダウンロードしたMSIファイルを使用してインストールを完了
  4. プライマリAD FSサーバーにAD FS管理者でログインし、PowerShellを管理者として実行
  5. 以下のコマンドレットを実行して、AD FSファームの新しいMFAプロバイダーとしてadfsmfaを登録 
    Register-MFASystem

MFAメタデータの保管方法

続いて、ユーザーのMFAメタデータをAD DS属性として保存するか、SQL Serverをリポジトリとして使用するか決定する必要があります。AD DSモードは、外部プラットフォームは不要で、シンプルな構成になりますが、すべてのドメインコントローラーに対するデータ同期には時間がかかる場合があります。SQLモードは、SQL Serverのライセンスコストを必要としますが、データの複製は不要で、他のアプリケーションとのデータ共有が容易になります。 adfsmfaのドキュメント ⧉には、さまざまな条件でどちらのモードを選択すべきかのヒントが公開されています。当社の環境では、AD FSサーバーは1台しか存在しないので、AD DSモードを採用しました。

adfsmfa用の属性を追加するために、AD FSサーバーのC:\Program Files\MFA\ADDSTools\mfa-schema.ldfを以下のように修正しました。

  • DN（識別名）とobjectCategory属性にある",DC=X"を、実際のドメイン（例：",DC=mydomain,DC=com"）に置換
  • adfsmfaが使用する属性の名称を変更する場合は、各エントリのadminDescription、adminDisplayName、lDAPDisplayName、name、mayContainの属性、およびDNのCN（共通名）を修正
  • 属性に対するクエリのパフォーマンスを向上するために、属性エントリのsearchFlags属性を1に変更して、インデックスを付与

たとえば、ユーザーのキーを配置する属性（KeyAttributeプロパティ）のエントリは、以下のように修正しました。

dn: CN=alphasystems-inc-Custom-AdfsMfaKey,CN=Schema,CN=Configuration,DC=alpha,DC=co,DC=jp
changetype: ntdsSchemaAdd
adminDescription: alphasystems-inc-Custom-AdfsMfaKey
adminDisplayName: alphasystems-inc-Custom-AdfsMfaKey
attributeID: 1.2.840.113556.1.8000.2554.43963.64993.29055.17455.46959.14109314.12081409
attributeSyntax: 2.5.5.12
isSingleValued: TRUE
lDAPDisplayName: alphasystemsinc-CustomAdfsMfaKey
name: alphasystems-inc-Custom-AdfsMfaKey
oMSyntax: 64
instanceType: 4
searchFlags: 1
isMemberOfPartialAttributeSet: TRUE
showInAdvancedViewOnly: TRUE
objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=alpha,DC=co,DC=jp
objectClass: attributeSchema
schemaIdGuid:: HsVYIgTzb0GckVnZwLEJEQ==

ファイルの修正が完了したら、ドメイン管理者として以下のコマンドを実行します。

LDIFDE -i -u -f mfa-schema.ldf

スキーマの拡張後は元に戻せなかったので、ファイル内の属性名が正しいか確認するとともに、ドメインコントローラーのバックアップを強く推奨します。

adfsmfaの基本設定

MMCを利用した管理を行うには、AD FSのプロパティを以下のように設定する必要があります。

  1. AD FSサーバーにてAD FSの管理を起動し、操作メニューからフェデレーション サービスのプロパティの編集を選択
  2. プロパティを以下の図のように設定する。この際に、委任名はドメイン管理者グループを指定

フェデレーション サービスのプロパティ

AD FSの設定が完了したら、デスクトップに作成されたMFAのショートカットから、adfsmfaの管理画面を開きます。

  1. 左メニューからグローバル パラメータを選択し、サービスの全般設定を表示
  2. 会社名、管理上の連絡先 (電子メール)や既定の国コードを適切に入力して、保存をクリック
  3. AD DS属性の名称を変更した場合
    1. 左メニューからストレージ構成、アクティブ ディレクトリ構成の順で選択
    2. アクティブ ディレクトリ属性の設定を変更した名称に変更して、保存をクリック
  4. メール認証を利用する場合
    1. 左メニューからMFA プロバイダー、電子メール多要素プロバイダーの順で選択
    2. ユーザーに送信されるメールに表示される会社名を適切に入力
    3. メールの送信元アドレスを 管理者の連絡先 (送信元) に入力
    4. SMTPサーバーの設定をメール サーバーと識別に対して実施し、保存をクリック
  5. 生体認証を利用する場合
    1. 左メニューからMFA プロバイダー、バイオメトリクス多要素プロバイダの順で選択
    2. サーバードメインを利用中のドメイン名（例：contoso.com）に指定
    3. サーバー名をAD FSサーバーの名前（例：adfs.contoso.com）に指定
    4. サーバー URLをAD FSファームのURL（例：https://adfs.contoso.com）に指定
    5. 左メニューからセキュリティ構成、WebAuthN 認証の順で選択
    6. AndroidやiOSの生体認証を利用したいので、オーセンティケータアタッチメントをPlatformを指定
    7. 構成証明の伝達の優先順位を、iOSのTouchID/FaceIDが正常に動作できたNoneを指定

これで、adfsmfaの基本設定が完了したので、MFAの挙動を確認できます。

テストユーザーの追加

adfsmfaの管理画面から動作確認用のユーザーを追加して、MFA機能の動作確認を行います。

  1. 左メニューからユーザー管理を選択し、右メニューからユーザーを追加を選択

  2. 名にMFAを設定したいADユーザーのUPN（例：test0001@contoso.com）を入力

  3. 電子メールの服装にメール認証のコードを受け取るメールアドレスを入力

    ユーザー情報の設定

  4. キータブに移動し、新しいキーをクリック

    キーの作成

  5. Google Authenticatorなどで、表示されたQRコードをスキャンして、アカウントを追加

さらに、動作確認用の証明書利用者信頼に対して、AD FSの管理からアクセス制御ポリシーをすべてのユーザーを許可し、MFA を要求に変更します。

adfsmfaの動作確認

メール認証

MFAを要求するようにしたサービスへアクセスすると、ユーザー名とパスワードの入力後に、メールで送信された確認コードを入力するように要求されます。

メール認証の実行

ユーザーの追加で指定したメールアドレスにセキュリティコードが送信されるので、コードを入力してサインインすると、サービスにログインすることができました。

ワンタイムパスワード認証

メールで送信された確認コードの入力画面で、別の方法でサインインするを選択すると、MFAで利用する認証方式を選べます。ワンタイムパスワード認証を利用する場合は、認証アプリケーションを使用するを選択します。この際に、選択内容を記録するにチェックを入れると、ワンタイムパスワード認証が次回以降も要求されるようになります。

ワンタイムパスワード認証の選択

QRコードをスキャンしたアプリ（Google Authenticatorなど）を起動し、追加したアカウントに表示された確認コードを入力します。

ワンタイムパスワード認証の実行

アプリに表示されたコードは、規定では30秒経過すると次のコードに切り替わりますが、さらに60秒間は有効なので、焦らずに入力してください。コードを入力してサインインすると、サービスにログインすることができました。

生体認証

生体認証の設定は、先ほどの管理画面から行うことはできず、MFAを要求するサービスのサインイン時に利用者が設定します。コードを入力してサインインする際に、認証後にオプションにアクセスするにチェックを入れると、生体認証を含めたMFAの設定画面にアクセスできます。

MFAの設定

生体認証デバイスを登録するを選択すると、デバイス名の入力が求められ、デバイスの登録をクリックすると、利用中のデバイスに備わっている生体認証機能が起動し、認証を要求されます。

生体認証の登録

生体認証の設定後にサービスへ再アクセスを行い、認証方法として生体認証デバイスの使用するを選択し、サインインをクリックすると、デバイスの生体認証機能が再び起動し、サービスにログインすることができました。

生体認証の起動

なお、当社での環境ではAndroidの指紋認証、iOSのTouchID／FaceIDが利用できることを確認しています。

当社独自のカスタマイズ

AD FS認証にMFAを追加できることを確認できたので、当社のMFA利用における要件を検討したところ、以下の通りになりました。

  • MFAの設定は、社内外の両方から実施できること
  • 社外からの設定の際には、すでに設定済みのMFAを必要すること
  • 利用者はMFAの無効化やパスワードの変更を禁止すること

最後の項目について少し補足すると、adfsmfaにはセルフサービスのユーザー管理の機能として、パスワードリセットを提供できます。ただ当社では、社外へAD FSのパスワードリセット機能を提供していないので、それに準じてadfsmfaによるパスワードの変更もできないことにしました。

adfsmfaの設定には、グローバルな項目も存在するので、社内や社外といったサービスにアクセスする場所によって、MFAの挙動を変更することはできません。したがって、MFAを要求するサービスに、どこからアクセスしても問題ない設定にする必要があります。 さまざまな設定を試したところ、管理画面からグローバル パラメータの項目を以下のように設定すれば、要件を満たすことができました。

adfsmfaのグローバル オプション

  • セキュリティ ポリシー (モデル)：Custom Template
    • adfsmfaには、ユーザーアクティベーションに関する挙動ポリシーが事前定義されている。しかし、当社の要件を満たすポリシーがなかったため、カスタム設定を選択した
  • MFA ステータス:
    • 必須 - MFA を無効にすることはできません
      • ユーザーによる無効化（オプション - MFA はオプションで無効にできます。 の挙動）や、MFAが無効の場合にサインインできる（不要の挙動）ことを禁止したいため
    • 必須 - サポートによる登録
      • 社外からのユーザー登録（管理 - サポートによって確認された登録およびユーザー - ユーザーによる登録の挙動）や、MFAが未設定の場合にサインインできる（管理されていない - サポートに連絡するの挙動）ことを禁止したいため
  • オプション管理
    • 登録ウィザード
    • ユーザーは既定のプロバイダーを選択できます
    • 構成の変更後にユーザーに通知する
    • ブラウザ言語を使用する

MFA情報の移行

既存の認証ソフトウェアはユーザーのMFA情報をデータベースに格納していたので、AD FSへの移行に伴うMFA情報の再設定が必要になりました。そこで、設定作業の負担軽減のため、データベースから抽出した情報を、ADユーザーの対応するAD DS属性として自動設定することを試みました。メール認証のアドレスは容易に移行できたのですが、ワンタイムパスワード認証のシークレットキーは、利用可能なキーサイズが事前に決まっており、既存と互換性がなかったため、移行を断念しました。その代わりとして、メール認証のアドレスを設定できるWebサイトを構築し、既存のワンタイムパスワード認証を利用して、社外からアクセスできるようにしました。ワンタイムパスワード認証しか設定していない利用者には、メールアドレスの設定後にadfsmfaが提供する設定機能を利用して、ワンタイムパスワード認証や生体認証を設定してもらう運用にしました。

今後の課題

その後、メールアドレスの移行および再設定を実施し、各サービスの認証をAD FSに移行しました。移行により、モバイル端末で使い慣れた生体認証によりサインインできるようになり、周りの利用者からの評判も好評です。 ただ使い続けていると、パスワードすらも利用しないパスワードレス認証を要望する声がでてきました。試しに、生体認証を利用する場合はパスワード不要にできないか検証したところ、選択した認証方式ごとにMFAの設定が可能か設定できないため、生体認証以外でもパスワード認証なしで設定ができてしまいました。今後のアップデートにより、MFAの挙動を認証方式ごとに設定できることを期待したいと思います。

とは言うものの、adfsmfaは一般的な用途ならば、必要十分な機能が備わっています。AD FS認証のセキュリティ強化に、adfsmfaを導入してみてはいかがでしょうか。

▲
TOP
アルファロゴ 株式会社アルファシステムズは、ITサービス事業を展開しています。このブログでは、技術的な取り組みを紹介しています。X（旧Twitter）で更新通知をしています。
X @techblogalpha