CIFs share only accessible without DNS entry

[socos]

Hello all, I've got an interesting one. I upgraded to 9.2.1.7 last week and started having strange issues accessing my CIFS shares. What's happening is if I try to UNC into my freenas (e.g. \\nas\share), I get prompted for a username/password. My Freenas is joined to an Active Directory domain. I've been lurking the forum for answers and found that I can access the shares via IP. I took this one step further and deleted the DNS records (Host A) for my FreeNAS server on the DNS server. With the entries deleted I can now access the shares via the hostname of my FreeNAS.

Just for kicks I have unjoined/joined my FreeNAS to my domain multiple times and the issue persists. Joining the domain automatically registers a Host (A) entry on my DNS server. This of course breaks accessing FreeNAS via hostname. I am able to fix/break this issue by creating/deleting the host name entries in DNS.

I have also done a fresh install of 9.2.1.7 on a VirtualBox VM and the same issue occurs.

Strange stuff... It wasn't doing this pre-9.2.1.7.

 

[dlavigne]

Joining the domain automatically registers a Host (A) entry on my DNS server. This of course breaks accessing FreeNAS via hostname

This part is confusing, can you clarify?

 

[wintermute000]

Maybe it's lost the dns suffix during the upgrade or even doing since kind of double suffix

 

[socos]

This part is confusing, can you clarify?

In a Windows domain environment, when you join a machine to the domain a machine object is created in active directory. In addition, if you have DNS Server role installed on a domain controller, a DNS record is created for the machine as well. These can be deleted and created manually but I guess Windows is being "nice" by creating it for you.

As I mentioned in the original post. For some reason having this entry kills my ability to access my CIFS shares using the FreeNAS hostname. IP address works fine though.

 

[anodos]

I have 9.2.1.7 configured as an AD member server and do not have this problem. There should be a DNS entry for your FreeNAS server. The issue may be with how your AD is configured. Is your workstation able to ping your FreeNAS server by FQDN? Is your FreeNAS server able to ping workstation and DC by FQDN? If you run "net view" from cmd on Windows workstation does your FreeNAS server appear?

 

[socos]

I have 9.2.1.7 configured as an AD member server and do not have this problem. There should be a DNS entry for your FreeNAS server. The issue may be with how your AD is configured. Is your workstation able to ping your FreeNAS server by FQDN? Is your FreeNAS server able to ping workstation and DC by FQDN? If you run "net view" from cmd on Windows workstation does your FreeNAS server appear?

Is your workstation able to ping your FreeNAS server by FQDN?

Yes, if the DNS entry for the FreeNAS exists. No, when the entry is deleted. With the entry deleted, I can still ping it by hostname (non-FQDN)

Is your FreeNAS server able to ping workstation and DC by FQDN?

Yes, deleted entry or not.

If you run "net view" from cmd on Windows workstation does your FreeNAS server appear?

Yes

 

[socos]

Maybe it's lost the dns suffix during the upgrade or even doing since kind of double suffix

I checked the /etc/resolv.conf file on the FreeNAS server and it's fine. I can also ping machines on the domain from FreeNAS and it is appending the proper suffix.

 

[wintermute000]

hmm it doesn't make sense does it.
The fact that deleting the A record from AD fixes it implies that the A record is involved in some kind of DNS lookup, which is breaking.
However if the A record is valid and correct then how can it break samba?
I don't know too much about the auth mechanism in an AD environment, I'd start debugging those logs

 

[socos]

hmm it doesn't make sense does it.
The fact that deleting the A record from AD fixes it implies that the A record is involved in some kind of DNS lookup, which is breaking.
However if the A record is valid and correct then how can it break samba?
I don't know too much about the auth mechanism in an AD environment, I'd start debugging those logs

Yeah, it's the opposite of what should be happening. I won't rule out that it's something on my domain. But it is pretty bizarre. The fact that the same behavior happens on a freshly installed VM of FreeNAS points towards the domain as well. I would try an older version but you guys are running 9.2.1.7 with AD without issues.

 

[anodos]

I've seen instances where name resolution wasn't working properly. I traced it down to erroneous A record entries on the DC.
Specifically, the FreeNAS server's A record pointed to the DC's IP address instead of pointing to the FreeNAS server's IP address. i.e.

Code:

DC001   192.168.0.250
FreeNAS 192.168.0.250

I'm not sure how it happened because I wasn't the one doing the domain join. Needless to say, name resolution wasn't working properly for the FreeNAS server. You may want to review entries in your forward lookup zone. You may also want to perform an nmap scan against the FQDN of the FreeNAS to verify that it is the right computer. Assuming you have a reverse lookup zone configured, you may want to also do an nslookup on the FreeNAS server's IP address.

 

[socos]

Alright I just looked at my log.smbd file and I see an awful lot of these:

[2014/09/03 20:55:57.852677, 1] ../auth/gensec/spnego.c:573(gensec_spnego_parse_negTokenInit)
SPNEGO(gse_krb5) NEG_TOKEN_INIT failed: NT_STATUS_LOGON_FAILURE

These errors coincide with when I have a DNS host entry present for FreeNAS. They stop when I delete the entry. Googled around a bit and it's pretty much greek.

 

[mjws00]

Kerberos token error of some sort. Hopefully a samba wizard will chime in.

 

[socos]

More weirdness to throw in the mix... Adding my FreeNAS into the hosts file on a Windows client allows access via hostname (e.g \\nas\share). I tried adding FQDN of FreeNAS into the hosts file but it prompts for username/password when I try to access the share. (That's the original problem)