Trying to mount a DFS share

Mounting a DFS share requires winbind (or so I think).

  1. 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 .

    [Note]Note

    Winbind also claims to be incompatible with the Name Service Caching Daemon, but the nscd is not in the Conflicts: list of the package. It wasn't on my system though, so I didn't have to remove it anyway.

  2. 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.

    1. Installing the Winbind package

      But when we look with ps whether winbindd is running, it isn't.

    2. 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.
      	      

    3. 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:

      [Note]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.

  3. Getting closer

    So we try krb5i:

    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.

  4. 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.