以下ドキュメントを参考にAzure上に環境を構築。最近物忘れが多いためMyメモのために。。
https://auth0.com/docs/connector
環境
手元のAzure IaaS上に以下の環境を用意・構築
- Windows Server 2台
1台目：Active DirectoryとAuth0のActive Directory/LDAP Connectorを兼用
2代目：冗長化の確認も検証したかったのでこれはActive Directory/LDAP Connector専用 - Windows Client
Windows 10 Pro（1809） - Azureロードバランサー （Internal Load Balancer）
WIAを利用する際の冗長化のためにいるっぽいので利用(WIAが不要であればAuth0側が生きてる方のサーバでよろしく処理してくれるようです。)
[参考URL] https://auth0.com/docs/connector/high-availability
今回は検証用に以下の構成を組みました。Windows統合認証の確認をしたかったのでAD Connectorのサーバはドメインのメンバーサーバにしています。（ドメイン不参加で確認したときは美味くいかなったので。。どっかでドキュメントも見たような記憶が）
設定・インストール
左メニューから「Connections」ー「Enterprise」ー「Active Directory/LDAP」から「＋」の「Create New」から作成
作成するとモジュールのダウンロード画面とWindows上でインストール後にAuth0と接続するために必要になる「TICKET URL」が表示されます。「TICKET URL」はコピペでメモってください。
ついでに対象アプリケーションも選択しときます。キャプチャは一杯ありますが、気にしないでください。
では、次にWindows環境（上の構成図のAD Connector #1想定）へモジュールのインストールですが、ここのURL https://auth0.com/docs/connector/install 通りで問題ないかと思います。インストール後に先程メモって貰った「TIKET URL」を入れれば設定画面へが表示されていきます。
私の設定画面はこんな感じでにしてます。パスワードライトバックも検証したいので、「Enable Write Back」「Enable Unicode Password」のチェックをしています。
設定が完了したら上メニューの「Search」で検索してみましょう。
私のAD構成はこんな感じで、auth0.ad001 というユーザを検索してみます。
テキストボックスにsAMAccountNameを入力して「Search」すると無事取得できましたね。
可用性のために2代目のサーバ（AD Connector #2）にもインストール
このサイト https://auth0.com/docs/connector/high-availability の通り実施したらいいのですが、２台目への設定する際に私、最初上部メニューからコンフィグファイルをExportしてImportしたところImportでエラーになりました。ちゃんとマニュアル通りしないと駄目ですねｗｗ
話を戻すと、Exportするとマニュアルに書いてある "C:\Program Files (x86)\Auth0\AD LDAP Connector"にある必要なファイルだけ（cofig.json、lib\profileMapper.js、certs\以下のファイル）ZIPでダウンロードされますので、それを個別で#2号機に手動で置き換えてください。置き換えた後は、Auth0のサービスは再起動して下さいね。
最後は問題ないかどうか上メニューの「Troubleshooting」画面へ遷移して「Run」を実行します。（私は最初にやったとき何故かこの部分でAuth0サーバとの接続部分でエラーになってしまってました。）
冗長化の設定
https://auth0.com/docs/connector/high-availability#kerberos-or-certificate-based-authentication-considerations
の通りWIAの場合はクラウド上のAuth0サーバを経由せずに直接オンプレ上のAD Connectorへ接続するためにそれぞれのサーバーをロードバランサーを使い冗長化する必要があります。
上記でも記載していますがWindows統合認証を使わずにAuth0の認証画面経由だとロードバランサーは不要ってことになります。
今回はAzure Load Balancerにてサクッと構成しました。下の赤丸で囲んだURLをユーザからのエンドポイントにします。
内部DNSにロードバランサーのIP（172.23.248.20）は登録してAzure Load Balancerも適当に構築。。。ここはググったら出てくると思うので割愛します。
テスト
今回はSalesforceをSPとして用意して確認してみました。いざ、Windows10クライアントから接続！！
あれ？ポップアップでるやーーん！
設定見直し、、、Windows統合認証するときはクライアントから出て行くPublic IPの登録が必要らしい。https://auth0.com/docs/connector/kerberos#flow ここにも書いてましたね。ということで現在の外向きのアドレスを確認。
Azure上にデプロイしているのでWindows10のパブリックIPを確認。企業の場合は、当然複数あるのでカンマで区切ったら登録可能となってます。
Azure PortalのWindows10のVMからパブリックIPを確認（上記の52.148.81.211）してAD ConnectorのIP Rangeに追加。
改めてテスト。
今度はWindowsのポップアップ。ブラウザの設定でロードバランサーのURLを信頼済みサイトに追加します。
再度、テスト。今度は問題なくログイン。
次は外部ネットワークからの接続
想定通り、Auth0のログイン画面が表示されるのでADのIDとPWを入力します。
ふぅ、問題なくSalesforceへログインできました。。。。Auth0はカスタムでルールを記述すれば外部NWからのアクセスはブロックなど柔軟に対応出来ますので便利。
補足
マルチフォレストのドメイン構成の会社があったり部署毎にADがあったりする場合においてもAuth0は対応しているらしい。https://auth0.com/docs/connector/prerequisites#one-connector-per-auth0-tenant-connection の中段ぐらい「This is needed if you have multiple AD/LDAP directories against which users will authenticate,・・・」
私が確認したときには、ログイン画面で最初エラーでもう一度確認すると美味くいったりするときがありましたが、サブミットしたタイミングで参照にいくADが一つだったりするんですかね。この辺は時間があったタイミングでもっと深くやってみたいと思います。