Office 365身份认证--深度解析（一）

微软Office 365现在支持的认证方式，正准确的说是Azure Active Directory认证方式有下列两大块：
1.云端认证
a.纯云用户的云端认证（本文不讨论，因为也太多好讨论的）
b.密码哈希同步
c.PTA（放到这里是因为认证方式主要还是由AzureAD主导的，翻译过来为 传递身份验证，但是太冗长就用PTA代替）
2.联合身份认证
a.ADFS的联合身份认证
b.第三方的联合身份认证，比如ping federate

这里所有的认证方式都是基于域名的来做的，你可以到Portal.azure.com里的Azure AD去查看:

比如contoso.com域名的用户都是密码同步的，zotosoft.com的用户可以是联合身份认证的。凡是云端认证的方式都是通过Azure AD来完成身份的验证，凡是联盟身份认证的都是由联盟组织提供认证。
Azure用的协议一般都有：SMAL,OAuth,Open ID Connect等。

我们具体来一个方式一个方式的看：
1.密码哈希同步–Password Hash Sync:

这是微软最推荐的认证方式，从架构和部署上也是最简单，可用性最高的方式。（虽然早期并不受用户欢迎，大多数都采用联合身份认证的方式，最近开始流行起来了）
主要不选择的原因：
1.听上去就感觉不安全
2.由法律或其他规定不允许同步密码到云端

先谈一下架构：
简单来说只需要安装一个Azure AD Connect的软件就可以了，这个软件严格意义上不需要安装在单独的服务器上，虽然生产环境建议这么做。但是安装在任何一台可以访问你域控制器的机器上都可以运行，如果你考虑高可用，负载均衡当然就需要额外部署其他的服务器了。
配置：
选中需要同步的域/OU/组/用户，选择password hash sync然后点击配置，就可以了，非常简单。
认证流程：
先说一下大致流程，AADC把用户的密码哈希值同步到Azure AD里，用户登陆Office 365的时候输入密码，AzureAD检验转换后是否和哈希值一样，然后授权用户访问。

