ActiveDirectory did not bind to the domain

[LostnIL]

Hello All,
I've been working on this issue for awhile, and I can't seem to get FreeNas to join my Domain. I've done this before in the past with little trouble.

I am getting a ActiveDirectory did not bind to the domain. I searched this issue, and tried the official AD steps, and a bunch of troubleshooting steps I found here on the forum.

I can ping the domain from freenas console, I setup the host info for FreeNAs in the DNS server. I can ping back and forth between the NAS and the DC.

I'm stumped and don't even know which information I should provide here. Has anyone encountered this error before when trying to join/auth with AD?

I am running the latest FreeNAS and the Domain Controller is running Windows Server 2012 R2

Thanks in Advance.

 

[Nick2253]

Have you read through the documentation on this: https://doc.freenas.org/9.10/freenas_directoryservice.html

I did this about a month ago, and I had no problems, so hopefully we can figure out what's going wrong here.

My procedure was (as best I can remember):

• Create DNS entry for FreeNAS server.
• Ensure that FreeNAS has correct DNS server and can resolve domain.
• Ensure that FreeNAS can resolve its own hostname.
• Ensure that any other domain-joined machine can resolve FreeNAS hostname.
• Create user in domain for doing FreeNAS join (I created a user "freenasAdmin" with a randomly generated password)
• Precreated FreeNAS server object in AD (I don't know if this is needed, but I figured it couldn't hurt; see the guide below for more details)
  
• Make sure domain time and FreeNAS time (including time zones) are in sync (I have my domain controller configured as an NTP server, and I pointed my FreeNAS server at my domain controller, however you could probably point it to any NTP server and it would be accurate enough for AD)
• Put the domain name, username (freenasAdmin), and password in the Directory Services -> Active Directory window.
• Join domain!

I referenced this guide during my setup, but didn't follow it exactly: https://forums.freenas.org/index.ph...directory-folder-file-user-permissions.20610/

 

[LostnIL]

I did. I followed those tutorials. One odd thing that keeps happening, every-time I try and join the Domain, the object I created for the FreeNAS server gets automatically disabled? Have you ever seen that happen ?

 

[Nick2253]

That's odd. Maybe you don't need to create the object in advance?

 

[anodos]

That's odd. Maybe you don't need to create the object in advance?

You don't need to create the object or the DNS entry in advance. They will be created automatically during the the process of joining the domain. The steps I follow are basically this:

1. Set static IP address for freenas server (you can also create a static mapping for it on your DHCP server).
2. Point it at the same NTP server as your DCs
3. Configure DNS properly on the FreeNAS server
4. Verify that you can ping the DC by name.
5. Create user for FreeNAS server (not necessary as you can use any domain account with appropriate privileges, but it is a cleaner way of doing things.)
6. Fill in correct info for your domain in the FreeNAS webgui under "Directory Services" -> "Active Directory", check the "Enable" box, and click "Save".

 

[Mystik Incarnate]

I'm having this issue. I recently updated to 9.10 from 9.3 during a round of maintenance against some of my systems. Anyways, since the update, I have no user auth from AD. When following anodos's instructions above, the WebUI lags for about a minute then reports that the service failed to restart.

Looking deeper, I found some instruction that said to run a script for troubleshooting, the output follows:

# sh /etc/directoryservice/ActiveDirectory/ctl start
False
True
Failed to join domain: failed to lookup DC info for domain 'domain.local' over rpc: Logon failure
False
winbindd not running? (check /var/run/samba/winbindd.pid).
smbd not running? (check /var/run/samba/smbd.pid).
nmbd not running? (check /var/run/samba/nmbd.pid).
True

not sure what the true/false statements mean, hopefully someone does.

Digging even deeper, I found you can init kerberos from the command line by the following commands:

[root] # sqlite3 /data/freenas-v1.db "update directoryservice_activedirectory set ad_enable=1;"
[root] # service ix-kerberos start
[root] # service ix-kinit start

After which, if I try klist, it gives me the token information.

So I dug even deeper. I checked the security event logs for login failures based on the log output above (specifically "Failed to join domain: failed to lookup DC info for domain 'domain.local' over rpc: Logon failure")
and I found the request that was failing.

So here's the compare, success from when I push ix-kinit to start manually looks like this:
Audit Success (Event 4624): An account was successfully logged on.
Subject:
Security ID: SYSTEM
Account Name: DC$
Account Domain: DOMAIN
Logon ID: 0x3e7

Logon Type: 3

New Logon:
Security ID: DOMAIN\Admin
Account Name: Admin
Account Domain: DOMAIN
Logon ID: 0x1749a0f
Logon GUID: {00000000-0000-0000-0000-000000000000}
[...]
Network Information:
Workstation Name: DC
Source Network Address: <IP of FreeNAS>
Source Port: 28175

This was followed by event 4768: A Kerberos authentication ticket (TGT) was requested. I'll let you fill in your own details for what it looks like (it's not super important anyways)

So here's what the failure looks like:
Audit Failure (Event 4625): An account failed to log on.

