オンプレでの ADFS 構築

# 概要

今の時代にADFSをオンプレミスに構築してSAML WebSSOを実現する際の個人的なメモです。
基本的にリンク集です。

# 基本的な情報

MVPの方々が十分すぎる情報をまとめてくれていますので、通常はこれを読めば十分です。

https://www.vwnet.jp/Windows/etc.asp

https://azuread.net/category/adfs/

## 初期構築

ここに Dropbox向け構築手順がありますが、前半部分の手順は他システムでも同じです。

https://www.vwnet.jp/Windows/WS12R2/2017100501/Dropbox.htm

Windows Server 2019 の場合、ここに書いてある手順も必要です。

https://www.vwnet.jp/Windows/WS19/2019043001/WS19ADFS.htm

## Webサイト接続

Dropboxにつなぐ際は上記の手順で問題ありませんが、その他サイトにつなぐ場合は以下の通り設定します。

IdP SSO Endpoint: https://your-FQDN/adfs/ls/
IdP Entity ID: http://your-FQDN/adfs/services/trust

これらの情報はメタデータに書いてあります。

https://your-FQDN/FederationMetadata/2007-06/FederationMetadata.xml

signing certificateを指定する必要がありますが、その場合、ADFS コンソールで `AD FS > Service > Certificates` から `Token-Signing` の証明書をダウンロードしてください。
多くのサイトではSAML SubjectにNameIDを受け取る仕様のようですので、Relying Party Trustを作成したときにClaim Issuance Policyで必要な情報が渡されるよう設定してください。

## SSL 証明書の作成

自前でSSL証明書を作る場合は、ここの情報が参考になります。

https://www.vwnet.jp/Windows/WS16/2017092701/Certreq.htm

が、CSRを作る際のINFについていくつか注意が必要です。
~~まず、上記リンク先に記載のINFの情報に加え、以下をINFに追記する必要があります。~~
確認したところCertificateTemplateの記載は必須ではありませんでした。(2021/5/5追記)

```
[RequestAttributes]
CertificateTemplate = WebServer
```

また、ChromeはSANが設定されていないと、証明書が偽装されていると認識するようですので、SANの設定が必要です。(警告が表示されますが、気にしなければ使えます)

```
[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=my.domain.name.com&"
_continue_ = "dns=*.another.domain.com"
```

当然ですが、内容は環境にあわせたDNSエントリの内容に変更してください。

オレオレ証明書ではなく、然るべきCAから証明書を取得する場合は、INFの記載に制約がある場合もあるようです。
いろいろと検索してみると、INF中のRequestTypeにCMCを使っている事例もあるようですが、私が利用したCAではPKCS10でないと受け付けてもらえませんでした。

## PC側設定

Windows統合認証のためにはADFSがイントラネットゾーンにある必要がありますので、インターネットオプションから設定しておいてください。
また、自前でSSL証明書を作った場合は、CAルートの証明書を信頼済みとしてPCにインストールしておいてください。

```
> certutil -addstore root your-certificate.cer
```




# How To いろいろ

## 証明書更新

https://jpazureid.github.io/blog/active-directory-federation-service/update-ssl-server-certificate/

ローカルストアに証明書を保存して、それをADFSのコンソールから選択する手順です。

## FQDN 変更

ADFS コンソールで `AD FS > Service` で `Edit Federation Service Properties` から、FQDNを変更。
その後、FQDNにあった証明書をインストール（上記、証明書更新手順）すれば完了します。

## 複数ドメインでの認証

簡単にはできないと思われます。
方法としては、ADFSのドメインとTwo-way trustを設定すると、信頼先でもSSOが可能になります。One-way trustでは動作しません。One-wayだとSP側(Relying Party側)にリダイレクトされて一見うまくいった感じがしますが、NameIDなどの情報が渡りません。Two-Way trustを使った場合のネットワークフローはこちらに記載しました。

https://qiita.com/HishiM/items/b955f1b18f699e95dd9a

あとは、両ドメインでADFSを導入してFederation Trustで実現できます。この場合、通常はADがClaim Providerでしたが、ADFSをClaim Providerにすることになります（もう一方はRelying Partyになります）。手順はこちらにある手順でできます。

https://qiita.com/magpie310/items/41af8f66abb9fa594524

この手順はちょっと難しいことをやっているのである程度複雑な設定になっていますが、NameIDだけを連携するだけであれば設定は簡単です。


## Chrome での SSO

PowerShellで設定すればできます。

https://docs.microsoft.com/ja-jp/windows-server/identity/ad-fs/operations/configure-intranet-forms-based-authentication-for-devices-that-do-not-support-wia

https://hi.service-now.com/kb_view.do?sysparm_article=KB0759249

Microsoftとしては、Internet ExplorerだけがWindows統合認証可能なブラウザという立ち位置のようです。

## なぜか動かない場合

ChromeのDeveloper Toolで送受信の内容を確認して、怪しいところを探してください。
こんな便利なツールがあります。

https://www.samltool.com/

英語がそれなりに分かる方でしたら、(いろいろと制約もあるでしょうが)英語版で構築する方が何かと便利です。
エラーメッセージなどをGoogleで検索するにしても、英語の方が情報が多いです。また、個人的にはADFSの日本語訳が？です。証明書利用者信頼、とか。