FortiNAC-F
FortiNAC-F is a zero-trust network access solution that provides users with enhanced visibility into the Internet of Things (IoT) devices on their enterprise networks. For legacy FortiNAC articles prior to FortiNAC-F 7.2, see FortiNAC.
Hawada1
Staff & Editor
Staff & Editor
Article Id 341180
Description This article describes how to fix and troubleshoot the Winbind integration with FortiNAC.
Scope FortiNAC v9.4 and Above
Solution
  1. Check which DNS are the primary and secondary DNS configured on FortiNAC's configWizard.

  2. Check to ensure the FortiNAC can resolve the DC's address.

  3. Try to nslookup the domain from the FortiNAC shell:
    fortinac:# execute enter-shell
    fortinac:~$ nslookup forti.lab
    Server: 192.168.1.10
    Address: 192.168.1.10#53
    The response with the domain controller IPs:

    Name: forti.lab

    Address: 192.168.1.10 <- DC1.
    Name: forti.lab
    Address: 192.168.1.11 <- DC2.

    Additionally, ensure that _ldap._tcp.forti.lab and _kerberos._tcp.forti.lab SRV records can be resolved, as these are used by clients to locate domain controllers:
    nslookup -type=SRV _ldap._tcp.forti.lab
    nslookup -type=SRV _kerberos._tcp.forti.lab
  4. Verify network connectivity between FortiNAC and the Domain controller using telnet:
    > telnet dc1.forti.lab 389
    > telnet dc1.forti.lab 135
    > telnet dc1.forti.lab 88
  5. If there is any time difference between FortiNAC and the domain controller, Domain join is sensitive to time. If there's a time drift, Kerberos authentication can fail.
    It's recommended to set an NTP on both FortiNAC and Domain Controller or manually sync the time if the NTP is unavailable.

In the scenario below, the Domain Controller Hostname(s) was added as an Asterisk "*", and not as a username

 

Domain Controller Hostname: Multiple servers may be specified, as well as * which will dynamically determine the best DC to contact.

 

Examples:

 

"dc01.example.com,dc02.example.com"

 

Or

 

"*"

Navigate to Network -> RADIUS -> Winbind tab -> keep the service Disabled and select Create New.

 

Note: The Domain NetBIOS Name must be in upper case, written as 'FORTI'. The same applies to the Kerberos Realm Name.

 

Winbind 1.PNG


After entering the domain credentials in the following 'Forti\adminuser' FortiNAC prompt the below error:


gse_get_client_auth_token: gss_init_sec_context failed with [Unspecified GSS failure. Minor code may provide more information: Message stream modified](2529638953)
ads_sasl_spnego_bind: kinit succeeded but SPNEGO bind with Kerberos failed for ldap/dc2.forti.lab - user[adminuser], realm[FORTI.LAB]: The attempted logon is invalid. This is either due to a bad username or authentication information.
Failed to join domain: failed to connect to AD: Invalid credentials

To resolve the issue, run the following command on the domain controller FortiNAC is complaining about joining (in this case, it was the secondary domain dc2.forti.lab) to verify the SPN:


setspn -L <service_account>

 

Example below:

 

Go to Windows -> Windows PowerShell on the Domain controller.

Copyright (C) Microsoft Corporation. All rights reserved.

 

PS C:\Users\adminuser> setspn -L FORTI\adminuser
Registered ServicePrincipalNames for CN=adminuser,CN=Users,DC=forti,DC=lab:

A service principal name (SPN) is a unique service instance identifier. Kerberos authentication uses SPNs to associate a service instance with a service sign-in account.

fortinac1:~$ cat /etc/samba/smb.conf
[global]
log level = 3
workgroup = FORTI
realm = FORTI.LAB
password server = *
security = ads
netbios name = fortinac1
dos charset = ASCII
fortinac1:~$

Result:


Winbind 2.png