Jamf Pro + Azure AD Application Proxy でオンプレADCSからクライアント証明書を発行してみた

こんにちは。某グループウェアの会社で情シスをやっている[あおてつ](https://twitter.com/ao_Tetsu)です。
この記事は[corp-engr 情シスSlack（コーポレートエンジニア x 情シス）#3 Advent Calendar 2020](https://adventar.org/calendars/5605) 15日目の記事です。

# はじめに
オンプレ環境に構成した認証局（Active Directory証明書サービス：以下 ADCS）からクライアント証明書を発行して、社内の無線LANに接続したり、VPNに接続するのはよくある運用だと思います。Windows PCであればADドメインに参加すれば比較的簡単に実現可能ですが、Appleデバイス（Mac）の場合はWindowsのようにできないためMDMを使うなど一工夫必要です。

Apple製品のデバイス管理サービス（MDM）として最もメジャーなJamf Proを使ってオンプレADCSからクライアント証明書をAppleデバイスへ配布したい場合、Jamf社が提供しているADCS Connectorを使うのが最も正攻法な構成です。
ただこの場合、外部からInternalセグメントへInbound方向へTCP/443ポートの通信を許可する必要があります。![Screenshot_5-2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140000/17c9e3a5-5a91-61fb-43fa-111d69ec395c.png)
参考：https://travellingtechguy.blog/jamf-adcs-connector/

ADCS ConnectorをDMZに配置しても良いのですが、企業によっては社内システム向けのDMZがなかったり、外部からInternalセグメントへのInbound方向の通信はFWのポート開放が許可できない場合もあると思います。
では、そんなときどうればよいのか。そんな場合でも解決方法があります。

## Azure AD Application Proxy
Azure AD Application Proxy(以下、AAD App Proxy)は一言で言うとAzureAD版のリバースプロキシサービスで、これを使うとVPNを使ったり、FWのポートを開けなくても社外からオンプレミスのWebアプリケーションにアクセスできるようになります。これは便利！
Azure AD Application Proxyについては[こちらの記事](https://azuread.net/2020/08/05/azure-ad-app-proxy1/)が詳しいので合わせて参照してください。

> 注）AAD App Proxyを利用するためには Azure AD P1以上のライセンスが必要です。

## Azure AD Application Proxy + Jamf ADCS Connector
ということで、AAD App ProxyとADCS Connectorを使えばもうすぐにやりたいことが実現できそうですが、実は落とし穴がありました。Jamf ADCS Connectorは構成上デバイスと通信する際にクライアント証明書が必要になります。
（公式ガイド ： https://docs.jamf.com/technical-papers/jamf-pro/integrating-ad-cs/10.6.0/Install_the_Jamf_AD_CS_Connector.html ）
が、なんと AAD App Proxyの方がクライアント証明書を利用する通信に対応していなかったのでした。。。

[Active Directory (Azure AD) アプリケーション プロキシに関してよく寄せられる質問](https://docs.microsoft.com/ja-jp/azure/active-directory/manage-apps/application-proxy-faq#can-i-publish-a-web-application-with-client-certificate-authentication-requirement) より
> <B><font color="black">クライアント証明書の認証要件が設定されている Web アプリケーションを公開できますか。</font></B>
> いいえ。アプリケーション プロキシは TLS トラフィックを終了するため、このシナリオはサポートされていません。


ということで、残念ながらADCS Connectorは使えないことがわかったので、次の方法を考えます。

## Azure AD Application Proxy + SCEP（NDES）
Jamf ProはSCEP（Simple Certificate Enrollment Protocol）にも対応しています。SCEP は、各証明書の発行で管理者による入力や承認を要求することなく、多数のデバイスにクライアント証明書を登録するプロセスを簡略化するIETFプロトコルです。
そして、ADCS環境でSCEPを使うためにはネットワーク デバイス登録サービス(NDES)を利用します。

ということで、AAD App Proxy ＋ NDES ＋ Jamf Pro で構成してみます。

# Step1. NDESを構成する
まずはNDESから構成します。ざっくりとしたNDESの構成の流れは以下のとおりです。
1. NDESサービスアカウントの作成
2. SCEP証明書テンプレートの作成
3. Windows ServerでNDESサービスのインストール＆構成を行う

本記事では細かい手順の記載は割愛しますが（後日時間があるときに詳細手順を記載します）、IntuneでSCEP（NDESサーバ）を構成する際のMicrosoftのドキュメントが参考になります。
https://docs.microsoft.com/ja-jp/mem/intune/protect/certificates-scep-configure

ローカル環境で
　　　*https\://localhosot_name/certsrv/mscep/mscep.dll*
にアクセスして以下のような画面になればひとまずNDESサーバの構成はOKです。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140000/788cac34-adfe-dc09-42cf-555937e687a5.png">

# Step2. Azure AD Application Proxy を構成する
次に AAD App Proxyを構成します。
これもMicrosoftのオフィシャルドキュメントが参考になります。

[ネットワーク デバイス登録サービス (NDES) サーバー上の Azure AD アプリケーション プロキシとの統合](https://docs.microsoft.com/ja-jp/azure/active-directory/manage-apps/active-directory-app-proxy-protect-ndes)

ほぼこのドキュメントの通り進めれば構成できます。

Azure Active Directory管理センターから
　**エンタープライズアプリケーション ＞ 新しいアプリケーション ＞ 独自のアプリケーション**
を開き

　**「オンプレミスのアプリケーションへのセキュリティで保護されたリモート アクセス用のアプリケーション プロキシを構成します」**
を選択して「作成」へ進みます。
![スクリーンショット 2020-12-15 1.08.30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140000/1e4ad475-4f57-ce75-cc78-3205fb18eb9c.png)

続いての設定画面で
**・名前：**アプリケーションの名前を任意で設定します
**・内部URL：**ローカルネットワーク環境内でのURLを記載します。
**・外部URL：**サブドメインは任意で、ドメイン名はデフォルトの「\*.msappproxy.net」、もしくはそのテナントで管理しているドメイン名が利用可能です。
**・事前認証：**「パススルー」を指定します。
**・コネクタグループ：**任意のコネクタグループを指定できますが、「Default」のままでも問題ありません。
残りの「追加設定」はすべてデフォルト値のままで問題ありません。
![スクリーンショット 2020-12-15 0.58.46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140000/f32f2995-f216-092d-fff4-cc368a5b43ef.png)

構成が完了して AAD App Proxy で発行したURL
　　　***https\://xxxxx.msappproxy.net/certsrv/mscep/mscep.dll***
にアクセスしてNDESのページが表示されればOKです。

><font color="Black"><B>！ワンポイントメモ！</B></font>
1つのNDESサーバに設定できる証明書テンプレートは１つだけです。この構成で複数の種類のテンプレートの証明書を発行したい場合は、テンプレートの数だけNDESサーバとAAD App Proxy（外部URL)を構成する必要があります。少し面倒ですね。。。

# Step3. Jamf Pro で SCEPを構成する
次にJamf Proの構成プロファイルでSCEPを設定します。
　**構成プロファイル ＞ SCEP**
より以下を設定していきます。

**・URL：**AAD App Proxyで構成したNDESサーバの外部URLを設定します。
**・名称：**任意のCAの名前を設定します。
**・プロファイル再配布：**証明書の有効期限が近づいたときに自動的に証明書を再発行する場合は、期限前日数を設定します。
**・件名：**任意のサブジェクトを設定します。
　例えば、コモンネームにシリアル番号を設定したい場合は **CN=$SERIALNUMBER** で設定可能です。
**・件名の別名タイプ：**特に指定がなけえれば「None」のままでOKです。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140000/8f25e45d-801e-9aa7-2aa2-e148451baaa2.png">

**・チャレンジタイプ：** 「Dynamic-Microsoft CA」を設定します。
**・SCEP管理者のURL：** AAD App Proxyを経由したNDESサーバ管理者URLを設定します。
　*例）https\://xxxxx.msappproxy.net/certsrv/mscep_admin/*
**・ユーザ名：**NDESサービスアカウントのユーザ名を設定します。
**・パスワード：**NDESサービスアカウントのパスワードを設定します。
**・パスワード検証：**NDESサービスアカウントのパスワードを再入力します。
**・再試行：**任意の再試行回数を設定します。デフォルトの0のままでも問題ありません。
**・再試行遅延：**任意の再試行回数を設定します。デフォルトの0秒のままでも問題ありません。
<img Src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140000/aa8147aa-b3fa-2ab4-7894-259c0fc2c689.png">

**・証明書の有効期限通知のしきい値：**任意の日数で設定します。
**・キーサイズ：**発行する証明書のビットサイズを設定します。
**・デジタル署名として使用：**必要に応じてチェックを入れます。
**・キーの暗号化に使用：**必要に応じてチェックを入れます。
**・キーチェーンからの export を許可：**必要に応じてチェックを入れます。
**・すべてのAppにアクセスを許可：**特に証明書の使用の制限が必要ない限りチェックを入れていたほうが無難です。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140000/eb28a932-adf4-608d-8626-267b33d83d46.png">

あとはいつものようにプロファイル名やScopeを設定して保存すれば完了です。

#### [Appendix]このクライアント証明書を利用して、無線LANに接続する場合
発行したクライアント証明書を利用して、無線LANに接続する場合はこの構成プロファイルで一緒に設定すると良いです。

ネットワークペイロードで任意のセキュリティタイプを設定し必要なセキュリティタイプを選択します。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140000/4da6d532-ba3c-7f79-c0b9-f8c4adae592c.png">

必要なプロトコルを選択します。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140000/1ace4a33-aaaf-0811-dca3-abc1d2c05ad1.png">

ID証明書ではSCEPペイロードでで設定したSCEPを選択します。
![スクリーンショット 2020-12-14 20.55.43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140000/063f3040-23e1-08c0-a7e6-dd4392c9fd7d.png)

これでクライアント証明書を利用した無線LANへ接続ができるようになります。

# デバイスへクライアント証明書が配布されたか確認
ここまでの設定、構成に問題がなければデバイスへ構成プロファイルがインストールされ、Jamfサーバ→AAD App Proxy→NDES→ADCS経由 でクライアント証明書が発行されるはずです。キーチェーンを開くと発行されたクライアント証明書がインストールされていることが確認できます。
下図の例ではデバイスのコンピュータ名をコモンネームに設定（CN=$COMPUTERNAME）したクライアント証明書を発行してみました。
![スクリーンショット 2020-12-15 2.15.13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140000/07d311bc-8bcd-4d45-4a93-9ca655679099.png)

# まとめ
デバイスをMDMで管理するならば、クライアント証明書もインターネット経由で発行できるPKIサービスを利用するのがベターです。が、なんらかの理由でオンプレ認証局の運用を続けなければならない場合（しかもFWでInbound方向へのポート開放ができない場合）は本記事にような構成でも実現できるので、必要な方への参考になれば幸いです。

でもオンプレ依存はできるだけ脱却したいですね。。。