在进行了Office 365 的基础AD同步之后,某天突然发现O365的AD同步不正常,如下图,默认本地AD和Office365 AD同步时间为三小时,下图中这种情况明显是有状况的。
在对上述这种情况进行Troubleshooting的时候,我在客户端要么重新安装同步工具 Azure AD Connect,要么就手动运行Azure AD 同步命令。但是这样只是一次性的触发一次同步,没有彻底的解决问题。
但是这样不是一个长久的解决办法,那就从问题的根源开始找原因。
其实Azure AD的同步也是一次从Local AD 主动向O365 推送的一次同步,我们可以在计划任务中找到这个计划。
我们点进去详细看一看
在这里我看到一个非常奇怪的账号,这个账号从字面上理解应该是Office365 AD同步系统自动生成的一个账号,结果最终问题就出在这里,我们继续往下看。
在这个计划任务的历史记录里面,我找到了相关的报错,一看多半就是账号的问题。
这个时候既然这个自动生成的账号有问题,那么自然而然会联想到我的服务器中负责 AD 同步的某一个 service是否也在跑这个账号呢?
果然被我们不幸言中,就是他,不对,是很眼熟,但是貌似又不是!而且和上面一个账号都是本机的一个本地账号。
继续,我们再打开本机的账号管理,终于找到了这两个账号!!
我确定问题肯定是出在这里。
通过微软Office365KB的查找,结果发现,Office 365 在安装AD同步工具的时候,会在本机自动创建一个叫做 AAD_ 的账号,这个账号是专门授权用来跑AD同步计划的,并主导 Microsoft Azure AD Sync服务的。
但是我不清楚我这里为什么有两个,难道和我重装多次同步工具有关? 后续再来研究吧
以下是微软资料中的截图
唯一的 AAD_ 账号
且这里运行该计划任务的账号应该具有域管理员的权限,不然无法上传AD属性。我这里的Author是我自己,是因为我在解决问题的时候修改过这个计划任务,理论上应该是AAD_ 这个账号哈,无所谓,但是下面的running账号就非常重要了。
BTW:这里大家不要学我用自己的管理员账号,我还是强烈建议可以创建一个单独的服务账号,或者就利用这个AAD_账号,保证密码永不过期即可。
修改完成之后,手动disable再enable一下这个计划任务,run一下,可以发现同步成功,且Office365 AD也能成功同步。
本文转自horse87 51CTO博客,原文链接:http://blog.51cto.com/horse87/1738373,如需转载请自行联系原作者