[前言]

虽然两者都叫做AD,其实除了品牌一样,Azure AD和传统AD几乎完全是两码事。那么他们之间到底有哪些区别?文章最后,还有用Azure AD部署传统应用的一个客户实例,有图有真相,千万莫错过哈^_^


Azure AD和传统AD之间,到底有啥差别?


以下的图表准确地进行了解释。该图表由盆盆的好友EMS Huang和尊华整理制作
640?tp=webp&wxfrom=5

传统AD依赖于Kerbose提供Authentication服务,Kerbose又叫做三头狗,要求计算机、用户和域控三方都要参与验证。这就是为什么在传统AD中,计算机也需要加域,因为它也有账号!计算机账号对人并不信任,它只信任域控!计算机也有登录到域的过程,甚至可以授权计算机账号访问文件夹和其他资源。

640?tp=webp&wxfrom=5

此外,在传统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可以对其进行解密和审核,并重新进行加密再发给应用程序。

640?tp=webp&wxfrom=5

应用程序拿到Azure AD签发的访问令牌后,将其解密,即可确定是否允许该用户访问。同时应用程序可能也需要访问Azure AD,以便读取该用户的其他属性,例如查看该用户的上级经理,以便确定是否请经理审批等等。这又要涉及到应用程序的服务主体账号,以及通过Graph API来访问Azure AD账号属性的能力。

光说不练嘴把式。这里给诸位介绍一个客户部署的实例(比较简单,没有用到ADFS),如何让CRM系统(基于Dynamic NAV系统)和微软Azure AD整合!

首先在在Azure里新建域名,并设置为主域,这样客户端今后可以用这个容易记忆的域名来登录,而无需用@domainname.partner.onm51CTO提醒您,请勿滥发广告!这样的冗长名字。
640?tp=webp&wxfrom=5


接下来在Azure AD里新建应用程序,这实际上是创建服务主体,这类似于传统AD里的SPN,因为应用程序需要获取请求用户的其他信息,这需要该应用程序在Azure AD里也要有自己的账号身份。
640?tp=webp&wxfrom=5

这里还需要指定应用程序的登录ID、ID URI和回复URL。在页面的底部,可以指定该应用的服务主体账号对Azure AD的访问权限,默认是允许登录和读取请求用户的user profile。
640?tp=webp&wxfrom=5

创建好应用程序的服务主体,则可以生成端点,对于Dynamic NAV来说,应该复制其联合验证的元数据文档地址。

640?tp=webp&wxfrom=5

将该数据粘贴到Dynamic NAV的路径,这样应用程序(RP依赖方)和Azure AD(STS)之间信任关系就创建完毕了。
640?tp=webp&wxfrom=5

导入或者新建Azure AD的用户,接下来用户就可以直接输入NAV的Web Client地址,就可以用Azure AD验证访问了!

640?tp=webp&wxfrom=5



华来四 是由彭爱华、黄爱华、程尊华和祁清华四位名字中都有华的MVP创建的微信公众号,分享最新的微软客户端、数据中心和云技术。欢迎扫描以下二维码关注,也可以直接在微信里关注:sysinternal

wKiom1UGxSiDZAQAAAHjAkIeaCg362.jpg