Zenn
🪪

ADFS を利用した非ルートドメインの Entra ID フェデレーション認証

2025/03/08に公開
Microsoft 365
Entra ID
tech

オンプレミスにある Active Directory と、クラウド上の Entra ID を連携させる場合は、基本的に UPN (User Principal Name) を合わせる事が推奨されており、通常は オンプレミスにある Active Directory と、Entra ID で UPN を合わせるか、代替UPNサフィックスを用いてサフィックスを変更する。
https://learn.microsoft.com/ja-jp/microsoft-365/enterprise/prepare-a-non-routable-domain-for-directory-synchronization?view=o365-worldwide

しかしオンプレミス側の UPN 変更に伴い Kerberos 認証に影響を与える可能性を考慮し、代替ログインID (UPN以外の属性) で Entra ID と同期するパターンも存在しています。
公式ドキュメントから引用するなら、いまは下記３パターンがあります。

https://learn.microsoft.com/ja-jp/entra/identity/authentication/howto-authentication-use-email-signin#overview-of-alternate-login-id-options

  1. AD FS の代替ログイン ID
  2. Microsoft Entra Connect の代替ログイン ID
  3. 代替ログイン ID としてのメール アドレス

ただし上記 “2”, “3” の構成は Hybrid Entra Join に非対応 (PRTが取得できない) だったり、プレビューであったり、別の課題が生じてしまうため、あまりおすすめはできません。

https://jpazureid.github.io/blog/azure-active-directory/haadj-and-upn/

この記事では “1” のパターンで、オンプレミスにある .local を維持したまま、Entra ID と連携するための手順についてザッとメモしています、

目的

  • 非ルートドメイン .local で構築された Active Directory ドメインを ADFS を用いて Entra ID / 代替ID によるサインインを行いたい。

構築・検証手順

  • 検証は Azure 上で実施しています (Windows Server は適宜日本語化)
  • 本番環境を想定するのであれば L/B, ADFS, WAP, etc… などの構成がありますが、下記では AD, ADFS 1台ずつの構成で内部からの認証で試しています。
  • 参考 : 公式ドキュメントの全体構成例

    オンプレミスの AD FS を Azure に拡張する
    https://learn.microsoft.com/ja-jp/azure/architecture/reference-architectures/identity/adfs

事前に準備しておく情報

  • Active Directory ドメイン名 : hogehoge.local　※適当な非ルートドメイン
  • ADFS/WAP で利用する FQDN : (内部/外部のDNSで解決可能な FQDN、example.com など)

1. Active Directory ドメインの構成

  • 前提条件
    • Azure 上に Windows Server 2022 にて構成
    • ドメイン名 : hogehoge.local　※非ルートドメインを指定して作成
  • Active Directory 構成後、Azure VM / NIC の内部IPを静的にしています。
  • Active Directory の構築手順については、ネット上に沢山の情報があるのでそちらを参照してください。
    https://www.server-world.info/query?os=Windows_Server_2025&p=active_directory

2. Microsoft 365 テナントの準備

  • 適宜 Microsoft 365 テナントを用意します。
  • 用意したテナントには、カスタムドメインとして事前に準備していた FQDN を登録まで完了させます。

https://learn.microsoft.com/ja-jp/microsoft-365/admin/setup/add-domain?view=o365-worldwide

3. Active Directory Federation Services の構築

https://learn.microsoft.com/ja-jp/windows-server/identity/ad-fs/deployment/configure-a-federation-server

  • 前提条件
    • 前述の通り本番想定で構成する場合には、冗長化のためにロードバランサ等の導入を検討する必要があるが、今回は除いている (ADFS/WAP 1台構成)
    • 構築対象として Azure VM デプロイ後、NIC の内部IPを静的に。 かつ DNS の向き先を 事前に構成した AD に向けている。
  • 事前準備
    • TLS/SSL 証明書の準備
    • 内部DNS へのドメイン登録
      • ADFS (および WAP) は、内外から解決可能な FQDN で構成する必要があります。例えば内部から認証する場合 sts.example.com は 内部IP (例: 10.x.x.x) 、外部からアクセスする場合は DMZ に置いた WAP の 外部IP (グローバルIP) で向ける事で、内部からは ADFS 、外部からは WAP 経由でそれぞれ認証画面にたどり着く事になります。
      • 今回は ADFS 単体で環境を立てているので、ADと同居しているDNSサービスに以下の手順でドメインを登録しました。
        1. Active Directory / DNS の前⽅参照ゾーンに、Microsoft 365 に登録した FQDN のゾーンを作成 (例: example.com)
        2. 次に内外からアクセスするための FQDN (例: sts.example.com) 、IPアドレスは ADFS として構成するサーバの プライベートIP を指定
    • Enable-PSRemoting の有効化
      • 後の工程で必要となるが、Windows Server 2016 以降 ADFS 導入後ではアクセスが拒否されるようになったので、必ず事前に行う。
        Enable-PSRemoting
  • 構築手順
    • Active Directory Federation Services の構築手順については、ネット上に沢山の情報があるのでそちらを参照してください。

