今天来谈谈O365，O365作为一个Saas的服务，本身相比较在本地部署Exchange + S4B Server + SharePoint来说已经方便了不知道多少倍，作为企业的IT来说已经可以将工作重点完全放在业务上，而不是服务器和系统本身的运维，这也是云服务的一大优势。

    云服务的一个很大的优势就是开箱即用，省去了很多部署的步骤，但是相对应的，有一些在本地可以控制的东西，但因为云的基础架构本身是用户触碰不到的，所以上云之后可能就没办法像本地一样能够完全掌控全局了。

    当然绝大部分用户希望能控制的内容，云厂商都会出相应的接口把控制的权限交给用户，有一些本身云服务不方便做的，也可以结合一些其他产品来实现。比如今天要介绍的O365结合ADFS，ADFS本身并不神秘，这个产品出现到现在已经过了10年以上的时间了(没记错的话)，通常来说我们会使用它来做一些联合的身份验证，比如说不同的域之间要控制一些访问的权限等

    ADFS本身的功能不做过多的介绍了，很多人基本都已经知道了，O365结合ADFS其实也很常见，通常来说有一些企业上云之后希望把访问控制的权限依然放在本地，不希望使用AAD来验证用户的身份，这对于很多大企业来说很有可能是不合规的，这种情况下我们都会使用ADFS来将身份验证的请求转回本地，使用本地的AD验证用户的身份，然后再将消息转给AAD，来完成最终身份验证的过程，这是ADFS最基本的使用方法

    但是实际上ADFS还有很多其他的功能，我们可以根据自己的需求在ADFS上编辑各种各样的rules来限制用户的访问，今天要介绍的就是其中一种用法，有些客户使用O365之后希望员工只能在办公室里访问自己的邮件，这种需求其实也好办，在DNS上做做手脚大概的需求就能实现了，但是如果说希望有些组可能不受限制的访问，大部分员工只能在办公室访问，这种怎么搞？

    这就需要用到ADFS+O365的方式了。这也是这个系列的博客主要介绍的内容，通过ADFS+O365实现控制某些组可以不受限制的访问O365，某些组是只能在特地条件下访问，这就是我们需要实现的。

    需要用到的资源包括

    1：国内版O365订阅

    2：国内版Azure订阅(用来部署ADFS，本地也可以，但是需要有公网IP)

    3：公网证书一张（用于ADFS和ADFS Proxy，自签名的在外网没导入过根证书，没测试过，推荐公网证书）

    大概的结构图如下：

    另外环境中ADFS使用的是Windows Server 2012 R2的，如果是Windows Server 2016 有可能会不一样，这个要注意