Azure AD和傳統活動目錄之間的差異

[前言]

雖然二者都叫作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