AD域環境是微軟整個產品體系中非常重要的一個系統，是大部分微軟應用的基礎。在某些情況下由於公司規劃原因或併購，會需要做AD域的遷移整合工作，或是兩個AD域跨林進行資源訪問。
這部分由於微軟官方有比較詳細的資料說明和實施步驟，所以本文就不再對此進行詳細描述，僅對實施AD整合過程中一些比較容易遇到的問題進行說明，豐富大家對此場景的瞭解。
跨林訪問的授權方式
背景
最近筆者實施了一個域整合的項目，由於客戶公司併購，需要將用戶和組全部從以前所在的A域全部遷移到新的B域（使用微軟ADMT遷移工具），但是由於一些其他原因，用戶需要逐步遷移，並且持續時間會非常長，大約1年（賬戶組會提前全部進行遷移）。
在此期間將會有一部分用戶仍然使用舊環境A域的賬號繼續使用，一部分已經遷移的用戶則使用遷移到新環境B域的賬號使用。
在此場景下，需要考慮在這個新舊環境都有用戶，並且文件服務器資源都還在舊域A域的情況下如何規劃用戶的授權問題。
授權問題
文件服務器一般爲了方便管理都會對組進行授權，所以本文主要討論對組授權的場景，也就是B域用戶訪問A域文件服務器的授權場景。單獨的用戶授權的場景比較簡單，本文不做討論。
根據AD中用戶訪問資源的工作機制，我們可以瞭解到，當用戶訪問文件服務器資源時，會首先和資源所在的域控進行身份認證，確認用戶賬戶是否有權限。對組授權則是會查看用戶賬戶信息的隸屬組信息進行判斷。
如果用戶賬戶屬性信息中，所屬的組剛好在資源的權限中也有同樣的組，則按設置的權限的進行訪問。
根據上述的工作原理，我們可以得出結論，如果需要授權只需要在A域的文件服務器上對共享資源授予需要的組的權限，然後再到B域中將用戶加入到對應的組中即可。（A域所有組都已經使用ADMT帶SID History跨林遷移到B域）
但是在筆者實際測試的中，發現並和我們設想的不一樣，部分用戶加入到了B域對應的組成員中並沒有獲取到對應的權限，而是需要將用戶在A域也加入到同樣的組成員方纔會有效果。反覆測試都是如此。
問題原因
經過詳細的測試分析，發現其實這個問題非常簡單，也並非我們理解的工作有問題，而是我們忽略了遷移的組的類型的問題。
因爲組有本地域組、全局組、通用組幾個類型，根據組的類型的定義，不同類型的組當然會有不通的情況。以下就將測試結果直接分享給讀者：
通過上表可以看出，由於不同類型組的作用域範圍不一樣，只有全局組和通用組的類型是以用戶自己所在域的權限爲準，本地域組只能以資源所在域的權限爲準。
遷移後用戶無法登入
背景
同前面描述的項目中在完成用戶遷移後，發現有部分用戶無法登陸，登陸提示：
During a logon attempt, the user's security context accumulated too many security IDs
問題分析解決
通過錯誤描述可以直接比較快找到線索，微軟官方文檔描述：
Windows系統包含一個限制，限制用戶的安全訪問令牌不能超過1,000個安全標識符（SID）。當用戶驗證訪問權限以與服務器建立新會話時，該用戶不能是該域中超過1,000個組的成員，如果超出此限制，則拒絕訪問服務器
參考鏈接：
https://support.microsoft.com/en-us/help/275266/error-message-during-a-logon-attempt-the-user-s-security-context-accum
以此筆者檢查環境並回憶項目實施過程，果然發現無法登陸的用戶都隸屬於大量的組的組成員。
雖然項目實施的某個國際大公司的AD環境，確實AD中有建立非常多的組，但還是比較難達到1000的限制。
最後筆者發現主因是本次項目過程中AD用戶和組遷移進行了兩次，而每次都會要進行帶SID History進行遷移，所以每個用戶的所屬組的數量就都“乘3”了。那些本來就所屬組較多的用戶在遷移2次後也就達到1000的限制。
找到了原因，解決辦法也就很簡單了，對這些無法登陸的用戶進行整理，將它從不需要的組中剔除，降低到1000個隸屬組之下即可。
其他注意問題
使用ADMT進行AD用戶遷移時，如果林內遷移，那麼用戶賬戶是移動的方式，完成遷移後源域的用戶賬戶將消失；如果是跨林遷移的方式，那麼用戶賬戶是複製的方式，源域的用戶賬戶仍然將會保留。
使用ADMT遷移用戶可以在多個域中遷移多次，只要是帶SID History即可保留在源域的權限。
使用ADMT進行遷移時需要配置禁用SID 篩選功能，測試發現如果在Windows Server 2016中文版環境下禁用SID 篩選命令沒有效果，而英文版本則可以正常運行。中文版的解決方法可以是下載英文語言包，將系統語言全部調整爲英文語言則可以正常執行。
作者：範博文