| Mounting a Windows share from Debian/Ubuntu Linux, using AD authentication | ||
|---|---|---|
 | Linux Authenticating against Active Directory |  |
| Mounting a Windows share from Debian/Ubuntu Linux, using AD authentication | ||
|---|---|---|
| | Linux Authenticating against Active Directory | |
DFS demands additional configuration (on the Windows side), so we try without it first:
Fix domain search
My Windows colleagues frequently use short share names for their servers, using just the host name instead of the FQDN. This works for them, even though their clients are not in the same DNS domain as their servers. See Domain Search Override for how to do this on Ubuntu.
apprentice@clnt-3-53:~$ sudo -s # working as root is easier here
root@clnt-3-53:~# kdestroy # to demonstrate that there are no hidden keys
root@clnt-3-53:~# kinit U1234567@WSPACE.MYDOMAIN.NL
U1234567@WSPACE.MYDOMAIN.NL's Password:
root@clnt-3-53:~# mount -t cifs //just-a-pc.ict.mydomain.org/testshare /mnt/ -o sec=krb5
root@clnt-3-53:~# mount -t cifs
//just-a-pc.ict.mydomain.org/testshare on /mnt type cifs (rw)
root@clnt-3-53:~# find /mnt/
/mnt/
/mnt/test
/mnt/test/New folder
root@clnt-3-53:~#
Kerberos enctypes
Not using the right Kerberos encryption types will get you Required keys not available no matter what you do.
The admin of the Active Directory server I'm talking to figured out which types are supported by the Windows Server 2008 R2 he's using.
And the error disappeared as soon as I put the following in /etc/krb.conf under [libdefaults]:
default_tgs_enctypes = AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96 RC4-HMAC
default_tkt_enctypes = AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96 RC4-HMAC
permitted_enctypes = AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96 RC4-HMAC
![[Note]](http://jurjenbokma.com/ApprenticesNotes/images/admon/note.png) | Note |
|---|---|
I'm aware that this conflicts with what I say further down for the NFS client. I still have to figure out whether there is a setting that works for both. I'm guessing now that the one I give here will work for both. |
Share server Kerberos principal
The server needs to have a Kerberos principal. You can try whether the principal actually exists with
root@clnt-3-53:~# kgetcred cifs/SMBSERVER.wspace.mydomain.com@WSPACE.MYDOMAIN.NL
root@clnt-3-53:~# klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: U1234567@WSPACE.MYDOMAIN.NL
Issued Expires Principal
May 24 08:52:13 2012 May 24 18:52:04 2012 krbtgt/WSPACE.MYDOMAIN.NL@WSPACE.MYDOMAIN.NL
May 24 08:52:04 2012 May 24 18:52:04 2012 cifs/SMBSERVER.wspace.mydomain.com@WSPACE.MYDOMAIN.NL
If you cannot get credentials for the server, your enctype preferences may be malconfigured (see the above step), or perhaps the server doesn't have a servicePrincipalName, which you can verify with ldapsearch.
| Note |
|---|---|
There was a warnign here that I didn't have this working yet. The warning is now gone. I 've got it working. |
The procedure is the same as for a share with no DFS (above).
But there are two extra restrictions.
First, each of the servers involved needs to accept Kerberos tickets for the cifs service.
And second, they must agree on packet signing.
If one does and another doesn't, it won't work.
Microsoft clients don't have a problem with a DFS root that has SMB signing switched off published through another server that demands it.
But mount.cifs does.
According to Wikipedia on SMB, packet signing is default on on DC, but not on 2008 Server in general.
1. |
Mounting a share on the DFS root server succeeds with |
That is a dead-on symptom of servers in the DFS path not agreeing on SMB Packet Signing. See above. I found two technet articles on signing related to policies which my MS admin found helpful. | |
2. | Mounting an SMB share fails if I don't set the uid in the mount command. With uid set will let that user write:
But it looks as if all files on the share are owned by that single user. And I know that isn't so. |
You are probably using a Windows-based CIFS/SMB server, not Samba. UID/GID information is not served by MS. Therefore, this is as good as it gets. |
A few loose notes pertaining to both DFS and non-DFS:
Mount.cifs shouldn't run suid root, so when started by the user, each share needs an entry in /etc/fstab, like these:
//workspace/MYDOMAIN /home/U1234567/myrug cifs users,sec=krb5i,servernetbiosname=wspace //bigsan.dt.mydomain.com/MYDOMAIN /home/U1234567/mycemc cifs users,sec=krb5
Using krb5 when only krb5i is available will get you 'protocol not supported'.
With a hostname like the first one, an entry in /etc/hosts is needed, since the DNS probably won't resolve it.
I think cifs.upcall now is notified by the kernel of the owner of the calling process, and figures out which credentials cache to pick based on that id and well known paths (in /tmp).
Still, it is hard for mount.cifs to figure out which credentials cache to use.
It may or may not help to put this in /etc/sudoers:
<snip> Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" <snip>
... and now that we 're at it, here is the /etc/sudoers snippet to allow anybody to run mount.cifs as root:
# allow anyone to mount without prompting for root password # this is NOT suitable for production ALL ALL = NOPASSWD:NOEXEC: /bin/mount, /bin/umount, /sbin/mount.cifs
When debugging credentials, set some debug flags in /proc/fs/cifs:
apprentice@clnt-3-53:~$ sudo sh -c "echo 1 > /proc/fs/cifs/DebugData"
apprentice@clnt-3-53:~$ sudo sh -c "echo 3 > /proc/fs/cifs/cifsFYI"
See the fs-cifs-README. This thread is nice when interpreting the debug logs.
The reason that mounting DFS shares fails, seems to be that the DFS end point doesn't accept Kerberos keys for its hostname.
Although through /proc/fs/cifs/SecurityFlags, one can configure what authentication to use with mount.cifs, even when I do:
root@clnt-3-53.ict.mydomain.com:~# echo 0x9 > /proc/fs/cifs/SecurityFlags
... mount.cifs will still try NTLM and other non-Kerberos methods unless I specify sec=krb of sec=krb5i.
But the settings in /proc/fs/cifs/SecurityFlags are being read, for the messaged logged change when I alter them.
| |  | |
| Joining an Active Directory domain with Debian/Ubuntu Linux |  | Ubuntu NFS4 server/client with AD Kerberos/LDAP |