CentOS环境下SSSD对接不同FQDN的AD域控制器失败问题求助

你的问题核心在于SSSD默认会验证配置的ad_server的FQDN是否属于ad_domain定义的域后缀（即ad.example.net），而你的域控制器是dc1.example.net（不在ad.子域下），这触发了SSSD的服务器域名验证逻辑，导致后端判定为离线。同时，服务器主机名配置的不匹配也可能加重了连接故障。

下面是针对性的解决方案：

1. 禁用SSSD的服务器域名后缀检查 #

在sssd.conf的[domain/ad.example.net]段添加以下参数，强制SSSD跳过服务器FQDN与AD域后缀的匹配验证：

ad_server_check_suffix = False

这个参数会让SSSD不再要求AD服务器的域名必须属于配置的AD域后缀，允许你直接使用dc1.example.net这类非子域的服务器地址。

2. 修正服务器主机名配置 #

你的Linux服务器实际主机名是server.int.example.com，但sssd.conf里的ad_hostname设置为dev1210utl1.ad.example.net，这会导致SSSD无法匹配AD中注册的计算机对象（因为你是用实际主机名加入AD的）。修改这个参数为服务器的真实FQDN：

ad_hostname = server.int.example.com

如果你的服务器在AD中注册的是其他名称，需要对应调整为AD中显示的计算机FQDN。

3. 确认KRB5配置的稳定性 #

你的krb5.conf已经正确设置了dns_lookup_kdc = false并指定了KDC地址，这部分没问题，但可以保持配置更简洁：

[realms]
AD.EXAMPLE.NET = {
    kdc = dc1.example.net
    kdc = dc2.example.net
    admin_server = dc1.example.net
    admin_server = dc2.example.net
}

4. 验证云DNS解析的正确性 #

确保你的云DNS解析器能正确返回dc1.example.net和dc2.example.net的IP地址，用以下命令测试：

nslookup dc1.example.net
nslookup dc2.example.net

如果解析失败，需要先在云DNS中添加这两条A记录，指向对应的AD域控制器IP。

5. 重启SSSD并验证状态 #

修改配置后，重启SSSD服务：

systemctl restart sssd

然后查看SSSD日志确认故障是否解决：

journalctl -u sssd -f

如果日志中不再出现Backend is currently offline的错误，尝试用AD用户登录测试：

su - <ad_username>

通过以上步骤，你应该可以在不添加AD DNS到/etc/resolv.conf或修改/etc/hosts的情况下，让SSSD正常连接到指定的AD域控制器。

内容的提问来源于stack exchange，提问作者Parvez Kazi