现在的情况

我有一个以前处于工作组模式的OmniOS文件服务器，并使用本地用户/组（在服务器上创build）和本地passwd密码来validation访问Windows CIFS / SMB共享的用户。 一切按预期工作， /usr/bin/ls -V显示ACL中的本地用户和组名，还可以由Windows用户从资源pipe理器的Windows安全性选项卡设置和修改权限。

计划的结果和采取的步骤

现在我想将此服务器移动到由samba4 AD DC（域模式）服务的Active Directory域。 为了方便以后添加更多的服务器，我想停止使用本地凭据，而是将中央AD用于用户，组和密码。 文件服务器join到一个testing域没有问题，然后我添加pipe理帐户的基本映射：

 root@omnios:/root# idmap list add winuser:[email protected] unixuser:root add wingroup:[email protected] unixgroup:root 

之后，可以以pipe理员身份login，使用资源pipe理器安全性选项卡授予AD用户和组的权限，然后使用这些Windows用户帐户访问文件夹。 没有进一步的设置是必要的，权限按预期工作（当打开安全选项卡时，从SID到AD用户名的翻译在很短的时间内是可见的）。

除了系统用户/组以外， /usr/bin/ls -V显示的是自动创build的数字ID（root / Administrator除外，其映射在idmap是硬编码的）。

• 单个用户不能通过域名访问服务器文件夹
• 不允许Windowslogin的活动目录允许远程桌面
• Kerberosnetworking广告join不响应
• Active Directory（LDAP）和pam使用kerberos而不是bindpw或匿名访问
• Active Directory在小型远程办公室没有DC

 drwx------+ 3 root root 3 Oct 17 13:45 test user:root:rwxpdDaARWcCos:fd----I:allow user:2147483651:rwxpdDaARWcCos:fd----I:allow 

根据文档，这些应该在重新启动后丢失，但在我的简单的testing案例中，他们似乎坚持。 （编辑：我似乎误判了它，重新启动文件服务器后权限仍然存在，但它们被删除，重新启动域控制器后，更改为nobody ）。我有点怀疑使用这种简单的模式，因为后来的潜在麻烦（见第三个问题）。

问题

我已阅读命名服务的不同选项的文档 ，但有些部分仍然不清楚。

• 很多例子都是关于两组不同的用户帐户（Unix / Windows），这些用户帐户应该被转换，这样inputAD的用户也可以login到Solaris系统，拥有一个shell等等。 通常，还必须映射/翻译不同的名称（例如[email protected] <=> jdoe ）。 另一方面，在我的情况下，用户帐户不应该存储在Solaris主机上，不需要login，也不需要进行名称翻译。 除了AD之外，是否还需要在每个Solaris主机上创build这些用户帐户（通过脚本或手动方式），如果ACL应该正确命名？
• AD DC已经为每个新创build的用户自动生成了UID和GID值作为LDAP属性 – 可以/可取的是使用那些而不是用户名/组名？ 我认为这将是Solaris端的IDMU版本，但文档没有提到除了改变设置之外还需要什么。
• 如果服务器被移出域，移到另一个域，没有DC可用，再次改变到工作组模式，或者添加具有相同configuration的第二个服务器，则文档永远不会提及发生什么情况。 在我目前的设置中，所有本地用户将始终保持不变，因此只要来自客户端的用户/密码组合是正确的，就可以授予他们访问权限。 假设设置更改为域模式，在域控制器丢失后，所有ACL将无用（并且必须手动重新创build），因为新域将使用新的SID并且不能通过用户名进行映射，这是否正确？ 如果是的话，通常做什么来防止这种情况？

除了这三个问题的答案之外，我正在寻找的是一种最佳实践或总结，可以指引我走上正确的道路。 我认为这将是基于目录的名称映射使用AD或LDAP（我已经和他们自动同步），但我不是很确定。 以后我不想陷入漏洞（ACL丢失或无法使用），或者不做任何额外的工作（build立实际上永远不需要的额外名称信息系统）。 我真的很喜欢基于内核的CIFS共享的易用性和稳定性，并希望find一种解决scheme，只需在AD / LDAP而不是本地系统中使用用户名/密码即可。