AD CS篇
AD CS篇
简介
AD CS是微软免费的证书管理服务,用于微软的 PKI 实施,AD CS以角色服务的形式提供与PKI相关的所有组件,每个角色服务负责证书基础结构的特定部分
PKI是软件、加密技术、过程和服务的组合,可使组织保证其数据、通信与业务的安全。PKI依赖于经过身份验证的用户和受信任的资源之间的数字证书交换。可以使用证书来保证数据安全,并管理来自组织内外的用户和计算机的标识凭据
AD CS简单搭建
在实际环境中为了安全要独立部署ADCS,这里为了方便直接在域控上面部署
在添加角色功能里面选择AD证书服务

一直下一步到角色服务选择证书颁发机构web注册,可在http://CA-Computer/certsrv身份认证后进行证书申请

然后一直下一步,直接安装即可
开始进行服务配置


设置类型这里选择企业CA,独立CA通常是未加入域的

选择根CA

创建新私钥


一直默认下一步,然后点击配置
配置完可以看见证书颁发机构

IIS的Internet Information Services (IIS)管理器

然后可以在web端访问

AD CS 角色
AD CS角色包括下列角色服务:
证书颁发机构。CA主要用途是颁发证书、吊销证书,以及发布授权信息访问(AIA)和吊销信息。部署的第一个CA是内部PKI的根,接下来部署PKI层次结构的从属CA,并将根CA置于顶部,从属CA隐式信任根CA,隐含信任根CA颁发的证书。可以部署多个内部CA层次结构,每个层次结构都有自己的根
证书颁发机构web注册。此组件提供了一种颁发和续订证书的方法,适用于用户使用未加入域的设别或允许非Windows操作系统的情况
在线响应者。 可以使用此组件配置和管理在线证书状态协议 (OCSP) 验证和吊销检查。 在线响应者可解码对特定证书的吊销状态请求,评估这些证书的状态,并返回包含所请求证书状态信息的签名响应。
网络设备注册服务(NDES)。利用此组件,路由器、交换机和其他网络设备可以从 AD CS 获取证书
证书注册web服务(CES)。 此组件用作运行 Windows 的计算机与 CA 之间的代理客户端。 CES 使用户、计算机或应用程序能够通过使用 Web 服务连接到 CA:
请求、续订和安装已颁发的证书。
检索证书吊销列表 (CRL)。
下载根证书。
通过 Internet 注册或跨林注册。
为不受信任的 AD DS 域中的计算机或未加入域的计算机自动续订证书。
证书注册策略web服务。 此组件使用户能够获取证书注册策略信息。 与 CES 结合使用时,它可在用户设备未加入域或无法连接到域控制器的情况下实现基于策略的证书注册。
ADCS 服务架构
这是微软所给的两层PKI环境部署结构实例

ORCA1:首先使用本地管理员部署单机离线的根 CA,配置 AIA 及 CRL,导出根 CA 证书和 CRL 文件
由于根 CA 需要嵌入到所有验证证书的设备中,所以出于安全考虑,根 CA 通常与客户端之间做网络隔离或关机且不在域内,因为一旦根 CA 遭到管理员误操作或黑客攻击,需要替换所有嵌入设备中的根 CA 证书,成本极高。
为了验证由根 CA 颁发的证书,需要使 CRL 验证可用于所有端点,为此将在从属 CA (APP1) 上安装一个 Web 服务器来托管验证内容。根 CA 机器使用频率很低,仅当需要进行添加另一个从属/颁发 CA、更新 CA 或更改 CRL。
APP1:用于端点注册的从属 CA,通常完成以下关键配置
将根 CA 证书放入 Active Directory 的配置容器中,这样允许域客户端计算机自动信任根 CA 证书,不需要在组策略中分发该证书。
在离线 ORCA1上申请 APP1 的 CA 证书后,利用传输设备将根 CA 证书和 CRL文件放入 APP1 的本地存储中,使 APP1 对根 CA 证书和根 CA CRL 的迅速直接信任。
部署 Web Server 以分发证书和 CRL,设置 CDP 及 AIA。
AD CS的LDAP属性
这里使用AD Explorer
ADCS在LADP容器中定义了CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=的属性

