FortiNAC cannot be joined to a FreeIPA domain through Network -> RADIUS -> Winbind. The Join Domain function performs a Samba Active Directory join, which FreeIPA does not accept by design.
The administrator creates a Winbind instance under Network -> RADIUS -> Winbind, points the Domain Controller Hostname at a FreeIPA server, and selects Join Domain. The GUI returns the following:
Failed to join domain: failed to connect to AD: No results returned
The failure persists even though:
The FreeIPA FQDN resolves correctly from FortiNAC. FortiNAC can ping the FreeIPA server by FQDN. Both systems are in the same subnet. The LDAP directory integration against the same FreeIPA server already works and is synchronising users and groups.
This combination of symptoms leads administrators to troubleshoot DNS, firewall policies and bind credentials, none of which are the cause.
The join cannot succeed and is not a candidate for further troubleshooting. The Winbind Join Domain button runs a Samba Active Directory join. FreeIPA is not an Active Directory domain controller and does not accept that join procedure.
Confirming the cause:
Enable the Winbind debug and reproduce the join:
execute enter-shell
nacdebug -name WinbindPlatformService true
The FortiNAC server log (output.master) records the failure:
ERROR yams.WinbindPlatformService - Error joining domain [IPA]:
Failed to join domain: failed to connect to AD: No results returned
WARN yams.WinbindPlatformService - Winbind Instance [IPA] isJoined = FALSE /
net ads testjoin -k (255):
WARN yams.WinbindPlatformService - Join to domain is not valid: NT code 0xfffffff6
The underlying command is visible in auth.log:
sudo: nac : USER=root ; COMMAND=/usr/bin/net ads join --no-dns-updates -U <account>
net ads join is the Samba join to an Active Directory domain. It first sends a connectionless LDAP (CLDAP) netlogon query to the configured Domain Controller Hostname and expects an AD netlogon response. FreeIPA answers the query from 389 Directory Server but returns no netlogon attribute, so Samba aborts with No results returned before any Kerberos or SMB exchange takes place.
A packet capture taken during the join shows exactly this pattern - one CLDAP request and reply on UDP/389, then nothing on UDP/88 or TCP/445:
execute tcpdump -i any host <FreeIPA_IP>
16:21:21.274100 Out IP fnac.45903 > freeipa.ldap: UDP, length 97
16:21:21.274459 In IP freeipa.ldap > fnac.45903: UDP, length 185
This is why the usual checks are all green and still irrelevant: DNS resolution, ICMP reachability, same-subnet placement and a working LDAP bind confirm transport and directory access, none of which is what the AD join requires.
FreeIPA documents this limitation on its own side. The IPA domain controller role does not create machine accounts in response to net ads join; IPA hosts are enrolled with ipa-client-install, which FortiNAC does not expose. Installing ipa-adtrust-install does not change this - it enables a cross-forest trust towards a real Active Directory forest, it does not turn FreeIPA into an AD domain controller.
A misleading intermediate error:
Before the above error appears, an incorrectly filled Domain NetBIOS Name produces a different message:
Failed to join domain: Invalid configuration
("workgroup" set to 'EXAMPLE.LOCAL', should be 'EXAMPLE')
This is a genuine field error - the Domain NetBIOS Name is the short name (EXAMPLE), not the Kerberos realm (EXAMPLE.LOCAL). Correcting it is necessary but does not resolve the join, which then fails at the AD discovery stage described above.
What to configure instead:
Winbind in FortiNAC serves one function only: ntlm_auth for MSCHAPv2. Nothing else depends on the domain join. Directory user and group synchronisation, portal authentication, administrative login and policy matching all work through the LDAP directory alone.
This is visible in the generated radiusd.conf, where the Winbind instance produces a single MSCHAP module:
#MSCHAP Configuration for Winbind - IPA
mschap mschap-IPA{
ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --allow-mschapv2 ..."
Select the authentication design according to the requirement:
Requirement | Configuration | Winbind needed |
|---|
Users and groups from FreeIPA in FortiNAC | LDAP directory under System -> Settings -> Authentication -> LDAP | No | Portal or administrative authentication | Same LDAP directory | No | 802.1X with FreeIPA username and password | Local RADIUS Server, EAP-TTLS/PAP (optionally PEAP-GTC) validated against the LDAP directory | No | 802.1X with certificates | Local RADIUS Server, EAP-TLS using certificates issued by the FreeIPA integrated CA | No | FreeIPA-side policy such as HBAC rules or IPA OTP | Proxy RADIUS towards a FreeRADIUS server integrated with FreeIPA | No | PEAP/MSCHAPv2 or TTLS/MSCHAPv2 | Requires a real Active Directory domain | Yes - not possible against FreeIPA |
Steps:
Delete the Winbind instance under Network -> RADIUS -> Winbind and leave the service disabled. Each failed join re-provisions and restarts radiusd, and leaves a non-functional MSCHAP module in the RADIUS configuration. Under the Local RADIUS Server configuration, enable TTLS (and GTC if PEAP-GTC is required) in Supported EAP Types, and remove PEAP so supplicants cannot negotiate an MSCHAPv2 method that cannot succeed. Confirm the LDAP directory is reachable and its credentials validated. TTLS/PAP authenticates by binding to the directory defined in FortiNAC. Configure the endpoint supplicants for EAP-TTLS with inner PAP. This is supported natively on Windows, macOS, iOS and Android, but is not the default on Windows and must be deployed through GPO or an MDM profile. Change the LDAP directory to LDAPS (TCP/636) or StartTLS before putting TTLS/PAP into production. With PAP the password reaches FortiNAC in clear text inside the TLS tunnel and is then verified by a simple bind, which is unprotected on TCP/389.
Do not attempt to work around the join by running ipa-adtrust-install on the FreeIPA server. It does not produce an AD domain controller that net ads join can join.
Related documents: | 