Account For Which Logon Failed:
Security ID: NULL SID
Account Name: Admin
Account Domain:

Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xc000006d
Sub Status: 0xc000006a
[...]
Network Information:
Workstation Name: FreeNAS
Source Network Address: <IP of FreeNAS>
Source Port: 52830

-------

So why is it not filling out the Account Domain field when authenticating? It obviously has the correct login information and all the details required to make this happen, but it's failing to because it's not passing along all the information needed to make a successful connection.

I'm hitting my head against a wall here, can someone point me at what I need where to make sure that all aspects of the AD connect are correctly configured with the domain (I've already checked every field under AD in the WebUI, including those under advanced)?

 

[jharm73]

You don't need to create the object or the DNS entry in advance. They will be created automatically during the the process of joining the domain. The steps I follow are basically this:

1. Set static IP address for freenas server (you can also create a static mapping for it on your DHCP server).
2. Point it at the same NTP server as your DCs
3. Configure DNS properly on the FreeNAS server
4. Verify that you can ping the DC by name.
5. Create user for FreeNAS server (not necessary as you can use any domain account with appropriate privileges, but it is a cleaner way of doing things.)
6. Fill in correct info for your domain in the FreeNAS webgui under "Directory Services" -> "Active Directory", check the "Enable" box, and click "Save".

What are the "appropriate privileges" ? I can only get it to work if the user is part of the Domain Admins group, which i really dont want to have to do.

Thanks!

 

[jharm73]

from another thread:

I created à standard service account (normal account with service name) , and give full control over computer account corresponding to freenas computer under security tab of computer account properties

This worked! Thanks!!!

 

[Nick Lutz]

Hi All,

I know this post is kind of old, but I used to have a lot of issues with FreeNAS and Active directory. FreeNAS still plays a minor role in our datacenter, and upon each boot, it never fails; FreeNAS will not join our Active Directory domain. I've come up with a script that, when run, joins FreeNAS to our AD domain each and every time. I keep the script on one of our shares and execute it from a FreeNAS ssh session. I'm not saying that this will solve your AD problems, but this may help in some way:


#!/bin/csh
echo "Setting AD to enabled in the FreeNAS Database..."
sqlite3 /data/freenas-v1.db "update directoryservice_activedirectory set ad_enable=1;"
echo "The AD enable returned code: $?"
echo "Restarting kerberos..."
service ix-kerberos restart
echo "Restarting NSS..."
service ix-nsswitch restart
echo "Restarting kerberos init..."
service ix-kinit restart
echo "Status from the kerberos init restart..."
service ix-kinit status
echo "The status command returned code: $?"
echo "Kerberos found the following security principals:"
klist
echo "Restarting the CIFS process..."
python /usr/local/www/freenasUI/middleware/notifier.py restart cifs
echo "The CIFS restart returned code: $?"
echo "Restarting the Active Directory service..."
service ix-activedirectory restart
echo "Active Directory Service returned code: $?"
echo "The status of the Active Directory service"
service ix-activedirectory status
echo "Active Directory Server returned code: $?"
echo "The Active Directory SRV record Summary"
host -t srv _ldap._tcp.yourdomain.net
echo "The Active Directory user listing:"
wbinfo -u
echo "The Active Directory group listing:"
wbinfo -g
echo "Finished"

Due to the "chatty" nature of this script, if it fails, at least you know where to begin your troubleshooting.

This script was assembled using bits and pieces from the various threads found here on this forum and other websites.

Almost forgot; edit this line:

host -t srv _ldap._tcp.yourdomain.net

To reflect your domain.

 

[Dotty]

Does not work for me, IM running 9.10.1-U4
If the FreeNAS comes back while the Domain Controller is Down it obviously cannot find the domain,, so I spin up the DC and then I run the script above, but I get:

The Active Directory SRV record Summary
_ldap._tcp.btf5-local.com has SRV record 0 100 389 win-2008-dc2.ad-local.com.
_ldap._tcp.btf5-local.com has SRV record 0 100 389 win-2008-dc.ad-local.com.
The Active Directory user listing:
could not obtain winbind interface details: WBC_ERR_WINBIND_NOT_AVAILABLE
could not obtain winbind domain name!
Error looking up domain users
The Active Directory group listing:
could not obtain winbind interface details: WBC_ERR_WINBIND_NOT_AVAILABLE
could not obtain winbind domain name!
failed to call wbcListGroups: WBC_ERR_WINBIND_NOT_AVAILABLE
Error looking up domain groups
Finished

 

[Nick Lutz]

When I see the WinBind errors, I tend to think that the SMB service is "switched off". Please check your "Services" screen to ensure SMB is turned "on". I've seen between "reboots" that this services is sometimes turned off with no explanation. For whatever reason, in older releases of FreeNAS, I had to significantly increase "AD timeout" and "DNS timeout" values. Currently using AD timeout of 120 and DNS timeout of 20.

Also to mention, if your system times are off by more than a minute or two, you will not be able to join the domain (even Windows boxes suffer this limitation/feature). Simple fix here; sync up your time between servers.

