Comment 66 for bug 207072

darkrain42, I've had an opportunity to review your patch, and it looks altogether correct to me (with one quibble over the error message presented on authentication failure). Although upstream has expressed concern about code duplication in the implementation, the two backends already share more than half their code, and this patch brings them closer to parity. Eliminating this code duplication is not something we should strive for in an SRU; though for my part, I wonder why this was ever done as two separate backends in the first place given the obvious overlap.

However, even with this patch applied, I don't see correct behavior for the share list when trying to connect to a samba server joined to an AD realm.

TEST CASE:

1. install the samba, smbclient, and winbind packages.
2. configure your system to act as a member of an AD realm, and enable the [homes] autoshares; e.g., in smb.conf:
  [global]
        workgroup = CANONICAL
        realm = CANONICAL.LOCAL
        security = ADS
        idmap backend = tdb
        idmap uid = 10000-20000
        idmap gid = 10000-20000
        template shell = /bin/bash
  [homes]
        comment = Home Directories
        valid users = %S
        create mask = 0700
        directory mask = 0700
        browseable = No
3. join your machine to the AD realm with 'net ads join' (https://help.ubuntu.com/community/ActiveDirectoryWinbindHowto#head-bbf631898fac0418a653cae2f0d4a1344ca8dfc2)
4. sudo /etc/init.d/samba restart && sudo /etc/init.d/winbind restart
5. grab a Kerberos tgt for the account in the AD realm with the same name as your login user by running 'kinit'. (You do not have to configure your local machine for AD logins for this to work, but the username must match between the AD realm and your local system.)
6. test with smbclient that the home share for the user is visible; i.e., "smbclient -L localhost -k" should return in the list of shares a share with the same name as the user. (using "smbclient -L localhost -N", i.e., anonymous connections, the share will not be visible.)
7. test whether nautilus sees this same share by running 'nautilus smb://localhost/'.

EXPECTED RESULTS: gvfsd-smb-browse will transparently use the existing Kerberos credentials when retrieving the browse list for the server, and a folder will appear in nautilus with the same name as the user.

ACTUAL RESULTS: gvfsd-smb-browse fails to use the Kerberos credentials, and the user's home share does not appear in the list.