【AWS】ELBでWindows統合認証を通したい場合は「ALB」ではダメ！「NLB」にする必要があった

  • 2019年5月26日
  • 2021年1月23日
  • AWS
AWS

こんんちはますのです。ロードバランスって何？ラウンドロビン方式？？？何やる子なの？？
はい。こんな知識0の状態からELB触っております。
AWSって本当にすごいですね。初心者エンジニアでもロードバランサー作れてしまうのですから…。

今回ですが

「Windows統合認証を使っているシステムをロードバランサーで認証を成功させたいよ」

という依頼から対応したことをメモしていきます。

目次

今回の要件確認

  1. EC2インスタンス上にIISでWebサーバを2台構築している
  2. Webサーバへのアクセスは社内からのアクセスのみ
  3. 各WebサイトはWindows統合認証でアクセス制限を掛けている
  4. 可能であればSSL通信化を実施したい

EC2-ELB構成図

ロードバランサー：ALB/NLB/CLBのうち「Windows統合認証」をサポートしているのは【NLB】！

現在、ELB（Elastic Load Balancing）では3種類のロードバランサーが用意されています。

  • ALB（Application Load Balancer）
    HTTP トラフィックおよび HTTPS トラフィックの負荷分散に最適なロードバランサ。
    ALBにセキュリティグループを設定出来るため、ターゲットインスタンスとの通信においてアクセス制御も容易となる。
    スティッキーセッション時間の設定も可能であり、特に要件が無ければALBを推奨している。
  • NLB（Network Load Balancer）
    TCPトラフィックなどネットワーク系の負荷分散に最適なロードバランサです。
    NLBはIPアドレスが固定化されているため、Aレコードでの処理が可能となる。
    しかし、セキュリティグループの設定が出来ない点や、ターゲットインスタンスへ渡す情報がクライアントPCの情報となるため、行き帰りで通信が異なることがある。
  • CLB（Classic Load Balancer）
    複数のAmazon EC2インスタンスにおける基本的な負荷分散を行うのに最適なロードバランサです。
    2016年以前にELBと言われていた機能がCLBに値する。
    ALB/NLBと比べて利用料金が若干高くなるため、ALBを利用する人が多い印象。

今回の要件の肝である「Windows統合認証」を満たすためには、クライアントの接続情報をサーバまで保持する通信を確立する「NLB」が必須でした。
参考：https://netblaze.biz/windows-authentication-fails-with-aws-application-elb/

ALBやNLBではプロキシサーバみたいな動きをします。
ターゲットインスタンスへ接続情報を渡す際に、IPアドレスなどがALBとなります。

そのためWebサーバは「こっちで持っているユーザ情報と一致しない」状況となってしまいます。
仮に接続出来たとしても「ALBさんいらっしゃい」と全ユーザ共通で出てしまうのです。

ELBをAWS管理コンソールから作成する

  1. AWS管理コンソール＞EC2＞ロードバランシング：ロードバランサーをクリック
  2. 「ロードバランサーの作成」をクリック
  3. 今回の要件はNLB作成のため、NLBの「作成」ボタンをクリック
  4. 名前：任意の名称を設定
    スキーム：社内向けのWebサーバへ行うため「内部」を設定
  5. リスナー：NLBを選択した場合は「TCP」か「TLS」になります。
    ACMで証明書をまだ作っていないので、取り急ぎ「TCP」を設定しました。
  6. アベイラビリティゾーン：今回のロードバランスを行うインスタンスが作成されているAZを２つ指定します。
    ※１AZにつき最低１インスタンスの設定が必要です。
  7. タグ：てきとーでOK！
    私は名前でつけたものと同じで「internal-nlb」と自分がわかるものにしています。
  8. ターゲットグループ：名前も管理上わかりやすいものを設定。
    今回は「internal-nlb-tg」のように設定しています。
  9. ヘルスチェック：とりあえず初期値に設定。
    NLBの場合、接続できなくなるとすぐに別インスタンスへ切り替えるのでALBよりここはシビアに考えなくても良かったです。
  10. ターゲットの登録：ロードバランスの対象となるインスタンスを設定します。
    インスタンスを検索からインタンス名を検索し選択＞「登録済みに追加」をクリックして設定する
  11. 最後に、設定値の確認画面が表示されます。
    「ロードバランサーを正常に作成しました。」という画面になればロードバランサーの作成が完了となります。

作成したNLBのIPアドレスをDNSにAレコード登録する

先程の作成したNLBのDNS名を確認し、DNSへAレコード登録します。
せっかくNLBで固定IP設定したのでDNSへはCネームじゃなくてIPで登録しておきたいところ。
Mac端末とかで検証したらAレコードでうまくいくことが多々あったので、NLB設定時はAレコードでDNS設定したほうが良さそうでした。

  1. AWS管理コンソール＞EC2＞ロードバランシング：ロードバランサーをクリック
  2. 作成したロードバランサー名をクリック＞説明タブのDNS名をコピー
  3. コマンドプロンプト等で「nslookup」や「dig」コマンドでIPアドレスを確認する
  4. ３で確認したIPアドレスをDNSのAレコードへ設定し、アクセスが出来るか確認する

クライアントPC⇔ロードバランサー間をSSL通信にする

  1. AWS管理コンソール＞EC2＞ロードバランシング：ロードバランサーをクリック
  2. 作成したロードバランサー名をクリック＞リスナータブ＞リスナーの追加をクリック
  3. プロトコル：ポートで「TLS：443」を設定
  4. 転送先：現在設定しているターゲットグループを指定する
  5. セキュリティポリシー「ELBSecurityPolicy-TLS-1-1-2017-01」を選択
    ※セキュリティレベルが各々異なるため、自身の環境に良いものを選択することになります。

    参考：https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/create-https-listener.html

  6. デフォルトのSSL証明書：「ACMから」「（ACMで作成した証明書を選択）」を選択し保存する。
    ※IAMで証明書を作成出来る方はそちらからでもOK！お金がかかりますが、ACMで作成したほうが簡単だったので、わたしはこちらを選択。

ACM Private Certificate参考：https://dev.classmethod.jp/cloud/aws/tried-acm-private-certificate-authority/

これらの設定をすることで、「Windows統合認証」「https通信化」を行った状態でのロードバランシングが出来ました！！
ALBとNLBの違いについて細かな設定とかはありましたが、それはまた後ほど。

作成期間：調査〜検証〜構築まで…おおよそ2ヶ月

最新情報をチェックしよう！

AWSの最新記事