[前言]
雖然兩者都叫做AD，其實除了品牌一樣，Azure AD和傳統AD幾乎完全是兩碼事。那麼他們之間到底有哪些區別？文章最後，還有用Azure AD部署傳統應用的一個客戶實例，有圖有真相，千萬莫錯過哈^_^
Azure AD和傳統AD之間，到底有啥差別？
以下的圖表準確地進行了解釋。該圖表由盆盆的好友EMS Huang和尊華整理製作。
傳統AD依賴於Kerbose提供Authentication服務，Kerbose又叫做三頭狗，要求計算機、用戶和域控三方都要參與驗證。這就是爲什麼在傳統AD中，計算機也需要加域，因爲它也有賬號！計算機賬號對人並不信任，它只信任域控！計算機也有登錄到域的過程，甚至可以授權計算機賬號訪問文件夾和其他資源。
此外，在傳統AD中，所有以Local System、Network Service身份運行的服務，在訪問域中的其他共享資源時，是以計算機賬戶的身份進行驗證的。趕緊打開服務控制窗口，看看哪些服務是在這些賬戶身份下運行的！
很顯然，傳統AD協議Kerbose和LDAP太沉重，一般只能適合內網C/S架構，無法穿透Internet。如果要穿透Internet，通常要將其轉爲基於Claim的形式，例如我們熟悉的ADFS。ADFS有點類似於調制解調器，能夠把Kerbose協議"轉換"爲其他Internet驗證協議(SAML等)，儘管其實並不是真正意義上的"轉換"。
而Azure AD支持常見的Internet驗證協議，例如WS-Federation、SAML等輕量級的基於Claim的驗證協議。
登錄過程，傳統AD的登錄會由用戶向域控申請和計算機之間通信的會話票據(默認存活8小時)，用戶登錄計算機時，向計算機出示會話票據(例如：天王蓋地虎、寶塔鎮河妖)，同時加上時間戳證明沒有篡改過，計算機纔會授權用戶登錄。
登錄以後，我們會在該計算機上生成登錄會話，並查詢該用戶所屬的域組和本地組，以此來創建訪問令牌，如果是本地管理員，則會生成2張訪問令牌(普通用戶令牌和管理員令牌)。
Azure AD同樣有訪問令牌，不過其中的內容是Claim屬性，而且由於需要在Internet上交付，所以需要對其進行數字簽名和加密。
如果有聯合驗證，則ADFS將傳統AD中所獲得的SAML令牌(或者其他協議)加密並簽名，發給Azure AD，由於兩者之間有信任關係，交換過證書，所以Azure AD可以對其進行解密和審覈，並重新進行加密再發給應用程序。
應用程序拿到Azure AD簽發的訪問令牌後，將其解密，即可確定是否允許該用戶訪問。同時應用程序可能也需要訪問Azure AD，以便讀取該用戶的其他屬性，例如查看該用戶的上級經理，以便確定是否請經理審批等等。這又要涉及到應用程序的服務主體賬號，以及通過Graph API來訪問Azure AD賬號屬性的能力。
光說不練嘴把式。這裏給諸位介紹一個客戶部署的實例(比較簡單，沒有用到ADFS)，如何讓CRM系統(基於Dynamic NAV系統)和微軟Azure AD整合！
首先在在Azure裏新建域名，並設置爲主域，這樣客戶端今後可以用這個容易記憶的域名來登錄，而無需用@domainname.partner.onm51CTO提醒您，請勿濫發廣告!這樣的冗長名字。
接下來在Azure AD裏新建應用程序，這實際上是創建服務主體，這類似於傳統AD裏的SPN，因爲應用程序需要獲取請求用戶的其他信息，這需要該應用程序在Azure AD裏也要有自己的賬號身份。
這裏還需要指定應用程序的登錄ID、ID URI和回覆URL。在頁面的底部，可以指定該應用的服務主體賬號對Azure AD的訪問權限，默認是允許登錄和讀取請求用戶的user profile。
創建好應用程序的服務主體，則可以生成端點，對於Dynamic NAV來說，應該複製其聯合驗證的元數據文檔地址。
將該數據粘貼到Dynamic NAV的路徑，這樣應用程序(RP依賴方)和Azure AD(STS)之間信任關係就創建完畢了。
導入或者新建Azure AD的用戶，接下來用戶就可以直接輸入NAV的Web Client地址，就可以用Azure AD驗證訪問了！
華來四 是由彭愛華、黃愛華、程尊華和祁清華四位名字中都有華的MVP創建的微信公衆號，分享最新的微軟客戶端、數據中心和雲技術。歡迎掃描以下二維碼關注，也可以直接在微信裏關注：sysinternal
