本地AD域迁移到 Azure AD,ad域迁移教程-ESG跨境

本地AD域迁移到 Azure AD,ad域迁移教程

本地AD域迁移到 Azure AD

现在使用Azure AD的企业慢慢变多，很多企业开始准备将本地AD域搬迁到Azure AD上面去。Workspace ONE中不管是UEM或者是Access都是将本地AD域作为最重要的认证和用户信息来源，AD迁移到AAD必然是对目前架构的一次重大调整。

那么，与之对应的，Workspace ONE如何调整理一下思路：

1Workspace ONE UEM和Azure AD对接

没问题，UEM支持将Azure AD作为认证源。

2Workspace ONE Access和Azure AD对接

也没有问题，Access和Azure AD都支持SAML。也就是说，我们可以将Azure AD作为WS1 Access的SAML IDP。

单独对接都没有问题，那么UEM和Access都有的情况呢

3Workspace ONE UEM 和Access都有，如何和Azure AD对接

我们需要看一下UEM和Access都存在的情况下，企业应用的场景包括：

UEM可以利用Access统一认证，单点登录。之前UEM、Access分别和AD同步，两边的用户信息是匹配的。

启用Hub Service，将各个平台（苹果/安卓/Windows）的Intelligent Hub作为企业门户。此时门户的应用发布是部分来自于UEM，部分来自于Access。

所以，我们在设置上会将注册时的认证来源选为Workspace ONE Access。

是不是开始有点懵了

那么是不是UEM和Access分别与AAD对接，就可以了呢

我曾经也这么认为，结果发现分别对接后两边的用户属性无法匹配，会出现一旦将Access作为认证源，Hub就无法进行正常注册。

如果将UEM作为认证源，Hub可以注册，但无法获取到Access发布的应用列表。

貌似是一个两难的境地。

突破点是让两边的用户属性统一，最合理的方式是：Access把用户写入到UEM里面。

事实上是用户属性从AAD→→Access→→UEM。

我知道听起来有点玄幻，但确实可以做。基于两点：

1将Azure AD作为WS1 Access的SAML IDP，配置Just in Time用户，在 用户登录Access（其实是登录Azure AD）的同时，把信息写入Access。

实现了用户属性从AAD→→Access。

2 利用Airwatch Provisioning APP，实现用户属性从Access→→UEM。

也就是说在开始时Azure AD用户在UEM和Access都是没有账户，更不用说用户属性了。

Azure AD用户要做的就是登录一次Access，即可完成在Access和UEM的账户创建，包括用户属性和Azure AD同步。

接下来用户就可以用Azure AD凭证来注册设备，获取完整的应用门户了

管理员无需进行用户生命周期管理。只需要负责Azure AD的部分就好了。

很好对吧，下面我们来看看如何实现。

测试环境准备：

Workspace ONE UEM

Workspace ONEAccess

Microsoft 365 （Azure AD）

如何获得以上测试环境我就不写了。

首先我们利用hub service的向导，将UEM和Access进行集成。这是最简易的方式，很轻松将UEM和Access集成起来。注意hub注册认证源选择成Access。

下面我们将Azure AD配置成Access的SAML IDP。

第一步先下载Access的SAML元数据，注意此时Access是作为服务提供商（SP），所以我们需要下载SP的元数据。

第二步，我们需要配置Azure AD。先打开https://aad.portal.azure.com/。

选择Azure Active Directory，创建一个新的企业应用程序。

选择最后一项Nongallery。

授权用户，把自己的测试账户分配进去，要不然没有授权，用户是没法使用这个应用程序来完成SAML的。

点击单一登录，SAML。

设置基本SAML配置。

实体ID：刚才Access SP的XML地址。记得设置成默认。

回复URL：SP.xml里面可以找到。

注销URL：同上。

添加断言中的用户属性和声明：

注意这些值会作为Access的JIT用户属性，其中最关键的是ExternalID，是将来配置Airwatch Provisioning APP所必须的，如果没有则会造成用户无法置备到UEM里面去。注意声明名称的大小写。

下载联合元数据XML。

第三步，我们回到Access界面。

在身份提供程序中点击添加SAML IDP。

填写身份提供程序的名称，绑定协议HTTP重定向。

SAML 元数据就是把刚才从Azure AD下载的联合元数据XML用编辑器打开，粘贴到框中，点击处理IDP元数据。

用户识别方式选为NameID元素，点击加号两次，添加：

“urn:oasis:names:tc:1.1:nameidformat:unspecified”映射到

“userPrincipalName”。

“urn:oasis:names:tc:1.1:nameidformat:emailAddress”映射到

“userPrincipalName”。

选中即时用户置备，创建目录名称（可以是任意，不一定是FQDN那种）。

选中使用的网络范围，没有设置过就选中所有。默认是不选的，一定要选中。

身份验证方法自己随便起名字，SAML上下文是

选中启用单点注销配置。

修改访问策略，根据实际情况，本文是修改了default策略。选中所使用刚才自己创建的身份验证名称。

可以观察到目录中多出了一个即时目录，希望你刚才起了一个容易分辨的名字。

打开另外一个浏览器或者是隐私模式之类的，尝试用Azure AD用户来登录Access。

你会发现界面会自动跳转到Azure AD登录。

登录完成之后会发现该用户被即时创建了出来。

注意观察此时的用户属性，包括了我们的ExternalID，也就是图中的外部ID。

第四步：配置Airwatch Provisioning APP来做用户置备。这步还是在Access界面上。

新建Web应用，从目录中选择Airwatch Provisioning，先不用做任何配置，一路点击下一步，保存。

回到Web应用列表。选中新建出来的Airwatch Provisioning，点击编辑。会发现界面有所变化。出现在置备的相关内容。

点开配置。这里可以采用粘贴XML内容的方式来自动填写。XML是来自UEM设置目录集成这里导出。

置备选项页中，可以选择启用证书身份验证，或者手动输入的方式。把启用置备改成“是”。

用户置备页面。带红色星号的是必须的，可以看到ExternalID（外部ID）的重要性。

组置备可以不配置。

保存并分配给用户/组即可。稍后可以看到用户已经置备成功。

此时回到UEM界面，就可以看到置备出来的用户。

需要说明的是，用户只需要登录一次Access即可，并不需要手工点击Airwatch Provisioning这个APP，其实默认这个APP是隐藏，不显示在用户门户中的，因为没必要。

最后一步就可以用设备来注册试试看了。

至此我们就完成了WS1的挑战，和Azure AD的集成。

特别声明：以上文章内容仅代表作者本人观点，不代表ESG跨境电商观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与ESG跨境电商联系。