定期修改账户的密码是个好习惯，也可以确保安全性。通常活动目录中的账户都会要求定期修改密码。对于普通用户账户来说这个并没有什么问题，但是对于用于服务运行的账户来说定期修改密码会增加很多维护成本。所以，通常管理员会将这些账户勾选密码永不过期，这样无疑增加了风险。
Windows中有托管服务账户Managed Service Account这个功能。可以把密码维护的工作交由Windows自动管理，即保证了安全也降低了维护成本。
创建服务账户首先要在AD中生成一个Microsoft Group Key Distribution Service的根密钥。这里用一个网上很流行的命令，根据当前时间减去10小时设定密钥的有效时间。创建完成会显示密钥的GUID。
Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10)) -Verbose
如果看不到图，请点我。
接下去就可以创建用于服务运行的账户了。其中DNSHostName可以设置成service.contoso.lab的样子。这里我为了好辨认，直接配置了计算机FQDN。另外，需要指定哪些计算机可以使用这个服务账户。可以是安全组，也可以是计算机账户
New-ADServiceAccount msa-client -DisplayName "MSA Client Test" -DNSHostName client-233.contoso.lab -PrincipalsAllowedToRetrieveManagedPassword client-233$
添加完毕后可以使用命令验证一下。
Test-ADServiceAccount msa-client | fl
同时在AD的用户和计算机管理单元里也能直接看到这个刚刚创建出来的托管服务账户。
接下去，我们就使用这个账户来运行Windows Time服务。直接在服务管理里，把登录账户改成域中的msa-client账户，密码留空。
系统会自动把它加到组策略的Log On As A Service的权限表里。并提示，新的登录名直到下次服务启动后才生效。
但是，我发现这样仍然不能启动Windows Time服务。
经过查证，需要将这个账户加入Generate Security audit的用户权限分配中。根据不同的服务，系统会有不同的权限要求，其它服务不一定需要这个权限。添加完毕后，就能正常启动Windows Time服务了。
如果要把服务改回Local System Account运行的时候，你会发现整个页面都变灰了，无法修改。
这个时候就要用到传统的sc命令了，虽然老，但是很有效。
sc config w32time obj=".\LocalSystem"
重启服务后，恢复原样。