AD Certificates
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
証明書のSubjectはその所有者を示します。
Public Keyは、証明書を正当な所有者にリンクするために、プライベートキーとペアになっています。
Validity Periodは、NotBeforeおよびNotAfterの日付によって定義され、証明書の有効期間を示します。
一意のSerial Numberは、証明書を識別するために証明書発行機関（CA）によって提供されます。
Issuerは、証明書を発行したCAを指します。
SubjectAlternativeNameは、識別の柔軟性を高めるために、主題の追加名を許可します。
Basic Constraintsは、証明書がCA用かエンドエンティティ用かを識別し、使用制限を定義します。
**Extended Key Usages (EKUs)**は、オブジェクト識別子（OIDs）を通じて、コード署名やメール暗号化など、証明書の特定の目的を示します。
Signature Algorithmは、証明書に署名する方法を指定します。
Signatureは、発行者のプライベートキーで作成され、証明書の真正性を保証します。
**Subject Alternative Names (SANs)**は、証明書の適用範囲を複数のアイデンティティに拡張し、複数のドメインを持つサーバーにとって重要です。攻撃者がSAN仕様を操作することによる偽装リスクを避けるために、安全な発行プロセスが重要です。
AD CSは、指定されたコンテナを通じてADフォレスト内のCA証明書を認識し、それぞれが独自の役割を果たします：
Certification Authoritiesコンテナは、信頼されたルートCA証明書を保持します。
Enrolment Servicesコンテナは、エンタープライズCAとその証明書テンプレートの詳細を示します。
NTAuthCertificatesオブジェクトは、AD認証のために承認されたCA証明書を含みます。
**AIA (Authority Information Access)**コンテナは、中間CAおよびクロスCA証明書を使用して証明書チェーンの検証を促進します。
リクエストプロセスは、クライアントがエンタープライズCAを見つけることから始まります。
公開鍵とその他の詳細を含むCSRが生成され、公開-プライベートキーのペアが作成された後に作成されます。
CAは、利用可能な証明書テンプレートに対してCSRを評価し、テンプレートの権限に基づいて証明書を発行します。
承認されると、CAはプライベートキーで証明書に署名し、クライアントに返します。
AD内で定義されているこれらのテンプレートは、証明書を発行するための設定と権限を概説し、許可されたEKUや登録または変更権限を含み、証明書サービスへのアクセス管理において重要です。
証明書の登録プロセスは、管理者が証明書テンプレートを作成し、それがエンタープライズ証明書発行機関（CA）によって公開されることから始まります。これにより、クライアントの登録のためにテンプレートが利用可能になります。このステップは、テンプレートの名前をActive Directoryオブジェクトのcertificatetemplatesフィールドに追加することで達成されます。
クライアントが証明書をリクエストするには、登録権限が付与されている必要があります。これらの権限は、証明書テンプレートおよびエンタープライズCA自体のセキュリティ記述子によって定義されます。リクエストが成功するためには、両方の場所で権限が付与される必要があります。
これらの権限は、アクセス制御エントリ（ACE）を通じて指定され、次のような権限が詳細に示されます：
Certificate-EnrollmentおよびCertificate-AutoEnrollment権限は、それぞれ特定のGUIDに関連付けられています。
ExtendedRightsは、すべての拡張権限を許可します。
FullControl/GenericAllは、テンプレートに対する完全な制御を提供します。
CAの権限は、そのセキュリティ記述子に記載されており、証明書発行機関管理コンソールを介してアクセス可能です。一部の設定では、低権限のユーザーにリモートアクセスを許可することもあり、これはセキュリティ上の懸念となる可能性があります。
特定の制御が適用される場合があります。たとえば：
Manager Approval: リクエストを保留状態にし、証明書マネージャーによる承認を待ちます。
Enrolment Agents and Authorized Signatures: CSRに必要な署名の数と必要なアプリケーションポリシーOIDを指定します。
証明書は次の方法でリクエストできます：
Windows Client Certificate Enrollment Protocol (MS-WCCE)、DCOMインターフェースを使用。
ICertPassage Remote Protocol (MS-ICPR)、名前付きパイプまたはTCP/IPを介して。
証明書登録ウェブインターフェース、証明書発行機関ウェブ登録役割がインストールされていること。
Certificate Enrollment Service (CES)、証明書登録ポリシー（CEP）サービスと連携。
Network Device Enrollment Service (NDES)は、ネットワークデバイス用に、シンプル証明書登録プロトコル（SCEP）を使用します。
Windowsユーザーは、GUI（certmgr.mscまたはcertlm.msc）またはコマンドラインツール（certreq.exeまたはPowerShellのGet-Certificateコマンド）を介しても証明書をリクエストできます。
Active Directory (AD) は、主に Kerberos と Secure Channel (Schannel) プロトコルを利用して証明書認証をサポートしています。
Kerberos 認証プロセスでは、ユーザーのチケット授与チケット (TGT) の要求がユーザーの証明書の 秘密鍵 を使用して署名されます。この要求は、ドメインコントローラーによって、証明書の 有効性、パス、および 失効状況 を含むいくつかの検証を受けます。検証には、証明書が信頼できるソースからのものであることの確認や、発行者が NTAUTH 証明書ストア に存在することの確認も含まれます。検証が成功すると、TGT が発行されます。AD の NTAuthCertificates オブジェクトは、次の場所にあります:
is central to establishing trust for certificate authentication.
Schannelは、安全なTLS/SSL接続を促進します。ハンドシェイク中に、クライアントは証明書を提示し、成功裏に検証されればアクセスが許可されます。証明書をADアカウントにマッピングするには、KerberosのS4U2Self機能や証明書の**Subject Alternative Name (SAN)**など、他の方法が関与する場合があります。
ADの証明書サービスは、LDAPクエリを通じて列挙でき、**Enterprise Certificate Authorities (CAs)およびその構成に関する情報を明らかにします。これは、特別な権限なしにドメイン認証されたユーザーによってアクセス可能です。CertifyやCertipy**のようなツールは、AD CS環境での列挙と脆弱性評価に使用されます。
これらのツールを使用するためのコマンドには次のものが含まれます:
AWSハッキングを学び、練習する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、練習する：HackTricks Training GCP Red Team Expert (GRTE)