Is your domain account used by FreeNAS in a good state? Expired password, disabled, not a domain administrator, etc? Again, somewhat simple fixes.

And finally; I had issues when using my PDC (Primary Domain Controller) on Windows 2012R2 as my AD setup for FreeNAS. When I pointed FreeNAS to my ADC (Alternate Domain Controller) which is also Windows 2012R2, things improved significantly.

I'm currently on FreeNAS 9.10.2 (a476f16) - Dell R620 servers with Dual E5-2670 processors. I'm running two FreeNAS servers (one for SMB sharing another for ISCSI shares) on this configuration. SMB server has 128GB RAM, the ISCSI server as 192GB RAM. Both servers are currently on Active Directory Windows 2012R2 (virtual machines) patched to December 2016 levels.

Hope this helps.

Almost forgot; There were some bad Microsoft patches released in either September or October that really messed up active directory. Make sure to either back those out, or move forward to newer patches. These patches resulted in numerous issues including messing up our authentication with FreeNAS and QNAP with respect to Active Directory. I don't remember the specifics of those patches (KB numbers and such), if you really need this info, let me know and when I have some free time, I'll research it.

 

[Dotty]

Hi Nick
You are right on the spot, I see those errors when SMB toggle is OFF.
The problem is, when FreeNAS reboots and the DC is not available, then toggle stays OFF after reboot.

I can turn it ON manually, but it defeats the purposed of having s script, so Im looking for a way to start the SMB on startup, and have the Toggle reflects that.
Do you know how to start SMB from command line on FreeNAS in a way that the toggle also turn ON?
All the options I have tried so far force the SMB to run and everything works, but the toggle reflects OFF state.
Thanks

 

[Nick Lutz]

Good question. It's probably something like;

sqlite3 /data/freenas-v1.db "update services set smbfs_enable=1;"

I'm not in front of a freenas server right now to find out what column needs to be toggled in the sqldb. The script was written prior to 9.10 when smb toggling was not dynamic.

 

[Dotty]

Yes, I also saw the DB and opened with a Windows machine,, saw the schema and toggle the controls via queries.
Visually, they change, but the functionality is not done there (meaning, I toggle the button via DB, but the service doesnt start/stop)
I figured that I could start the service via script, and then toggle the button via DB so it looks consistent, but I still cannot find out what is the real command they use for starting the SMB.
I guess we are close.

 

[Dotty]

this is the query I used:
sqlite3 /data/freenas-v1.db "update services_services set srv_enable=1 where srv_service='cifs' ; "

It changes the toggle, on the GUI.

 

[Dotty]

I just started sending the commands on a different sequence., like this:

sqlite3 /data/freenas-v1.db "update directoryservice_activedirectory set ad_enable=1;"
echo $?
service ix-kerberos start
service ix-nsswitch start
service ix-kinit start
service ix-kinit status
echo $?
klist
service ix-pre-samba start
python /usr/local/www/freenasUI/middleware/notifier.py start cifs
service ix-activedirectory start
service ix-activedirectory status
echo $?
python /usr/local/www/freenasUI/middleware/notifier.py restart cifs
service ix-pam start
service ix-cache start &
service samba_server onestart
service ix-post-samba start
sqlite3 /data/freenas-v1.db "update services_services set srv_enable=1 where srv_service='cifs' ; "

I see FreeNAS now populates the list of objects from the DC, if I go to the "permissions" on a dasaset I can see users, etc.
The only problem is that when I try to browse the FreeNAS share from a Windows PC on that domain (a share that has AD permissions), the network drive wont reconnect.
Unless I reboot the client PC.

If instead of running all the commands above I just use the GUI , go to Directory Services, put the password, check the Enable option and click Save, then no problem, the network drive reconnects on the PC, without having to restart it.

Sounds like a kerberos ticket issue, but im out of my confort zone on that.
The fact is, the GUI is doing something that is not covered on the commands above, and I dont know what it is.

PS. all those tests are done simulating the case where FreeNAS reboots and the DC is not available until few minutes later.
basically Im rebooting FreeNAS with the DC box "offline", and give about 15 min separation before putting the DC online again and start working on the FreeNAS.

The whole point is to see how FreeNAS can be automatically reconnected if it reboots while the DC is not reachable (power outage, VPN issues, etc)

 

[mywobblysausage]

I am late to the party but I have just had this issue where my FreeNAS 9.10.1-U4 would not rejoin the domain after reboot.

My fix was to remove a VLan interface I had created as part of testing. No matter what, it could not login to the domain with that vLan interface (even though it was talking to my DC's, I could see failed login attempts in the DC's event logs).

 

[anodos]

I am late to the party but I have just had this issue where my FreeNAS 9.10.1-U4 would not rejoin the domain after reboot.

My fix was to remove a VLan interface I had created as part of testing. No matter what, it could not login to the domain with that vLan interface (even though it was talking to my DC's, I could see failed login attempts in the DC's event logs).

9.10 is quite old and buggy. It's probably a good idea to update, but I might hold off for 11.2-U4. I'm in the process of making significant changes to Active Directory for 11.3, which will make it much more fault-tolerant.