Azure AD和传统AD之间，到底有啥差别？
以下的图表准确地进行了解释。该图表由盆盆的好友EMS Huang和尊华整理制作。
传统AD依赖于Kerbose进行验***，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
本文出自 “MVP盆盆” 博客，请务必保留此出处http://markwin.blog.51cto.com/148406/1621664
原文地址：http://markwin.blog.51cto.com/148406/1621664
