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