首先得说，你这个场景确实容易踩坑——新旧Samba域架构差异太大了，先帮你拆解下问题根源，再给可行的解决方案。

启动失败的核心原因 #

从日志里的objectclass sambaDomain is not a valid objectClass in schema就能看出来：你用旧Samba 4.6.7的ldapsam后端去对接新的Samba 4.17.4 AD DC，但两者的LDAP架构完全不是一回事。

旧的Samba PDC是NT4风格的域，用的是传统Samba LDAP schema，依赖sambaDomain这类对象来存储域信息；而新的Samba AD DC是完全兼容Active Directory的架构，它的LDAP目录里根本没有sambaDomain这个对象类。当旧PDC启动时，它会自动尝试在新AD的LDAP里查找或创建对应COMPANY域的sambaDomain对象，结果找不到对应的schema定义，直接就启动失败了。

你的思路方向对吗？ #

你的核心目标（让用户共用一套密码、平滑迁移）非常合理，但直接用ldapsam把旧PDC的密码后端指向新AD DC这条路是走不通的——ldapsam是为传统Samba LDAP域设计的，和AD的LDAP架构不兼容。

配置里的明显问题 #

除了架构不兼容，你的配置还有两个冲突点：

• 同时设置了passdb backend = tdbsam和passdb backend = ldapsam:ldap://dc1.company.com，Samba会搞不清该用哪个后端；
• 针对旧域COMPANY的idmap配置用了ldap后端，但新AD的idmap结构和旧Samba完全不匹配，这会进一步加剧启动错误。

可行的解决方案 #

根据你的场景，推荐三个方案，按长期维护成本从低到高排序：

方案1：把旧PDC转为新AD域的成员服务器（优先推荐） #

这是从根本上解决问题的办法：

1. 先停止旧Samba PDC的域服务（确保smbd和nmbd停掉）；
2. 把旧服务器加入新的COMPANY-NEW AD域，作为域内的文件服务器；
3. 调整旧服务器的共享配置，让用户通过AD账号认证访问。

这样用户直接用新AD的账号密码登录，不需要两套密码，你可以逐步把旧共享迁移到新服务器，或者让用户继续用旧服务器的共享——认证全走新AD。优点是架构统一，后续维护省心，彻底解决密码同步问题。

方案2：建立旧NT4域与新AD域的信任关系（平滑迁移首选） #

如果暂时不能停用旧域，可以尝试建立双向信任：

1. 在新Samba AD DC上配置信任关系，指向旧的COMPANY NT4域；
2. 在旧PDC上升级Samba版本（建议升到4.10+，因为4.6.7太旧，对AD信任的支持有限），然后配置Winbind对接新AD域；
3. 配置密码同步：用Samba自带的密码同步机制，或者pam_winbind等工具，确保用户在任何一个域改密码，另一个域自动同步。

这种方案可以保留旧域的同时，实现用户跨域认证和密码同步，迁移过程更平滑，适合用户数量多、需要逐步迁移的场景。

方案3：用密码同步工具临时过渡（应急方案） #

如果上面两个方案都暂时无法实施，可以用临时的密码同步工具过渡：

• 比如用sssd配置双域认证，让旧PDC的用户认证同时查询新AD的LDAP；
• 或者用第三方密码同步工具，监听两个域的密码变更事件，自动同步密码。

这个方案不需要改变现有架构，能快速实现密码同步，但属于临时过渡，长期维护麻烦，可能存在同步延迟或失败的风险，不建议长期使用。

最后，如果你需要更细节的配置步骤，可以提供更多环境信息（比如旧服务器的操作系统版本、用户数量等），我可以帮你细化。

备注：内容来源于stack exchange，提问作者Tipsyeagle