前回はWindowsの認証の仕組みやSAM(Security Account Manager)に関してご紹介しました(URL)。今回は、Active Directoryについて取り上げたいと思います。

まずは、Active Directoryのおさらいですが、アカウント、グループやコンピュータなどのリソースをドメインで一元管理できるディレクトリサービスを提供しており、グループポリシーを用いてこれらのリソースを管理することが可能です。また、認証基盤を提供しており、シングルサインオンによるリソースの活用ができることもポイントです。

Active Directoryでの認証に利用されているKerberos認証はTGT(Ticket Granting Ticket)やService Ticketと呼ばれる許可証のようなチケットを用いて利用者だけではなく、サーバ(Domain Controller DC)のなりすましなどが行えないような仕組みであると思います。

①AS-REQ
クライアントはアカウント名やホストアドレスなどを送付し、TGTを要求します。

②ERR-PREAUTH-REQUIRED
最初のAS-REQに対して、タイムスタンプを送付します。

③AS-REQ
クライアントはアカウント名やホストアドレスおよびアカウントのパスワードHashで暗号化したタイムスタンプを送付し、再度TGTを要求します。DCは保持しているパスワードHashを利用して正当なアカウントであることを確認します。これは事前認証と呼ばれており、Active Directoryの設定で無効化することも可能です。事前認証は、攻撃者がDCに対してダミーのAS-REQを送付し、取得したTGTに対してブルートフォースが行えるため、無効にするべきではないとされています。

④AS-REP
DCは、TGS(Ticket Granting Service)のパスワードHashを用いて生成したTGTをクライアントに送付します。TGSのパスワードは、具体的にはkrbtgtアカウントのパスワードになります。クライアントは今後このTGTを提示することで、認証済みであることを確認することができます。もし任意のTGTを取得できた場合、なりすましが可能となります。Pass the Ticketと呼ばれる攻撃手法では、任意のチケット(TGTまたは後述するService Ticket)を取得・生成することでなりすましを行います。Pass the Ticketについては、こちらでも記載していますで、ご参照いただければと思います。

⑤TGS-REQ
クライアントはActive Directoryのリソースにアクセスするために必要となるService Ticketを要求します。TGTを提示することで、認証が行われたアカウントであることが確認できます。

⑥TGS-REP
DCは、Active Directoryのリソースへアクセスする際に必要となるService Ticketを送付します。

Kerberos認証では、TGTの発行とService Ticketの発行という大きく2つのステップを経て行われます。また、既にお気づきの方もいるかと思いますが、パスワードのHashはタイムスタンプなどのデータの暗号化や復号化に用いていますが、パスワードやパスワードのHashは通信経路上に通常流れない仕組みとなっています。では、パスワードの変更はどうなるのかというと、kerberos(88/tcp,88/udp)ではなくkpassword(464/tcp,464/udp)で行われます。詳細についてはこちらをご参照ください。

ここまではActive Directoryでの認証(Kerberos)についてご紹介しましたが、Active Directoryではどのようにアカウントのパスワードが管理されているのかという点についてご紹介したいと思います。

Active Directoryで管理する情報は、%SystemRoot%\NTDS\ntds.ditに保存されています。ntds.ditはESE(Extensible Storage Engine)というフォーマットになっています。0x4～0x7にシグネチャである\xef\xcd\xab\x89となっているファイルで、細かいファイルフォーマットに関してはこちらを参照していただければと思います。

ESEでは、ATTm590045やATTm13といったカラム名にデータが格納されています。ATTm590045はSAMAccountNameが、ATTm13はDescriptionがユーザごとに保存されています。以下の方法でntds.ditからNTLM Hashを取得することが可能です。RIDが500であるAdministratorを例にしています。

今回はActive Directoryでの認証やパスワード管理についてご紹介しました。Kerberos認証はパスワードを通信経路上に流さないなどセキュアな認証方式であると言えますが、プロトコルとしてパスワードの推測やDoSに対する耐性があるというわけではないため、推測が困難なパスワードの利用であったり、アカウントロックの実装などセキュリティ施策は別途必要になります。

2回にわたりWindowsのパスワードや認証についてご紹介してきました。複雑なやりとりが多いのも、よりセキュアな仕組みを作り上げるために様々な試行錯誤の結果なのではないかと思いをはせながら行きつけの飲み屋へ飲みに行ってきます、テキーラを。

同僚の結婚祝いに頂いたテキーラ(ブログの内容と関係ありません)

＜参考＞
・https://social.technet.microsoft.com/wiki/contents/articles/23559.kerberos-pre-authentication-why-it-should-not-be-disabled.aspx
・https://tools.ietf.org/html/rfc1510#section-5.4.1