using samba in a domain environment

I am having problems getting Samba to authenticate AD users to Samba shares. Since I need to get our file server back online I think I will just run Samba as a standalone server. The problem with that is I have a AD domain so I have some concerns. First off can Samba serve files to users that are part of a domain without the Samba server having to join the domain? Also how are passwords handled when the user changes there password I assume that it would also have to be changed on the Samba server?

As long as the username and password are exactly the same then yes it will allow then to access the shares with the permissions granted to the local users of the same name.

Passwords would have to be manually synced yes.

What is the issue you are having?

I am using Windows 2012 domain controllers. The problem is I can't get Samba to authenticate using AD user names or groups all shares come back with access denied. I can log in using kinit and verify that I get a kerberos ticket. I also have verified that the file server gives out a kerberos ticket when trying to access the share from the windows 7 systems. Whenever I try to access the share from a Windows box via \\machinename, FQDN or just by typing the ip address I get access denied. I create a test share on the Linux box \data\files I did a chgrp on \data\files giving domain users ownership I than ran a chmod 777 \data\files still nothing. Also I can run getent on passwords and groups and it returns. I'm new to Limux so I don't really no all the troubleshooting steps for something like this. As of this morning Winbind will no longer start I am tempted to blow away the install and just start fresh.

krb5.conf

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = testdomain.LAN
default_tgs_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
default_tkt_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
preferred_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
dns_lookup_realm = false
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true

[realms]
EXAMPLE.COM = {
kdc = kerberos.example.com


nsswitch.conf

#netmasks: nisplus [NOTFOUND=return] files

bootparams: nisplus [NOTFOUND=return] files

ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: files

netgroup: files

publickey: nisplus

automount: files
aliases: files nisplus



samba
[global]
workgroup = TESTDOMAIN
realm = TESTDOMAIN.LAN
security = ads
encrypt passwords = yes
idmap config * : range = 16777216-33554431
template shell = /bin/false
winbind use default domain = false
winbind offline logon = false



[Files]
comment = file share
path = /data/files
writeable = yes
valid users = TESTDOMAIN\domain users

I assume that it is denying you at the point of trying to browse the share? Rather than when trying to create or read files?

It'll be share level permissions stopping you which is the valid users option on the share. iirc you can omit the option to open the share to everyone when you specify a unix group then it has to be prefixed with @, also when using spaces in a linux config file they tend to have to be enclosed by quotation marks to escape the space. As it would read that line as two seperate users/groups Testdomain\domain and users.

I'd be pretty confident that that is your problem just need some googlefoo to double check how to specify domain accounts, it could be possible that you have use the sid.

Can't be anymore specific as I haven't used share level permissions at all and just use the filesystem permissions to control share access.

"Can't be anymore specific as I haven't used share level permissions at all and just use the filesystem permissions to control share access. " Ok you are basically giving everyone full access at the share level than lock them down via regular linux permissions.

Yep pretty much, although I think that you'd be able to get share level perms working if you can doublecheck the correct way to specify domain accounts/groups.

The file permissions are posix acls.