今天遇到了一个奇怪的问题，公司目前在SQL Server上都采用AD域账号登录，由于账号人数众多，所以我们建立了一个AD Group（域组），将大家的AD账号加入了这个AD Group，然后我们将这个AD Group设置为了SQL Server的账号。按道理说所有在这个AD Group的AD账号都应该可以用SSMS的Windows认证登录SQL Server才对，但是奇怪的事情发生了，所有同事的AD账号都能够在SQL Server所在服务器的远程桌面上用SSMS登录SQL Server（Windows认证），但是在自己的电脑上使用SSMS登录SQL Server（Windows认证）都报错，错误如下:
Login failed for user 'ADXXX'. (Microsoft SQL Server, Error: 18456)
其中的'ADXXX'是AD域账号。
但是奇怪的是我将大伙的AD账号而不是AD Group设置为SQL Server账号后，大伙在自己的电脑上又可以用Windows认证登录SQL Server了，但是如果SQL Server账号是AD Group，死活都不行。这时候我在想为什么将AD账号设置为SQL Server账号后可以，但是AD Group设置为SQL Server账号后就不行？后来我发现数据库服务器上SQL Server服务的执行账号居然用的是NT Service账号，如下所示：
我在想是不是因为NT Service账号权限不够，没法访问AD域服务器的AD Group信息，所以导致大伙在自己的电脑上使用Windows认证登录SQL Server失败？
因此我将上图的SQL Server服务的执行账号更换为了一个AD账号，并且该AD账号在数据库服务器的administrators组里面
然后重启SQL Server服务，还是将AD Group设置为SQL Server账号，让大家在自己电脑上还是通过SSMS用Windows认证登录SQL Server，结果大家现在都能登录上了！所以SQL Server在安装时的默认执行账号NT Service并不是万能的，像本文描述的情况就需要更改SQL Server服务的执行账户为一个AD账户，并且将其放在数据库服务器的administrators组里面。
顺便说一下，刚更改SQL Server服务的执行账户后，大伙登录可能会报下面一个错误，怀疑是SQL Server还没和AD域服务器同步，过了五分钟再登录这个错误就消失了，大家在自己的电脑上成功登录了SQL Server
The target principal name is incorrect. Cannot generate SSPI context. (Microsoft SQL Server, Error: 0)