Mounting a DFS share requires winbind (or so I think).
Getting rid of Avahi-daemon
This is unrelated to the matter at hand, but lest I forget: the test domain ends in “.local”, and is thus incompatible with avahi
(see .
apprentice@testbox:~$ dpkg -l \*avahi\*|grep ^ii|awk '{print $2}'|grep ^avahi|xargs sudo apt-get remove -y
apprentice@testbox:~$ sudo apt-get remove nscd
Note | |
---|---|
Winbind also claims to be incompatible with the Name Service Caching Daemon, but the |
Installing WinBind
Winbind “integrates authentication and directory service (user/group lookup) mechanisms from a Windows domain on a Linux system”. It also offers NetBIOS name lookup, and the AD server may resolve hostnames as well. We install it.
Installing the Winbind package
apprentice@linux-pc:~$ sudo apt-get install winbind
<snip>
Setting up winbind (2:3.4.7~dfsg-1ubuntu3.8) ...
* Starting the Winbind daemon winbind
...done.
But when we look with ps whether winbindd
is running, it isn't.
Configuring Winbind itself
Winbind is configured through /etc/samba/smb.conf
.
There is a rather elaborate smb.conf that comes with the distro, and we don't want to damage that too much.
So we patch it with smb.conf.winprogress
:
--- /etc/samba/smb.conf 2011-11-23 11:55:35.000000000 +0100 +++ ./smb.conf 2011-11-17 15:18:44.000000000 +0100 @@ -28,6 +28,7 @@ # where using a master file is not a good idea. # + #======================= Global Settings ======================= [global] @@ -35,7 +36,10 @@ ## Browsing/Identification ### # Change this to the workgroup/NT-domain name your Samba server will part of - workgroup = WORKGROUP +# begin -- JB 20111117 -- +# note that workgroup is the 'short' domain name + workgroup = WINPROGRESS +# end -- JB 20111117 -- # server string is the equivalent of the NT Description field server string = %h server (Samba, Ubuntu) @@ -100,6 +104,19 @@ # /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/ServerType.html # in the samba-doc package for details. # security = user +#begin -- JB20111117 -- + security = ads + realm = WINPROGRESS.LOCAL + password server = 192.168.127.201 192.168.127.202 + template homedir = /home/%D/%U + template shell = /bin/bash + client use spnego = yes + client ntlmv2 auth = yes +# default to true already -JB + encrypt passwords = yes + winbind use default domain = yes + restrict anonymous = 2 +#end -- JB20111117 -- # You may wish to use password encryption. See the section on # 'encrypt passwords' in the smb.conf(5) manpage before enabling. @@ -220,6 +237,10 @@ ; idmap uid = 10000-20000 ; idmap gid = 10000-20000 ; template shell = /bin/bash +# begin -- JB20111117 + idmap uid = 10000-20000 + idmap gid = 10000-20000 +# end -- JB20111117 # The following was the default behaviour in sarge, # but samba upstream reverted the default because it might induce @@ -228,6 +249,11 @@ # having this setting and smb.conf(5) for details. ; winbind enum groups = yes ; winbind enum users = yes +# begin -- JB20111117 +# winbind separator = + + winbind enum users = yes + winbind enum groups = yes +# end -- JB20111117 # Setup usershare options to enable non-root users to share folders # with the net usershare command.
apprentice@linux-pc:/etc/samba$ sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.dist
apprentice@linux-pc:/etc/samba$ sudo patch /etc/samba/smb.conf < smb.conf.winprogress
patching file /etc/samba/smb.conf
Rebooting (for lack of better measures)
At this point, I'm sure there is a combination of reloads that will get us out of the woods, but I'm unable to find it quickly, and I'm unable to either start winbind
or join the AD domain, until I reboot the PC, and then suddenly I am able to do both:
apprentice@linux-pc:~$ sudo net ads join -U SomeAdmin%VerySecretPasswd
Using short domain name -- WINPROGRESS
Joined 'CIT-CRS-71-28' to realm 'winprogress.local'
DNS update failed!
apprentice@linux-pc:~$ ps axu|egrep -i [w]inbind
apprentice@linux-pc:~$ sudo /etc/init.d/winbind start
* Starting the Winbind daemon winbind
...done.
apprentice@linux-pc:~$ ps axu|egrep -i [w]inbind
root 28701 1.0 0.0 66272 3132 ? Ss 20:37 0:00 /usr/sbin/winbindd
root 28702 1.5 0.0 70496 3728 ? S 20:37 0:00 /usr/sbin/winbindd
apprentice@linux-pc:~$ sudo tail /var/log/samba/log.winbindd
initialize_winbindd_cache: clearing cache and re-creating with version number 1
[2011/11/23 16:41:12, 0] winbindd/winbindd_util.c:782(init_domain_list)
Could not fetch our SID - did we join?
[2011/11/23 16:41:12, 0] winbindd/winbindd.c:1399(main)
unable to initialize domain list
[2011/11/23 20:37:40, 0] winbindd/winbindd.c:1258(main)
winbindd version 3.4.7 started.
Copyright Andrew Tridgell and the Samba Team 1992-2009
[2011/11/23 20:37:40, 0] winbindd/winbindd_cache.c:2578(initialize_winbindd_cache)
initialize_winbindd_cache: clearing cache and re-creating with version number 1
Note | |
---|---|
By this point, sudo is very slow when it has to ask for a password. This is because sudo's PAM configuration doesn't translate the username 'apprentice' to the AD/Kerberos principal name 'SomeAdmin'. Presumably, this can be solved by reconfiguring idmapd. I didn't bother though, and just started a root shell. Yet the command that require root are still prefixed with 'sudo' in these notes. |
Getting closer
apprentice@linux-pc:~$ mount.cifs //winprogress.local/uwp2.0 /admin/apprentice/myShared -o domain=WINPROGRESS,user='SomeAdmin@WINPROGRESS.LOCAL',sec=krb5
mount error(95): Operation not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
So we try “krb5i”:
apprentice@linux-pc:~$ mount.cifs //winprogress.local/uwp2.0 /admin/apprentice/myShared -o domain=WINPROGRESS,user='SomeAdmin@WINPROGRESS.LOCAL',sec=krb5i
mount error(126): Required key not available
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
From the wireshark sniff, we gather that the Linux box is asking for a ticket to cifs/winprogress.local
or host/winprogress.local
, neither of which exists.
Creating the missing principal
It would be nice it the cifs client could be configured to use an arbitrary principal for any given client, but according to this thread there is good reason not to allow that.
If it can be done, my guess is that /etc/request-key.conf
is the place to start, but I haven't dived in.
I just asked for the principal to be created on the Windows AD server, which he did.