Wildfly 10/11/12域模式下4447远程端口AD认证配置问题

看起来你已经搞定了HTTP管理端口（9990）的AD LDAP认证，但卡在原生远程端口4447的认证上——这个问题其实挺常见的，核心原因通常是原生接口（native-interface）没有关联到你配置的AD安全域，或者SASL认证细节没调整到位。我给你梳理几个关键排查和修复步骤：

1. 确认原生接口的安全域关联 #

打开domain/configuration/domain.xml，找到<management-interfaces>节点，检查native-interface的security-realm属性是否和http-interface使用的是同一个AD认证的realm：

<management-interfaces>
    <!-- 确保native-interface引用你的AD安全域，而非默认的ManagementRealm -->
    <native-interface security-realm="ADRealm">
        <socket interface="management" port="${jboss.management.native.port:4447}"/>
    </native-interface>
    <http-interface security-realm="ADRealm" http-upgrade-enabled="true">
        <socket interface="management" port="${jboss.management.http.port:9990}"/>
    </http-interface>
</management-interfaces>

如果这里native-interface还是用的ManagementRealm，它只会读取本地的mgmt-users.properties，自然无法用AD用户登录。把它改成你配置AD认证的那个realm名称（比如示例中的ADRealm）。

2. 验证AD安全域的配置完整性 #

确认你的AD安全域配置包含完整的认证和授权逻辑，尤其是LDAP连接和用户/组过滤规则：

<security-realm name="ADRealm">
    <authentication>
        <ldap connection="ADConnection" base-dn="DC=your-domain,DC=com">
            <!-- 用户名属性要和AD匹配，通常用sAMAccountName -->
            <username-filter attribute="sAMAccountName"/>
        </ldap>
    </authentication>
    <authorization>
        <ldap connection="ADConnection" base-dn="DC=your-domain,DC=com">
            <group-search recursive="true">
                <group-to-principal attribute="member"/>
            </group-search>
            <!-- 确保AD组已映射到WildFly的管理角色（比如Administrator） -->
            <role-mapping>
                <role name="Administrator">
                    <group name="WildFly-Admin-Group" dn="CN=WildFly-Admin-Group,OU=Groups,DC=your-domain,DC=com"/>
                </role>
            </role-mapping>
        </ldap>
    </authorization>
</security-realm>

<!-- 对应的LDAP连接配置要保证绑定用户有权限查询AD -->
<outbound-connections>
    <ldap name="ADConnection" url="ldap://your-ad-server:389" search-dn="CN=Bind-User,OU=Service-Accounts,DC=your-domain,DC=com" search-credential="Bind-Password"/>
</outbound-connections>

重点检查：

• LDAP绑定用户是否拥有查询AD用户、组的权限
• 用户名过滤属性（sAMAccountName）是否和你测试HTTP接口时用的一致
• 角色映射是否覆盖了你用来测试的AD用户所在的组

3. 测试原生接口的AD认证 #

用WildFly自带的jboss-cli工具直接测试4447端口的登录：

# 替换成你的AD用户名、密码和控制器地址
./jboss-cli.sh --connect controller=127.0.0.1:4447 --user=your-ad-username --password=your-ad-password

如果登录失败，立刻查看域控制器的日志文件domain/log/host-controller.log，里面会有详细错误提示：

• LDAP连接超时：说明原生接口绑定的网络无法访问AD服务器
• 用户找不到：检查用户名属性或base-dn是否正确
• 权限不足：确认AD用户所在组已映射到WildFly的Administrator角色

4. 调整SASL认证策略（可选） #

如果上面的步骤都没问题，但还是无法登录，可能是原生接口的SASL认证机制和AD不兼容。你可以在安全域的认证部分添加SASL配置：

<security-realm name="ADRealm">
    <authentication>
        <ldap connection="ADConnection" base-dn="DC=your-domain,DC=com">
            <username-filter attribute="sAMAccountName"/>
        </ldap>
        <!-- 添加SASL配置，兼容AD认证机制 -->
        <sasl>
            <mechanism-selector selector="JBOSS-LOCAL-USER, DIGEST-MD5, PLAIN"/>
            <policy>
                <no-anonymous value="true"/>
            </policy>
        </sasl>
    </authentication>
    <!-- 授权部分保持不变 -->
</security-realm>

注意：PLAIN机制是明文传输，生产环境建议配合LDAPS（SSL加密的LDAP）使用。

最后重启域控制器，再测试4447端口的AD登录，应该就能正常工作了。

内容的提问来源于stack exchange，提问作者Tomáš Heřmánek