从‘三头狗’到‘云令牌’：手把手带你体验AD到AAD的身份验证协议变迁（含实战配置）

想象一下，你正在管理一家跨国企业的IT基础设施。十年前，员工们坐在办公室里，通过域控服务器完成身份验证；如今，他们可能在地球的另一端，用手机访问公司资源。这种转变背后，是身份验证技术从传统Active Directory（AD）到Azure Active Directory（AAD）的进化历程。本文将带你深入这个技术演进的底层世界，理解Kerberos、SAML、OAuth这些协议如何塑造了现代云身份验证的格局。

1. 传统AD的基石：Kerberos协议深度解析

Kerberos得名于希腊神话中的三头犬，这个比喻恰如其分——它需要用户、计算机和域控三方共同参与验证过程。让我们拆解这个"三头狗"的工作机制：

Kerberos票据流转的核心步骤：

1. AS_REQ/AS_REP：用户向认证服务器(AS)请求票据授予票据(TGT)
2. TGS_REQ/TGS_REP：使用TGT向票据授予服务(TGS)请求服务票据
3. AP_REQ/AP_REP：向应用服务器出示服务票据进行最终验证

关键点：Kerberos采用对称加密，域控(Key Distribution Center)掌握所有密钥

传统AD环境中的典型验证流程可以用以下代码模拟：

python复制# 模拟Kerberos验证流程
def kerberos_auth(user, password, service):
    # 第一步：获取TGT
    tgt = get_tgt_from_kdc(user, hash(password))
    
    # 第二步：获取服务票据
    service_ticket = get_service_ticket(tgt, service)
    
    # 第三步：服务验证
    return verify_service_ticket(service_ticket, service)

这种机制的优势在于：

• 无密码传输：认证过程中不直接传输密码
• 双向认证：服务也能验证域控的合法性
• 票据重用：减少频繁认证开销

但它的局限性也很明显：

• 严格时间同步