今天来谈谈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,自签名的在外网没导入过根证书,没测试过,推荐公网证书)


    大概的结构图如下:

O365结合ADFS限制用户登录地址 (一) - 开篇介绍_第1张图片



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