桌面云和AD域的解耦玩法

在桌面云实践中，很多企业的第一步就是确定AD域，因为这是做用户认证的使用最广泛的基础架构。但是在大规模环境中，AD域本身的健壮性令人担忧。最近有机会了解到，有厂家的桌面云产品——深信服的在走一条离开AD域绑定的路线，很有特点。本文就记录一下相关信息。

桌面云是为了稳定性想要和AD解耦，但企业中其它一系列应用都是基于AD域的，不可能轻易改变。因此本次PoC的课题是用户仍然使用AD用户来登录桌面云，来看看深信服是怎么做的。

基本要素梳理：

用户来源：通过LDAP从现有AD域环境中同步。（也可以本地建立用户，本次不涉及）
用户组的实现：AD的安全组可以同步，但在同步之后，深信服中叫做“角色“。基于角色可以做个性化的管控和资源的分配。

第一步验证：AD域用户和安全组起效

预置条件

深信服桌面云没有本地建立用户。
测试域sanfortest.local的/test OU下有ad01、ad02、ad03 三个账户。
ad01、ad03属于安全组aaa。整体结构如下：

测试步骤及现象：

1、用测试域sanfortest.local/test ou下同步ad01、ad02两个用户，注意不同步ad03用户。

注意不勾选“只有导入到本地的用户，才能进行LDAP认证”。导入后的效果如图所示：

2、依次登录ad01-03，发现：ad01可以正常登录，ad02不可登录，ad03可登录。这就是因为ad01、ad03隶属于aaa安全组，现在在深信服中是aaa角色，这个角色有虚拟桌面资源。

注：深信服可以本地新建角色，角色是实现资源分配的第一步。从AD安全组同步过来的角色会默认和用户关联。从上图可以看出，AD同步的有默认描述。

第二步验证：AD域解耦起效

1、AD域只是用户登录验证，实际登录VDI桌面的，并不是AD域用户。从下图系统界面可以很清楚地看到，用户是Administrator，这是一个虚拟桌面的本地用户。

2、AD域故障或不工作时，通过缓存，用户仍然可以登录桌面云。将AD 域控制器的网卡禁用，通过本地缓存功能（最长30天），ad01仍可以正常使用。因此，深信服桌面云可以不受AD域故障的制约。具体配置见下图。

总结

通过以上的验证，基本解耦概念确实是实现了。但是仔细推敲，还是有不少疑问。对于我来说，最不适应的就是用户凭据的变更。登录的时候我是用的AD用户，可实际用桌面的时候，却变了身份，而且所有用户都是本地的用户，甚至都叫同一个名字，那对于用户之间差异性的服务该如何实现呢？我的第一反应是：如果每个用户要配置独立的NAS数据网盘的话，该如何实现。

和现场及远程的深信服工程师交流之后，我提出了以下桌面云项目中的常见个人数据盘相关的需求，目前正等待回应中。

设备使用传统的NAS品牌（传统的部署就是加域）。
用户登录时，挂到NAS上的自己独有的盘，且实现基本安全隔离（其它人不能看）。
对不同用户的网盘有不同特性，有自己的属性（角色），可实现配额等管理需求。
创建新用户时，在AD新建用户和加入用户组即可，不需要在NAS共享上手动配置文件夹等。

2020年1月6日，收到深信服相关回应如下，补充在此：

第一，不脱域，可以直接实现，其他厂家也支持。第二，脱域，深信服可以通过windows文件共享方式加云盘技术实现，需要使用vdc本地用户名密码认证，不再走ad域认证，但是该模式下无法做到个性化调整配置功能。其他厂家，脱域模式下，连挂载nas都不支持。第三，通过深信服的存储eds可以实现，只是仅支持同一品牌。

基本要素梳理：