今天遇到了一個奇怪的問題，公司目前在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 'AD\XXX'. (Microsoft SQL Server, Error: 18456)
其中的'AD\XXX'是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)