看一下常见的几个问题：
1.同步到AzureAD的是密码吗？
不，是密码的哈希值。具体什么是哈希值：
比如你的密码是12345，那么哈希过后，密码就编程abcde。如果你说那我把密码改成12344后是不是哈希值就是abcdd了呢？当然不是那么简单，如果你更改哪怕1个字符，哈希值会完全改变，比如12455的哈希值就变成了%*(*HF。所以哈希是不可逆的，就算别人拿到你在AzureAD中的密码哈希值，也是无法反向推导你的原始密码的。

2.选择密码哈希同步就只有哈希算法这一层保护吗？
不，首先AzureAD Connect跟Azure AD之间的通信时经过SSL的，这本身也是一层保护，其次在AzureADConnect把哈希值交付给AzureAD前还有额外的加密，直接用第3个问题引出中间的流程

3.如果用户1的密码是123，用户2的密码也是123，是不是代表他们在云端的哈希值是一样的？
不，完全不一样。看一下下面这张图（画的不是很好）:

中间Azure AD Connect的部分，其实还会再次用SHA256来加密一次，这当中其实还有一个排序算法来确保两个就算是一样的密码，处理后得到的SHA256哈希值也是不同的。整个过程也是在证书的加密过程下进行的，另外别忘了AzureAD Connect跟Azure的通讯还是在SSL加密下进行的。所以一共4层的安全措施来保障密码同步的安全。

另外还有一点：微软在持续监视各种暗网上的交易，如果有一个暗网上出现了一个黑客提供的用户名密码，名且这个用户名符合某一个AzureAD的用户名，微软会拿暗网上提供的密码走一遍这个加密流程查看是否最后得到的哈希值是一样的，如果是一样的那么会匿名举报。这就是为什么我们说密码哈希同步时最好的认证方式。

接下来我们看一下PTA：
PTA可以看成是ADFS的一个“阉割”版本，所以我们先看一看ADFS再来看PTA。
ADFS架构：
如果想要实现高可用，那么ADFS这个部署上最少用到4台服务器（形成一个场），2台加域的ADFS服务器，2台Web Application服务器（放在DMZ中，如果这当中你需要实现负载均衡那么额外购买其他的硬件设备），然后根据实际的用户数量，你还需要增加相应的服务器数量，可能到6台，8台也不一定。最后考虑灾备的情况，那么就需要整个架构再复制一份到另外的机房去。大致的拓扑图如下:

流程：
ADFS的认证与密码哈希不同，分为内网认证和外网认证。先看内网，公司内网当用户登录的时候，ADFS使用的是Kerbores协议，因为可以直接访问到本地的域控制器，认证后产生票据/令牌颁发给用户，用户讲令牌给Office 365来实现登录。这个过程因为使用的是Windows Intergrated Authentication，那么直接使用当前登录的用户名和密码，所以用户无需再次输入，也就实现了我们认为的单一登录（single sign on）
如果是外网访问：外网访问的时候，AzureAD会看用户的后缀名，然后根据域名来看这个域名属于哪一种形式，是managed还是Federated，如果是联盟身份认证，就去找web服务器（ADFS的服务由WEB服务器发布到公网）发布的网址：https://sts.contoso.com/adfs/ls/idpinitiatedsignon.htm，这里也就是一个重定向，用户在这里完成身份认证，也会拿到令牌来登录Office 365。

Azure AD与本地AD存在一个依赖信任关系（relying party trust）,这里包含了所有的需要放在这个颁发的SMAL令牌的配置信息（类似用户和一些用户属性的信息，邮箱，ObjectID等等）。那么为什么AzureAD会信任这个信令？在最初搭建ADFS环境的时候，有一步是需要提供一个第三方CA的证书的，也就是所Azure会需要一个从本地签名的信令，如果这个签名是正确的，那么AzureAD会接受并准许用户登录。

有时候会出现一个情况就是整个环境使用了一段情况发现本地证书是有效的，但是AzureAD认证报错，不允许用户登录。这有可能是因为本地证书已经被更新过了。生产环境一般不会让证书有效期超过1年，所以当本地的证书更新后，AzureAD端存储的仍然是老版本的证书信息，所以就出现了不信任的情况。
当然使用ADFS会出现的问题也不单单只有证书这一项需要担心，虽然是一个高可用或者负载均衡的架构，如果负载均衡设备除了问题，不管是前端的还是后端的，都不能进行身份认证了。

再回到PTA，PTA前面提到是一个低配版本的ADFS，唯一任务就是去做身份认证。推出这个的原因也是因为ADFS的部署实在太冗长，而且维护成本很高，单单从对Azure/Office365的认证来看是有些不划算的，而且竞争对手OKTA也有非常建议的系统来做认证。
PTA从架构上来说比ADFS少了很多东西：
1.首先需要的服务器就少了少了一半
2.其次对服务器软硬件系统要求没有那么高
3.不需要第三方CA证书
4.不需要公网IP地址
5.不需要部署软硬件的负载均衡
6.部署和维护的成本也降低很多

我自己测试过，如果单单部署最简易的架构，ADFS从环境从0开始最快我需要90分钟，但是PTA只需要40分钟。

流程上与ADFS基本是一样的，但是这里Azure AD不会让用户重定向到一个URL去做认证，然后拿令牌，而是PTA在本地的代理–agent会持续的向Azure AD发送请求，这个发送的流量都是出站流量，所以不用把PTA的服务器暴露在公网上，这样也非常安全，不像ADFS必须用WEB服务器来发布网址。因为这个请求是持久的，所以Azure AD知道有1台或者2台代理是随时待命的，我只需要把认证请求发给他们就好，这个背后的认证过程也是Windows Intergarted 认证方式。

我们再看最后一种，SSSO-Seamless Signle Sign On。这个认证方式是密码哈希同步和PTA的附加选项。
我们知道ADFS的一大好处就是用户体验，一个加域的处于公司内网的电脑在访问Office 365的时候不需要再次输入用户名密码–单一登陆。为什么密码哈希和PTA不能做到？就是因为Azure AD不认Kerberos这个协议。

那么现在SSSO支持了这种做法，如果用户使用加域的电脑在公司内网，也就可以实现单一登陆的体验，而且不需要部署ADFS

SSSO的工作原理跟ADFS一样，在部署AADC的时候勾上Enable Single Sign-on就可以：

这一步会创建一个计算机账户：“AZUREADSSOACC” 在微软的官方文档中也有提到–https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso-how-it-works
这个计算机账户到底是什么？其实就是一个代表Azure AD的计算机账户，但是位置放在本地AD。
我们看一下Kerberos是怎么工作的：比如现在你要访问一个本地的文件服务器1，这个文件服务器1肯定有一个登记的SPN（service principle name）计算机账户在AD，服务票据–Service ticket就是颁发给对应的这个SPN的。所以这个文件服务器我们可以理解成资源服务器，访问这些服务器都需要这样的服务票据。但是AzureAD不是一个本地的资源服务器，所以如果想让Azure AD用Kerberos就需要在本地注册这么一个计算机账户。AzureAD 的SPN里包含的URL就是代表Azure AD的–https://autologon.microsoftazuread-sso.com 把这个URL添加到你的Intranet区域里。配置SSSO的步骤可以在微软官网找到–https://docs.microsoft.com/zh-cn/azure/active-directory/hybrid/how-to-connect-sso-quick-start

用下表总结一下：