[Samba] Cannot access shared home directories from linux machine

[Rowland Penny]

On 10/07/14 16:17, isofx wrote:
> Am 05.07.2014 15:33, schrieb steve:
>> On Thu, 2014-07-03 at 14:46 +0200, L.P.H. van Belle wrote:
>>> i see :
>>>
>>>> other::---
>>>
>>> what are the rights on
>>> /home
>>> and
>>> /home/DOMAIN
>>>
>>> try set it in linux on 755 ( both )
>>> and try again.
>
> root at dc01:/media/data01# ls -lha
> drwxr-xr-x 4 root root 4,0K Jul 3 11:05 .
> drwxr-xr-x 4 root root 4,0K Jun 28 16:15 ..
> drwxrwxr-x+ 3 root root 4,0K Jul 3 13:53 home
>
> root at dc01:/media/data01/home# ls -lha
> insgesamt 20K
> drwxrwxr-x+ 3 root root 4,0K Jul 3 13:53 .
> drwxr-xr-x 4 root root 4,0K Jul 3 11:05 ..
> drwxrwxr-x+ 2 3000000 users 4,0K Jul 10 15:53 demo
>
> I set the permission to 755 and ssh with domain accounts is now 
> possible. However there's still a problem with the permissions as the 
> users can't write to their own home-directory:
>
> login as: demo
> demo at 192.168.10.53's password:
> Linux ts01 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64
>
> The programs included with the Debian GNU/Linux system are free software;
> the exact distribution terms for each program are described in the
> individual files in /usr/share/doc/*/copyright.
>
> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
> permitted by applicable law.
> Last login: Thu Jul 10 15:33:37 2014 from 192.168.49.112
> demo at ts01:~$
> demo at ts01:~$ pwd
> /home/DOMAIN/demo
> demo at ts01:~$ mkdir test
> mkdir: cannot create directory „test“ : Permission Denied
>> -----Oorspronkelijk bericht-----
>> Van: ea4ml3f at gmx.at [mailto:samba-bounces at lists.samba.org] Namens isofx
>> Verzonden: donderdag 3 juli 2014 14:35
>> Aan: samba at lists.samba.org
>> Onderwerp: [Samba] Cannot access shared home directories from
>> linux machine
>>
>> Hi,
>>
>> I configured a share for home-directories on my Debian Samba
>> PDC (4.1.9)
>> and connected the share on another linux machine (terminal server) via
>> /etc/fstab:
>>
>> //192.168.10.51/home /home/DOMAIN/ cifs
>> credentials=/root/.smbcredentials,iocharset=utf8 0 0
>>
>> The .smbcredentials file contains the Domain Administrators
>> username/password. The share is mounted successfully, however
>> users can
>> not log into their home directories.
>>
>> Nope, I don't think you can. Before commiting to /etc/fstab, make sure
>> you can mount it manually on the DC:
>> (lose the ts for a while and work on the DC. Assuming you are on the DC
>> called ts01.domain.intern)
>
> I'm a little confused. I've got these two machines:
>
> dc01.domain.intern ... the domain controller running samba 4
> ts01.domain.intern ... the terminal server mounting the share via 
> /etc/fstab
>
> On which machine do you want me to execute the commands?
>
>> 1. make sure you have a recent cifs-utils installed
>
> root at dc01:/media/data01/home# apt-cache policy cifs-utils
> cifs-utils:
> Installed: 2:5.5-1
> Candidate: 2:5.5-1
> Version table:
> *** 2:5.5-1 0
> 500 http://ftp.at.debian.org/debian/ wheezy/main amd64 Packages
> 100 /var/lib/dpkg/status
>
>> 2. samba-tool domain exportkeytab /etc/krb5.keytab --principal=TS01$
>
> I did this on dc01.domain.intern
>
>> 3. mount -t cifs //ts01.domain.intern/home /mnt -osec=krb5,username=TS01
>> $
>
> root at dc01:/media/data01/home# mount -t cifs //dc01.domain.intern/home 
> /mnt -osec=krb5,username=TS01$
>
> This worked fine:
>
> root at dc01:/media/data01/home# cd /mnt/
> root at dc01:/mnt# ls
> demo
>
>> what do you have in /etc/request-key.conf
>> We can get it working as you wish when we know the dns and krb5 stuff is
>> OK.
>> HTH
>> Steve
>>
>
> There's no /etc/request-key.conf on the dc01, here's the output for ts01:
>
> #OP TYPE DESCRIPTION CALLOUT INFO PROGRAM ARG1 ARG2 ARG3 ...
> #====== ======= =============== =============== 
> ===============================
> create dns_resolver * * /sbin/key.dns_resolver %k
> create user debug:* negate /bin/keyctl negate %k 30 %S
> create user debug:* rejected /bin/keyctl reject %k 30 %c %S
> create user debug:* expired /bin/keyctl reject %k 30 %c %S
> create user debug:* revoked /bin/keyctl reject %k 30 %c %S
> create user debug:loop:* * |/bin/cat
> create user debug:* * /usr/share/keyutils/request-key-debug.sh %k %d 
> %c %S
> create cifs.spnego * * /usr/sbin/cifs.upcall -c %k
> create dns_resolver * * /usr/sbin/cifs.upcall %k
> negate * * * /bin/keyctl negate %k 30 %S
>
> Here's the output in /var/log/auth.log when logging in via ssh as demo 
> (domain user):
>
> Jul 10 16:43:04 ts01 sshd[12571]: pam_winbind(sshd:auth): getting 
> password (0x00000000)
> Jul 10 16:43:04 ts01 sshd[12571]: pam_winbind(sshd:auth): user 'demo' 
> granted access
> Jul 10 16:43:04 ts01 sshd[12571]: Accepted password for demo from 
> 192.168.49.112 port 28015 ssh2
> Jul 10 16:43:04 ts01 sshd[12571]: pam_unix(sshd:session): session 
> opened for user demo by (uid=0)
>
> I begin to think there's either a problem with PAM or Kerberos. Here's 
> the /etc/pam.d/common-auth for ts01:
>
> auth sufficient pam_winbind.so
>
> auth [success=2 default=ignore] pam_unix.so nullok_secure
> auth [success=1 default=ignore] pam_winbind.so krb5_auth 
> krb5_ccache_type=FILE cached_login try_first_pass
>
> auth requisite pam_deny.so
> auth required pam_permit.so
> auth optional pam_cap.so
>
> The configuration was mostly created by pam-auth-update after 
> installing winbind. However, I needed to add the first line - 
> otherwise domain users are not able to login (not even via SSH).
>
> Here's the /var/log/auth.log output for a failed login in without the 
> "auth sufficient pam_winbind.so" line:
>
> Jul 10 17:10:08 ts01 sshd[20427]: pam_unix(sshd:auth): authentication 
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.49.112 
> user=demo
> Jul 10 17:10:08 ts01 sshd[20427]: pam_winbind(sshd:auth): getting 
> password (0x00000388)
> Jul 10 17:10:08 ts01 sshd[20427]: pam_winbind(sshd:auth): pam_get_item 
> returned a password
> Jul 10 17:10:08 ts01 sshd[20427]: pam_winbind(sshd:auth): request 
> wbcLogonUser failed: WBC_ERR_AUTH_ERROR, PAM error: PAM_SYSTEM_ERR 
> (4), NTSTATUS: NT_STATUS_CONNECTION_DISCONNECTED, Error message was: 
> NT_STATUS_CONNECTION_DISCONNECTED
> Jul 10 17:10:08 ts01 sshd[20427]: pam_winbind(sshd:auth): internal 
> module error (retval = PAM_SYSTEM_ERR(4), user = 'demo')
> Jul 10 17:10:11 ts01 sshd[20427]: Failed password for demo from 
> 192.168.49.112 port 28118 ssh2
> Jul 10 17:10:12 ts01 sshd[20427]: Received disconnect from 
> 192.168.49.112: 13: Unable to authenticate [preauth]
>
> Best regards,
> Rainhard
>
Hi, you seem to be using the 'rid' backend on the machine you are trying 
to connect from:

idmap config * : backend = rid
idmap config * : range = 10000 - 49999
idmap uid = 50000 - 100000
idmap gid = 50000 - 100000

Doing this will ensure that you will definitely get a different id 
number for the user on the client against the one that they will have on 
the Samba4 server (incidentally, you are running an AD DC not a NT style 
PDC). I would suggest that you give your users & groups uid & gidNumbers 
and set the client to use these.

Once this is setup, you should be able to connect via smbclient etc to 
the server, once this is working, you can move onto the cifs setup.

Just what OS is the client running? idmap uid & gid where replaced some 
time ago.

Rowland