Certificate templates(证书模板)
证书模板颁发首先需要在CA的certtmpl.msc进行配置,随后在certsrv.msc进行证书模板的发布
在扩展中证书模板对象的 EKU (pKIExtendedKeyUsage) 属性包含一个数组,其内容为模板中已启用的 OID (Object Identifiers),这些自定义应用程序策略 (EKU oid) 会影响证书的用途,比如这是Kerberos身份验证的OID


但是要以下 oid 的添加才可以让证书用于 Kerberos 身份认证,没有就新建
Client Authentication
1.3.6.1.5.5.7.3.2
PKINIT Client Authentication
1.3.6.1.5.2.3.4
Smart Card Logon
1.3.6.1.4.1.311.20.2.2
Any Purpose
2.5.29.37.0
SubCA
(no EKUs)

ADCS大部分利用在证书模板存储为CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=,其 objectClass 为 pKICertificateTemplate,以下为证书的字段
常规设置:证书的有效期
请求处理:证书的目的和导出私钥要求
加密:要使用的加密服务提供程序 (CSP) 和最小密钥大小
Extensions:要包含在证书中的 X509v3 扩展列表
主题名称:来自请求中用户提供的值,或来自请求证书的域主体身份
发布要求:是否需要“CA证书管理员”批准才能通过证书申请
安全描述符:证书模板的 ACL,包括拥有注册模板所需的扩展权限
Enterprise NTAuth store( 企业NTAuth存储 )
NtAuthCertificates 包含所有 CA 的证书列表,不在内的 CA 无法处理用户身份验证证书的申请
域内机器在注册表中有一份缓存:
当组策略开启“自动注册证书”,等组策略更新时才会更新本地缓存
Certification Authorities & AIA(证书颁发机构)
Certification Authorities 容器对应根 CA 的证书存储。当有新的颁发 CA 安装时,它的证书则会自动放到 AIA 容器中

来自他们容器的所有证书同样会作为组策略处理的一部分传播到每个网络连通的客户端,当同步出现问题的话 KDC 认证会抛 KDC_ERR_PADATA_TYPE_NOSUPP 报错
Certificate Revocation List(证书吊销列表)
证书吊销列表 (CRL) 是由颁发相应证书的 CA 发布的已吊销证书列表,将证书与 CRL 进行比较是确定证书是否有效的一种方法

通常证书由序列号标识,CRL 除了吊销证书的序列号之外还包含每个证书的吊销原因和证书被吊销的时间

证书注册流程

客户端创建公钥/私钥对;
将公钥与其他信息 (如证书的主题和证书模板名称) 一起放在证书签名请求 (CSR) 消息中,并使用私钥签署;
CA 首先判断用户是否允许进行证书申请,证书模板是否存在以及判断请求内容是否符合证书模板;
通过审核后,CA 生成含有客户端公钥的证书并使用自己的私钥来签署;
签署完的证书可以进行查看并使用。
证书注册方式
证书颁发机构web注册
部署CA时勾选证书颁发机构web注册,即可在http://CA-Computer/certsrv身份认证后进行证书申请

客户端GUI注册
域内机器可以使用certmgr.msc(用户证书),certlm.msc(计算机证书) GUI请求证书


命令行注册
域内机器可以通过certreq.exe或power shellGet-Certificate申请证书
DCOM调用
基于 DCOM 的证书注册遵循 MS-WCCE 协议进行证书请求,目前大多数 C#、python、Powershell的 ADCS 利用工具都按照 WCCE 进行证书请求
证书注册权限
在 Active Directory 中权限控制是基于访问控制模型的,其包含两个基本部分:
访问令牌,包含有关登录用户的信息
安全描述符,其中包含保护安全对象的安全信息

在 ADCS 中使用两种安全性定义注册权限 (主体可以请求证书) ,一个在证书模板 AD 对象上,另一个在企业 CA 本身上
在颁发CA上使用certtmpl.msc课查看所有证书模板,通过安全扩展可以对证书模板用户访问权限进行查看

