Steve, as described in comment 12, I'm using kerberos authentication inside an ADS network and I have no problems with nautilus and gvfs. However my setup is different from yours. The smb.conf is like this:
[global]
workgroup = LAB
realm = MYDOMAIN.COM
netbios name = %h-DEB
server string = %h-DEB (Samba %v, Ubuntu)
security = ADS
password server = dhcpias1.mydomain.com
restrict anonymous = 2
client NTLMv2 auth = Yes
client lanman auth = No
client plaintext auth = No
log file = /var/log/samba/log.%m
os level = 0
preferred master = No
local master = No
domain master = No
idmap domains = LAB
idmap config LAB: default = yes
idmap config LAB: backend = rid
idmap config LAB: range = 100000-1000000
template shell = /bin/bash
winbind separator = _
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes
winbind refresh tickets = Yes
winbind offline logon = Yes
invalid users = root
[Share]
comment = %h-DEB_Share
path = /home/LAB/adsusername/Share
valid users = LAB_adsusername, "@LAB_domain users", @users
force user = LAB_adsusername
read only = No
The PAM configuration has been changed by using this line in /etc/pam.d/common-auth:
This means that the login user is a domain user (not a local user) and that it automatically acquires a kerberos ticket.
With this setup I'm able to browse with nautilus all network shares (including the one of the local workstation) even without the gvfs patch from darkrain42. So it seems that in my case gvfs is correctly using kerberos credentials and I wonder if your problem may be related to something else than the gvfs patch.
If necessary, I can post the complete configuration of my workstation, but at the moment I will not be able to do other test inside the ADS network until next week.
Steve, as described in comment 12, I'm using kerberos authentication inside an ADS network and I have no problems with nautilus and gvfs. However my setup is different from yours. The smb.conf is like this:
[global] mydomain. com samba/log. %m adsusername/ Share
workgroup = LAB
realm = MYDOMAIN.COM
netbios name = %h-DEB
server string = %h-DEB (Samba %v, Ubuntu)
security = ADS
password server = dhcpias1.
restrict anonymous = 2
client NTLMv2 auth = Yes
client lanman auth = No
client plaintext auth = No
log file = /var/log/
os level = 0
preferred master = No
local master = No
domain master = No
idmap domains = LAB
idmap config LAB: default = yes
idmap config LAB: backend = rid
idmap config LAB: range = 100000-1000000
template shell = /bin/bash
winbind separator = _
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes
winbind refresh tickets = Yes
winbind offline logon = Yes
invalid users = root
[Share]
comment = %h-DEB_Share
path = /home/LAB/
valid users = LAB_adsusername, "@LAB_domain users", @users
force user = LAB_adsusername
read only = No
The PAM configuration has been changed by using this line in /etc/pam. d/common- auth:
auth sufficient pam_winbind.so krb5_auth krb5_ccache_ type=FILE cached_login
This means that the login user is a domain user (not a local user) and that it automatically acquires a kerberos ticket.
With this setup I'm able to browse with nautilus all network shares (including the one of the local workstation) even without the gvfs patch from darkrain42. So it seems that in my case gvfs is correctly using kerberos credentials and I wonder if your problem may be related to something else than the gvfs patch.
If necessary, I can post the complete configuration of my workstation, but at the moment I will not be able to do other test inside the ADS network until next week.