In our environment, our domain (school.edu) is serviced by 3 domain controllers. The correct SRV records are in DNS. However, our webmaster (like many other places), wants school.edu to redirect to www.school.edu. For this reason (and for security concerns), the A/AAAA records that exist for school.edu are pointing to public webservers which either handle the traffic or redirect browsers to www.school.edu. It would not be safe to have the domain controllers be publicly accessible, etc. Additionally, I do not know of any technical requirement mandating that a domain, school.edu, have any A/AAAA records at all. SRV records are all that is needed to find a domain's ldap/AD servers (and global catalog servers, etc).
When configuring Active Directory.. by following the documentation at TrueNAS SCALE docs, the checks we have end-users do all succeed: 1. Use dig to ensure DNS resolution is working; 2. Display all ldap SRV records for the domain; 3. Check/set/verify NTP is configured; 4. Check/set/verify the Timezone is correct.
However, when entering a domain (school.edu), username (administrator), password (super-secret) through the UI, we get the error: Failed to look up Domain Controller information: ads_connect: No logon servers are currently available to service the logon request. Didn't find the ldap server!
The workaround is to temporarily add a line to /etc/hosts:
school.edu 11.22.33.44 (ip of a domain controller)
The UI then functions as expected when configuring AD. Once kerberos, and everything else is configured automatically, it seems safe to remove that line from /etc/hosts. It would seem that the UI/middlewear is relying on the assumption that there are A/AAAA records for the domain, which may not always be the case. It should be using the SRV records to find the logon servers.
When configuring Active Directory.. by following the documentation at TrueNAS SCALE docs, the checks we have end-users do all succeed: 1. Use dig to ensure DNS resolution is working; 2. Display all ldap SRV records for the domain; 3. Check/set/verify NTP is configured; 4. Check/set/verify the Timezone is correct.
However, when entering a domain (school.edu), username (administrator), password (super-secret) through the UI, we get the error: Failed to look up Domain Controller information: ads_connect: No logon servers are currently available to service the logon request. Didn't find the ldap server!
The workaround is to temporarily add a line to /etc/hosts:
school.edu 11.22.33.44 (ip of a domain controller)
The UI then functions as expected when configuring AD. Once kerberos, and everything else is configured automatically, it seems safe to remove that line from /etc/hosts. It would seem that the UI/middlewear is relying on the assumption that there are A/AAAA records for the domain, which may not always be the case. It should be using the SRV records to find the logon servers.