4. フェデレーション構成

https://learn.microsoft.com/ja-jp/microsoft-365/troubleshoot/active-directory/set-up-adfs-for-single-sign-on

  • ADFS上の PowerShell を利用して Microsoft 365 とのフェデレーションを構成します。
    [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Install-Module MSOnline
Import-Module MSOnline
Connect-MsolService
Set-MsolADFSContext –computer <ADFSのコンピューター名)
Convert-MsolDomainToFederated -DomainName <Microsoft 365 に登録したドメイン名>
  • 実行後は Entra 管理センターのドメインのところでも フェデレーション が有効になった事がわかります。

5. ADドメインユーザの作成

  • 今回は非ルートドメインのユーザをフェデレーション認証にする・・・という事が目的なので、AD側でテストユーザを幾つか作成しておく。
  • イメージとしてはよくある 社員番号@hogehoge.local を想定
    例 : 123456780@hogehoge.local, 123456781@hogehoge.local, 123456782@hogehoge.local
  • 各ユーザのメールアドレスに Entra ID で利用させたい ID を記述 (例: user01@example.com など)、これが Entra ID 側での UPN になる想定

6. 代替ログインID の設定

https://learn.microsoft.com/ja-jp/windows-server/identity/ad-fs/operations/configuring-alternate-login-id

  • ADFS にて代替ログインID を “mail属性” に設定する。
Get-AdfsClaimsProviderTrust
Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID mail -LookupForests <FQDN、例: hogehoge.local>

7. Active Directory / UPNサフィックスの追加

  • Entra Connect 構成時に UPNサフィックスがないとドメインを確認するところでコケるので UPNサフィックスを追加する。
  • Active Directory ドメインと信頼関係 → プロパティ → UPNサフィックスとして、Microsoft 365 に登録したカスタムドメインを追加

8. Entra Connect 構成

  • 前提条件
    • ADFS でフェデレーションをする場合は、ID の同期だけでも動作はするが、一旦パスワードハッシュ同期で構成しています。
    • Entra Connect は本来は Active Directory と別の Windows Server で立てる事が推奨されますが、今回は手抜きして AD と同じ VM に入れています。
  • 構築
    • Entra Connect 構成時には UPN 名に “mail” 属性を選択して同期
    • Hybrid Entra Join の構成
      • Entra Connect のデバイス構成の設定を変えて、Hybrid Entra Join も有効にしておく

同期結果の確認、オンプレミス Active Directory 上では 社員番号@hogege.local だか、Entra ID 上では Mail属性 を元に user01@example.com 的なIDで作成されている。

9. Windows 11 Client の準備とドメイン参加

  • Windows 11 を用意して、ドメインに参加した状態にする。
  • Edge ブラウザを起動するなり、Office.com に開いてサインインする画面を開くと ADFS にリダイレクトされ認証される事がわかる。
  • サインインをしたユーザで “dsregcmd /status” を実行する事で以下の事がわかる。
    • “AzureAdJoined” と “DomainJoined” が Yes になり Hybrid Entra Join が出来ている。
    • .local ユーザのまま PRT 取得まで出来ている事 (AzureAdPrt : YES) がわかる。

参考情報・備忘メモ

大まかな認証フロー

こんなイメージ、ADFS認証後は "Mail属性" でトークンを戻す = Entra ID 側で NameID が UPN と一致 → 同一ユーザと判断し、Hybrid Join 完了し、PRT も受け取れる。

以下の記事も参照するとイメージしやすいかも？
https://qiita.com/okuda_y/items/4fc3111aadcf183059b0

UserPrincipalName (UPN) と sAMAccountName

端的に述べると

  • UserPrincipalName (UPN)
    • Windows 2000 以降で導入された比較的新しい方の ログインID 形式
    • 例：xxxx@domain.com
    • 主に Kerberos 認証で利用される（Entra ID 連携時など、モダン環境で主として使用）
  • sAMAccountName
    • Windows Server 2000 より前の ログオンID 形式
    • 例：domain\xxxx（古くからある Windows の形式）
    • 過去の経緯から NTLM と共にに使われることが多かったが、Kerberos 認証も可能

UPN は Windows Server 2000 以降のユーザログインや、Entra ID との同期時に主となる ID として扱われる。 一方 sAMAccountName はログイン後の Profile フォルダ名などに使われるため、現状でも設計・構築時に影響を与える要素となっている。

どちらの形式でも Active Directory 上では同一の SID を持つ "同一ユーザ オブジェクトの別名" として扱われるため「UPN を使う場合」「sAMAccountName を使う場合」という形で新旧の棲み分けが行われているイメージ (で合っていると・・・と思う・・・)

下記の記事も参考にしてください。
https://engineeroutput.com/adのユーザプリンシパル名upnとsamaaccountnameについて/

Discussion