TrueNAS version: 25.10.0.1 SCALE
Summary
When configuring LDAP as a Directory Service, TrueNAS generates an invalid /etc/sssd/sssd.conf file that prevents SSSD from successfully enumerating users and groups.
Because of how TrueNAS determines whether a domain is “online,” this failure mode surfaces as a generic 60-second timeout error (“Timed out while waiting for domain to come online”), which strongly suggests a networking or connectivity problem — even though the real issue is an invalid SSSD configuration.
This combination of:
- invalid config generation
- and misleading readiness checks
results in a very confusing and time-consuming debugging experience.
Issue 1: Invalid ldap_*_object_class values
TrueNAS writes LDAP filter syntax into SSSD options that expect plain object class names.
Generated (invalid)
ldap_user_object_class = (objectClass=posixAccount)
ldap_group_object_class = (objectClass=groupOfUniqueNames)
Correct / working
ldap_user_object_class = posixAccount
ldap_group_object_class = groupOfUniqueNames
Per SSSD documentation, these options must be object class names, not LDAP filters. Using filter syntax prevents proper enumeration.
Issue 2: Indented INI keys cause mis-parsing
Several LDAP mapping options are written with leading whitespace:
ldap_user_search_base = ou=people,dc=upton,dc=com
ldap_group_search_base = ou=groups,dc=upton,dc=com
ldap_user_name = uid
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_user_home_directory = homeDirectory
ldap_user_shell = loginShell
Because SSSD uses an INI parser where indented lines can be treated as continuation lines, these keys are not reliably parsed. This caused:
- missing
homeDirectorymappings - missing
loginShellmappings - silent fallback to defaults
Removing indentation resolves the issue immediately.
Issue 3: Misleading “domain timeout” error masks configuration failures
When saving the LDAP configuration in the UI, the loading spinner runs for exactly 60 seconds, followed by:
“Timed out while waiting for domain to come online”
After taking a peek at the middleware code, this timeout corresponds to logic that waits for at least one user and one group to be returned via NSS:
for pwd in iterpw(module=NssModule.SSS.name):
has_users = True
break
for grp in itergrp(module=NssModule.SSS.name):
has_groups = True
break
If neither users nor groups are returned within 60 seconds, the domain is considered offline.
Why this is problematic
- If the SSSD config is invalid (as in this case), enumeration will never succeed
- The error message strongly implies a networking or connectivity issue
- There is no indication that SSSD is running but returning zero results
- No hint is given to check
/etc/sssd/sssd.conf
I’ve seen a few fourm posts with this exact error, like this one:
<url to truenas fourms> /t/cannot-connect-ldap-timeout-error/47975
Result after manual fixes
After:
- correcting
ldap_user_object_class/ldap_group_object_class - removing indentation from all LDAP mapping keys
LDAP integration works correctly:
id <ldap-user>resolves immediately- UID/GID, home directory, and shell map correctly
- The domain comes online without timeout
Notes
This appears to be a middleware config-generation issue combined with insufficient error differentiation during domain readiness checks. The issue is fully reproducible and resolves immediately once the generated config is corrected.
Happy to provide logs, additional repro steps, or test against other LDAP backends if helpful.
