看了几个文章，都是写的exchange2010的报错，有点过时了，我写下exchange2013遇到该问题的排查


首先排除服务器的问题和用户本地配置的问题。

对比法：服务器是否有问题？其他账户是否有问题？本地环境下其他账户是否有问题？


均排除，那么问题就在账号上了。


查看该账号在AD中的属性，安全选项卡，推荐在另一台辅域控上打开正常账号进行对比。


发现SELF权限中很多权限消失，类似于网上其他exchange2010文章中描述的管理员NT AUTHORITY\SELF权限丢失问题。


修改后账号恢复正常，但是过一天，甚至几个小时候仍然会有该问题，权限依然会消失。


那么问题出在哪里呢？继续排查发现该账户是在adminisratorsAD管理员组中，依然参考exchange2010问题中的解释：

活动目录服务有个处理过程是为了保证受保护组的安全描述符不被改动。如果一个属于受保护组的账号的安全描述符跟AdminSDHolder object的安全描述符不匹配的话， 
那样这个账号的安全描述符会被AdminSDHolder object的安全描述符所覆盖。

由于修改Send As权限是通过修改用户的安全描述符来实现的，因此假如一个用户是属于某个受保护组的话，上述修改会在一个小时左右执行，即把AdminSDHolder object的安全描述符覆盖到这个用户的安全描述符，因为Send As属于安全描述符的其中的一个权限，所以同时也会被覆盖，最终导致NT AUTHORRITY/SELF 权限丢失。

而我的实践经验也发现，凡是属于受保护组的账号，都是没有Send As权限的。

2.受保护的组大概有哪些

Administrators 
Account Operators 
Server Operators 
Print Operators 
Backup Operators 
Domain Admins 
Schema Admins 
Enterprise Admins 
Cert Publishers

还有一点，有两个特殊账户也是受保护的： 
Administrator 
Krbtgt

3.如果将用户上述组的成员或者用户，Send As权限就会丢失。

微软官方建议不要使用受保护组成员来作为邮箱账号。假如你真的需要受保护组的那些权限，建议你使用两个域账号。 一个用来加入受保护组，另一个用来作为邮箱账号。

由于办公过程需要操作AD，所以加入了Account Operators这个组，就可以在本机使用dsa.msc来操作AD的账号了，随之就出现NT AUTHORRITY/SELF 权限丢失了。

所以呢，碰到这些问题的朋友们，还是按照微软的建议，分开两个账户来使用吧，总之就是不要把要用到邮箱的账号加入到上述的受保护组，即使你拼命添加NT AUTHORRITY/SELF这个权限，过一个小时左右照样会不见的。


以上