可在颁发CA上使用certsrv.msc,在属性里查看CA对于用户的访问权限设置

证书认证
Kerberos的PKINIT
在 RFC 4556 中定义了 PKINIT 为 Kerberos 的扩展协议,可通过 X.509 证书用来获取 Kerberos 票据 (TGT)
PKINIT 与 Kerberos 差别主要在 AS 阶段:
PKINIT AS_REQ:发d送内容包含证书,私钥进行签名。KDC 使用公钥对数字签名进行校验,确认后返回使用证书公钥加密的 TGT 并且消息是使用 KDC 私钥签名;
PKINIT AS_REP:客户端使用 KDC 公钥进行签名校验,随后使用证书私钥解密成功拿到 TGT
利用Rebeus
NTLM凭据
当使用证书进行 PKCA 扩展协议认证的时候,返回的 PAC 中包含了 NTLM 票据
即使用户密码改了,通过证书随时可以拿到 NTLM。获取能用来进行 Kerberos 身份认证的证书需要满足一下几个条件:
证书模板OID
目前已知应用程序策略 (oid) 只有包含了 Client Authentication、PKINIT Client Authentication、Smart Card Logon、Any Purpose、SubCA 时,对应的证书才能充当 PKINIT 身份认证凭据。
没有可以新建

对应的oid:
Client Authentication
1.3.6.1.5.5.7.3.2
PKINIT Client Authentication
1.3.6.1.5.2.3.4
Smart Card Logon
1.3.6.1.4.1.311.20.2.2
Any Purpose
2.5.29.37.0
SubCA
(no EKUs)
证书请求权限
用户拥有向 CA 申请证书的权限;
用户拥有证书模板申请证书的权限。
证书获取
导出机器证书
通过 certlm.msc 图形化或 certutil.exe 进行证书导出

当私钥未设置为允许导出的时候,利用 Mimikatz 的 crypto::capi 命令可以 patch 当前进程中的 capi ,从而利用 Crypto APIs 导出含有私钥的证书



导出用户证书
通过 certmgr.msc 图形化或 certutil.exe 进行用户证书导出
同理遇到私钥限制可以使用mimikatz导出

证书查找
.pfx\ .p12\ .pkcs12
含公私钥,通常有密码保护
.pem
含有base64证书及私钥,可利用openssl格式转化
.key
只包含私钥
.crt\ .cer
只包含证书
.csr
证书签名请求文件,不含有公私钥
.jks\ .keystore\ .keys
可能含有 java 应用程序使用的证书和私钥
关键术语解释
根证书颁发机构 (Root Certification Authority)
证书基于信任链,安装的第一个颁发证书机构是根CA,是信任链的起始
从属CA (Subordinate CA)
是信任链的子节点,通常比根CA低一级
颁发 CA (Issuing CA) 颁发 CA 属于从属 CA,它向端点(例如用户、服务器和客户端)颁发证书,并非所有从属 CA 都需要颁发 CA
独立 CA (Standalone CA) 通常定义是在未加入域的服务器上运行的 CA
企业 CA (Enterprise CA) 通常定义是加入域并与 Active Directory 域服务集成的 CA
电子证书 (Digital Certificate) 用户身份的电子证明,由 Certificate Authority 发放(通常遵循X.509标准)
AIA (Authority Information Access) 权威信息访问 (AIA) 应用于 CA 颁发的证书,用于指向此证书颁发者所在的位置引导检查该证书的吊销情况
CDP (CRL Distribution Point) 包含有关 CRL 位置的信息,例如 URL (Web Server)或 LDAP 路径 (Active Directory)
CRL (Certificate Revocation List) CRL 是已被撤销的证书列表,客户端使用 CRL 来验证提供的证书是否有效
安全问题
证书模板滥用
访问权限配置错误
伪造证书
参考
https://blog.noah.360.net/active-directory-certificate-services-attack-and-exploit/
https://learn.microsoft.com/zh-cn/training/modules/implement-manage-active-directory-certificate-services/2-explore-fundamentals-of-pki-ad-cs
https://mp.weixin.qq.com/s/xPf_NYa1Bp4Fx2-qMsAEbA
Last updated