CIFS share authentication only works with FQDN or ip not with domain name

[Linus Törngren]

I cannot get my FreeNAS server to authenticate when using my server name, nas. It does however work when I use the server IP to connect or the FQDN of the server.

I'm using the latest FreeNAS version and a Windows 7 machine to connect.

Clarification: I'm using Active Directory mode and have connected to my Windows Server 2012 DC. It works when I connect to \\nas.internal.t-net.se and \\172.30.0.240 but not when I connect to \\nas.

 

[rogerh]

What have you put as netbios name in the CIFS service dialogue? Do both machines have the same workgroup name?

 

[Linus Törngren]

Here's some pics. Settings for CIFS and Active Directory. I also ran a couple of nbtstat commands on my DC.

EDIT: Two from the client.

 

[rogerh]

Well, assuming they're on the same IP subnet, it should just work! Neither of them seem to be master browser though. If there are no other candidates it might be worth encouraging one or other of them to do this. No idea about Windows but man smb.conf tells you how to do that on Freenas.

 

[rogerh]

Sorry, what I wrote above is rubbish; I have discovered that AD is supposed to use DNS. The answer seems to be either to put the "nas" hostname in the 'hosts' file on Windows, or to put the relevant domain in the 'search domain' field on Windows. Either should give Windows the right IP when searching by hostname using DNS (assuming you must have an appropriate DNS server somewhere or else the FQDN wouldn't work).

 

[Linus Törngren]

I've tried adding dhcp option 119 to my domain controllers DHCP-server but it doesn't seem to work. It might be that NetBIOS is being used and that I'm on the same subnet. I do not have nor will I be having total control over the clients as they're joined to a different domain.

EDIT: Connecting with my Macbook Air works like a charm so I think it's something to do with how windows uses NetBIOS and DNS.

 

[rogerh]

Given the latest info, I'm totally out of my depth, I'm sorry to say. It seems complicated using AD if the clients are authenticated with a different server.

 

[Linus Törngren]

Thank you for your time rogerh, you've given me a couple of ideas at least. I'll continue to search for a solution.

Adding dhcp option 119 adds my domain to the domain search list but that doesn't seem to solve the problem. I'm thinking that maybe I need a WINS-proxy or server. The weird thing is that problem seems to be more with the relation of my client and domain controller than the relation of my client and nas.

 

[Linus Törngren]

I'm cautiously optimistic that I might have solved the issue. I used net use /delete to remove all connectons to my nas. I then tried to connect using net use \\nas /user:T-NET\lintor and after password verificaton it seems I can now connect.

I'm not sure exactly why it works...

 

[rogerh]

Well done! Seems to be a mix of domain authentication and password authentication, quite complicated.

 

[cyberjock]

I always use net use /delete * when having problems. It's the only way to completely rule out authentication problems on Windows.

The problem is that Windows will only let you connect to a given machine with a single login. So if your first login was as a guest user (which may auto-authenticate thanks to Windows) you'll be boned until reboot. Of course, if it is automatically authenticating, once you reboot (or relog) you'll end up there all over again.

So I always use net use /delete and net use <blah bla blah> to mount my shares. It's the only way to be 100% sure that the account and credentials you are desiring to use are actually being used. I cover this in my permissions guide that is in the works. :P

For those that aren't domain admins, common login scripts use net use to mount your shares on bootup.

 

[Linus Törngren]

I've also discovered that changing the Windows ACLs with the Computer Management tool is very prone to lock outs and such. It seems it somehow affects the underlying folder permissions. Then the dataset is ruined since I'm not allowed to change permissions.

 

[anodos]

I think compmgmt.msc modifies the per-share access controls. Samba stores the per-share access control settings in a file called share_info.tdb. You can use tdbtool to verify whether entries have been written to it. If you have accidentally written to the tdb file, you might be able to fix the problem by deleting the CIFS share in the FreeNAS GUI (not the underlying dataset) and recreating it. But it might also be good to see what you've done with the underlying permissions of the share. Post the output of "getfacl /mnt/[pool]/[dataset]" for the share that's causing problems.

The best way to configure permissions is through the "security" tab in explorer.