Hi, I have problem with mountning NFS4 file with Kerberos security ( I can mount without Kerberos security)
Both test machines run Ubuntu-saucy I have the nfs4 server which joined to AD with 'msktutil' : Server's /etc/krb5.keytab
klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 3 SERVER$@DOMAIN.ORG (arcfour-hmac) 3 SERVER$@DOMAIN.ORG (aes128-cts-hmac-sha1-96) 3 SERVER$@DOMAIN.ORG (aes256-cts-hmac-sha1-96) 3 host/server.domain.org@DOMAIN.ORG (arcfour-hmac) 3 host/server.domain.org@DOMAIN.ORG (aes128-cts-hmac-sha1-96) 3 host/server.domain.org@DOMAIN.ORG (aes256-cts-hmac-sha1-96) 3 nfs/server.domain.org@DOMAIN.ORG (arcfour-hmac) 3 nfs/server.domain.org@DOMAIN.ORG (aes128-cts-hmac-sha1-96) 3 nfs/server.domain.org@DOMAIN.ORG (aes256-cts-hmac-sha1-96)
Then, joined client machine to AD with 'realm' command:
alongina@client:~$ sudo realm join --verbose -U USER --computer-ou OU="Linux computers",OU=ADResources domain.org [sudo] password for alongina: * Resolving: _ldap._tcp.domain.org * Performing LDAP DSE lookup on: 10.144.5.17 * Performing LDAP DSE lookup on: 10.144.5.18 * Successfully discovered: domain.org Password for USER: * Unconditionally checking packages * Resolving required packages * Installing necessary packages: samba-common-bin * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.JAW8AX -U USER ads join domain.org createcomputer=ADResources/Linux computers Enter USER's password: DNS update failed! Using short domain name - AAA-BBB Joined 'CLIENT' to dns domain 'domain.org' No DNS domain configured for client. Unable to perform DNS Update. * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.JAW8AX -U USER ads keytab create Enter USER's password: * /usr/sbin/update-rc.d sssd enable update-rc.d: /etc/init.d/sssd: file does not exist * /usr/sbin/service sssd restart sssd stop/waiting sssd start/running, process 3597 * Successfully enrolled machine in realm
==============0000000========= klist -ke
Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 4 host/client.domain.org@DOMAIN.ORG (des-cbc-crc) 4 host/client.domain.org@DOMAIN.ORG (des-cbc-md5) 4 host/client.domain.org@DOMAIN.ORG (aes128-cts-hmac-sha1-96) 4 host/client.domain.org@DOMAIN.ORG (aes256-cts-hmac-sha1-96) 4 host/client.domain.org@DOMAIN.ORG (arcfour-hmac) 4 host/CLIENT@DOMAIN.ORG (des-cbc-crc) 4 host/CLIENT@DOMAIN.ORG (des-cbc-md5) 4 host/CLIENT@DOMAIN.ORG (aes128-cts-hmac-sha1-96) 4 host/CLIENT@DOMAIN.ORG (aes256-cts-hmac-sha1-96) 4 host/CLIENT@DOMAIN.ORG (arcfour-hmac) 4 CLIENT$@DOMAIN.ORG (des-cbc-crc) 4 CLIENT$@DOMAIN.ORG (des-cbc-md5) 4 CLIENT$@DOMAIN.ORG (aes128-cts-hmac-sha1-96) 4 CLIENT$@DOMAIN.ORG (aes256-cts-hmac-sha1-96) 4 CLIENT$@DOMAIN.ORG (arcfour-hmac)
=================================================================
root@client:/export/alongina# mount -t nfs4 server.domain.org:/nfs4/server /mnt/server -o sec=krb5 mount.nfs4: access denied by server while mounting server.domain.org:/nfs4/server
client: /var/log/syslog
eb 11 16:00:39 client rpc.gssd[708]: handling gssd upcall (/run/rpc_pipefs/nfs/clntb) Feb 11 16:00:39 client rpc.gssd[708]: handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 ' Feb 11 16:00:39 client rpc.gssd[708]: handling krb5 upcall (/run/rpc_pipefs/nfs/clntb) Feb 11 16:00:39 client rpc.gssd[708]: process_krb5_upcall: service is '<null>' Feb 11 16:00:39 client rpc.gssd[708]: Full hostname for 'server.domain.org' is 'server.domain.org' Feb 11 16:00:39 client rpc.gssd[708]: Full hostname for 'client.domain.org' is 'client.domain.org' Feb 11 16:00:39 client rpc.gssd[708]: No key table entry found for CLIENT.DOMAIN.ORG$@DOMAIN.ORG while getting keytab entry for 'CLIENT.DOMAIN.ORG$@DOMAIN.ORG' Feb 11 16:00:39 client rpc.gssd[708]: No key table entry found for root/client.domain.org@DOMAIN.ORG while getting keytab entry for 'root/client.domain.org@DOMAIN.ORG' Feb 11 16:00:39 client rpc.gssd[708]: No key table entry found for nfs/client.domain.org@DOMAIN.ORG while getting keytab entry for 'nfs/client.domain.org@DOMAIN.ORG' Feb 11 16:00:39 client rpc.gssd[708]: Success getting keytab entry for 'host/client.domain.org@DOMAIN.ORG' Feb 11 16:00:39 client rpc.gssd[708]: WARNING: Client not found in Kerberos database while getting initial ticket for principal 'host/client.domain.org@DOMAIN.ORG' using keytab 'FILE:/etc/krb5.keytab' Feb 11 16:00:39 client rpc.gssd[708]: ERROR: No credentials found for connection to server server.domain.org Feb 11 16:00:39 client rpc.gssd[708]: doing error downcall Is it mismatch with encryption typs? Problem with DNS ? Client machine is missing reverse addresse in DNS... host client.domain.org client.domain.org has address 10.80.8.54 -------------------- host 10.80.8.54 Host 54.8.80.10.in-addr.arpa. not found: 3(NXDOMAIN) Best longina
From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Ondrej Valousek Sent: 30. januar 2014 14:38 To: End-user discussions about the System Security Services Daemon Subject: Re: [SSSD-users] sssd-1.11.1 Saucy automount
That was me. Yes, autofs works with sssd having AD backend (and using RFC2307 schema). No blushing. ________________________________ From: sssd-users-bounces@lists.fedorahosted.orgmailto:sssd-users-bounces@lists.fedorahosted.org [sssd-users-bounces@lists.fedorahosted.org] on behalf of Chris Gray [fathed@gmail.com] Sent: Thursday, January 30, 2014 11:28 AM To: End-user discussions about the System Security Services Daemon Subject: Re: [SSSD-users] sssd-1.11.1 Saucy automount This person was able to setup autofs with sssd and samba as their AD server.
https://www.mail-archive.com/sssd-users@lists.fedorahosted.org/msg00810.html
I haven't tried this, but in theory if you make the right settings in MS AD and in the config files for autofs and sssd, it should work pretty much the same.
Since you have to specify where the ou for the automount base is in the autofs config files, you don't actually need to make the automount ou at the base level, but it's up to you and your ad structure on where you want to put it. Then as long as you have krb5, ldap, and everything set right, it should work for
Chris
On Wed, Jan 29, 2014 at 4:06 AM, Longina Przybyszewska <longina@sdu.dkmailto:longina@sdu.dk> wrote: Use case is - we work towards policy, accessing any resources from any platform. All users get per automatic windows share. Additionally, Linux users have primary homedir as nfs mounted share with automount/autofs+ NIs. Some enterprise services have access only to windows share.
Linux desktops, running sssd with AD-provider should be able access both shares.
Best Longina
Problem is here: Feb 11 16:00:39 client rpc.gssd[708]: WARNING: Client not found in Kerberos database while getting initial ticket for principal 'host/client.domain.org@DOMAIN.ORG' using keytab 'FILE:/etc/krb5.keytab' Rpc.gssd needs to use CLIENT$@domain.org Krb5 principal. And yes, reverse DNS records would be nice :) HTH,
Ondrej
________________________________ From: sssd-users-bounces@lists.fedorahosted.org [sssd-users-bounces@lists.fedorahosted.org] on behalf of Longina Przybyszewska [longina@sdu.dk] Sent: Tuesday, February 11, 2014 5:00 PM To: 'End-user discussions about the System Security Services Daemon' Subject: Re: [SSSD-users] sssd-1.11.1 Saucy automount(nfs4+krb problem)
Hi, I have problem with mountning NFS4 file with Kerberos security ( I can mount without Kerberos security)
Both test machines run Ubuntu-saucy I have the nfs4 server which joined to AD with ‘msktutil’ : Server’s /etc/krb5.keytab
klist –ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 3 SERVER$@DOMAIN.ORG (arcfour-hmac) 3 SERVER$@DOMAIN.ORG (aes128-cts-hmac-sha1-96) 3 SERVER$@DOMAIN.ORG (aes256-cts-hmac-sha1-96) 3 host/server.domain.org@DOMAIN.ORG (arcfour-hmac) 3 host/server.domain.org@DOMAIN.ORG (aes128-cts-hmac-sha1-96) 3 host/server.domain.org@DOMAIN.ORG (aes256-cts-hmac-sha1-96) 3 nfs/server.domain.org@DOMAIN.ORG (arcfour-hmac) 3 nfs/server.domain.org@DOMAIN.ORG (aes128-cts-hmac-sha1-96) 3 nfs/server.domain.org@DOMAIN.ORG (aes256-cts-hmac-sha1-96)
Then, joined client machine to AD with ‘realm’ command:
alongina@client:~$ sudo realm join --verbose -U USER --computer-ou OU="Linux computers",OU=ADResources domain.org [sudo] password for alongina: * Resolving: _ldap._tcp.domain.org * Performing LDAP DSE lookup on: 10.144.5.17 * Performing LDAP DSE lookup on: 10.144.5.18 * Successfully discovered: domain.org Password for USER: * Unconditionally checking packages * Resolving required packages * Installing necessary packages: samba-common-bin * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.JAW8AX -U USER ads join domain.org createcomputer=ADResources/Linux computers Enter USER's password: DNS update failed! Using short domain name – AAA-BBB Joined 'CLIENT' to dns domain 'domain.org' No DNS domain configured for client. Unable to perform DNS Update. * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.JAW8AX -U USER ads keytab create Enter USER's password: * /usr/sbin/update-rc.d sssd enable update-rc.d: /etc/init.d/sssd: file does not exist * /usr/sbin/service sssd restart sssd stop/waiting sssd start/running, process 3597 * Successfully enrolled machine in realm
==============0000000========= klist –ke
Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 4 host/client.domain.org@DOMAIN.ORG (des-cbc-crc) 4 host/client.domain.org@DOMAIN.ORG (des-cbc-md5) 4 host/client.domain.org@DOMAIN.ORG (aes128-cts-hmac-sha1-96) 4 host/client.domain.org@DOMAIN.ORG (aes256-cts-hmac-sha1-96) 4 host/client.domain.org@DOMAIN.ORG (arcfour-hmac) 4 host/CLIENT@DOMAIN.ORG (des-cbc-crc) 4 host/CLIENT@DOMAIN.ORG (des-cbc-md5) 4 host/CLIENT@DOMAIN.ORG (aes128-cts-hmac-sha1-96) 4 host/CLIENT@DOMAIN.ORG (aes256-cts-hmac-sha1-96) 4 host/CLIENT@DOMAIN.ORG (arcfour-hmac) 4 CLIENT$@DOMAIN.ORG (des-cbc-crc) 4 CLIENT$@DOMAIN.ORG (des-cbc-md5) 4 CLIENT$@DOMAIN.ORG (aes128-cts-hmac-sha1-96) 4 CLIENT$@DOMAIN.ORG (aes256-cts-hmac-sha1-96) 4 CLIENT$@DOMAIN.ORG (arcfour-hmac)
=================================================================
root@client:/export/alongina# mount -t nfs4 server.domain.org:/nfs4/server /mnt/server -o sec=krb5 mount.nfs4: access denied by server while mounting server.domain.org:/nfs4/server
client: /var/log/syslog
eb 11 16:00:39 client rpc.gssd[708]: handling gssd upcall (/run/rpc_pipefs/nfs/clntb) Feb 11 16:00:39 client rpc.gssd[708]: handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 ' Feb 11 16:00:39 client rpc.gssd[708]: handling krb5 upcall (/run/rpc_pipefs/nfs/clntb) Feb 11 16:00:39 client rpc.gssd[708]: process_krb5_upcall: service is '<null>' Feb 11 16:00:39 client rpc.gssd[708]: Full hostname for 'server.domain.org' is 'server.domain.org' Feb 11 16:00:39 client rpc.gssd[708]: Full hostname for 'client.domain.org' is 'client.domain.org' Feb 11 16:00:39 client rpc.gssd[708]: No key table entry found for CLIENT.DOMAIN.ORG$@DOMAIN.ORG while getting keytab entry for 'CLIENT.DOMAIN.ORG$@DOMAIN.ORG' Feb 11 16:00:39 client rpc.gssd[708]: No key table entry found for root/client.domain.org@DOMAIN.ORG while getting keytab entry for 'root/client.domain.org@DOMAIN.ORG' Feb 11 16:00:39 client rpc.gssd[708]: No key table entry found for nfs/client.domain.org@DOMAIN.ORG while getting keytab entry for 'nfs/client.domain.org@DOMAIN.ORG' Feb 11 16:00:39 client rpc.gssd[708]: Success getting keytab entry for 'host/client.domain.org@DOMAIN.ORG' Feb 11 16:00:39 client rpc.gssd[708]: WARNING: Client not found in Kerberos database while getting initial ticket for principal 'host/client.domain.org@DOMAIN.ORG' using keytab 'FILE:/etc/krb5.keytab' Feb 11 16:00:39 client rpc.gssd[708]: ERROR: No credentials found for connection to server server.domain.org Feb 11 16:00:39 client rpc.gssd[708]: doing error downcall Is it mismatch with encryption typs? Problem with DNS ? Client machine is missing reverse addresse in DNS… host client.domain.org client.domain.org has address 10.80.8.54 -------------------- host 10.80.8.54 Host 54.8.80.10.in-addr.arpa. not found: 3(NXDOMAIN) Best longina
From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Ondrej Valousek Sent: 30. januar 2014 14:38 To: End-user discussions about the System Security Services Daemon Subject: Re: [SSSD-users] sssd-1.11.1 Saucy automount
That was me. Yes, autofs works with sssd having AD backend (and using RFC2307 schema). No blushing. ________________________________ From: sssd-users-bounces@lists.fedorahosted.orgmailto:sssd-users-bounces@lists.fedorahosted.org [sssd-users-bounces@lists.fedorahosted.org] on behalf of Chris Gray [fathed@gmail.com] Sent: Thursday, January 30, 2014 11:28 AM To: End-user discussions about the System Security Services Daemon Subject: Re: [SSSD-users] sssd-1.11.1 Saucy automount This person was able to setup autofs with sssd and samba as their AD server.
https://www.mail-archive.com/sssd-users@lists.fedorahosted.org/msg00810.html
I haven't tried this, but in theory if you make the right settings in MS AD and in the config files for autofs and sssd, it should work pretty much the same.
Since you have to specify where the ou for the automount base is in the autofs config files, you don't actually need to make the automount ou at the base level, but it's up to you and your ad structure on where you want to put it. Then as long as you have krb5, ldap, and everything set right, it should work for
Chris
On Wed, Jan 29, 2014 at 4:06 AM, Longina Przybyszewska <longina@sdu.dkmailto:longina@sdu.dk> wrote: Use case is - we work towards policy, accessing any resources from any platform. All users get per automatic windows share. Additionally, Linux users have primary homedir as nfs mounted share with automount/autofs+ NIs. Some enterprise services have access only to windows share.
Linux desktops, running sssd with AD-provider should be able access both shares.
Best Longina
Got it. You need to use short hostname - i.e. hostname should return only "client", not "client.domain.org". O.
________________________________ From: sssd-users-bounces@lists.fedorahosted.org [sssd-users-bounces@lists.fedorahosted.org] on behalf of Ondrej Valousek Sent: Tuesday, February 11, 2014 6:22 PM To: End-user discussions about the System Security Services Daemon Subject: Re: [SSSD-users] sssd-1.11.1 Saucy automount(nfs4+krb problem)
Problem is here: Feb 11 16:00:39 client rpc.gssd[708]: WARNING: Client not found in Kerberos database while getting initial ticket for principal 'host/client.domain.org@DOMAIN.ORG' using keytab 'FILE:/etc/krb5.keytab' Rpc.gssd needs to use CLIENT$@domain.org Krb5 principal. And yes, reverse DNS records would be nice :) HTH,
Ondrej
________________________________ From: sssd-users-bounces@lists.fedorahosted.org [sssd-users-bounces@lists.fedorahosted.org] on behalf of Longina Przybyszewska [longina@sdu.dk] Sent: Tuesday, February 11, 2014 5:00 PM To: 'End-user discussions about the System Security Services Daemon' Subject: Re: [SSSD-users] sssd-1.11.1 Saucy automount(nfs4+krb problem)
Hi, I have problem with mountning NFS4 file with Kerberos security ( I can mount without Kerberos security)
Both test machines run Ubuntu-saucy I have the nfs4 server which joined to AD with ‘msktutil’ : Server’s /etc/krb5.keytab
klist –ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 3 SERVER$@DOMAIN.ORG (arcfour-hmac) 3 SERVER$@DOMAIN.ORG (aes128-cts-hmac-sha1-96) 3 SERVER$@DOMAIN.ORG (aes256-cts-hmac-sha1-96) 3 host/server.domain.org@DOMAIN.ORG (arcfour-hmac) 3 host/server.domain.org@DOMAIN.ORG (aes128-cts-hmac-sha1-96) 3 host/server.domain.org@DOMAIN.ORG (aes256-cts-hmac-sha1-96) 3 nfs/server.domain.org@DOMAIN.ORG (arcfour-hmac) 3 nfs/server.domain.org@DOMAIN.ORG (aes128-cts-hmac-sha1-96) 3 nfs/server.domain.org@DOMAIN.ORG (aes256-cts-hmac-sha1-96)
Then, joined client machine to AD with ‘realm’ command:
alongina@client:~$ sudo realm join --verbose -U USER --computer-ou OU="Linux computers",OU=ADResources domain.org [sudo] password for alongina: * Resolving: _ldap._tcp.domain.org * Performing LDAP DSE lookup on: 10.144.5.17 * Performing LDAP DSE lookup on: 10.144.5.18 * Successfully discovered: domain.org Password for USER: * Unconditionally checking packages * Resolving required packages * Installing necessary packages: samba-common-bin * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.JAW8AX -U USER ads join domain.org createcomputer=ADResources/Linux computers Enter USER's password: DNS update failed! Using short domain name – AAA-BBB Joined 'CLIENT' to dns domain 'domain.org' No DNS domain configured for client. Unable to perform DNS Update. * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.JAW8AX -U USER ads keytab create Enter USER's password: * /usr/sbin/update-rc.d sssd enable update-rc.d: /etc/init.d/sssd: file does not exist * /usr/sbin/service sssd restart sssd stop/waiting sssd start/running, process 3597 * Successfully enrolled machine in realm
==============0000000========= klist –ke
Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 4 host/client.domain.org@DOMAIN.ORG (des-cbc-crc) 4 host/client.domain.org@DOMAIN.ORG (des-cbc-md5) 4 host/client.domain.org@DOMAIN.ORG (aes128-cts-hmac-sha1-96) 4 host/client.domain.org@DOMAIN.ORG (aes256-cts-hmac-sha1-96) 4 host/client.domain.org@DOMAIN.ORG (arcfour-hmac) 4 host/CLIENT@DOMAIN.ORG (des-cbc-crc) 4 host/CLIENT@DOMAIN.ORG (des-cbc-md5) 4 host/CLIENT@DOMAIN.ORG (aes128-cts-hmac-sha1-96) 4 host/CLIENT@DOMAIN.ORG (aes256-cts-hmac-sha1-96) 4 host/CLIENT@DOMAIN.ORG (arcfour-hmac) 4 CLIENT$@DOMAIN.ORG (des-cbc-crc) 4 CLIENT$@DOMAIN.ORG (des-cbc-md5) 4 CLIENT$@DOMAIN.ORG (aes128-cts-hmac-sha1-96) 4 CLIENT$@DOMAIN.ORG (aes256-cts-hmac-sha1-96) 4 CLIENT$@DOMAIN.ORG (arcfour-hmac)
=================================================================
root@client:/export/alongina# mount -t nfs4 server.domain.org:/nfs4/server /mnt/server -o sec=krb5 mount.nfs4: access denied by server while mounting server.domain.org:/nfs4/server
client: /var/log/syslog
eb 11 16:00:39 client rpc.gssd[708]: handling gssd upcall (/run/rpc_pipefs/nfs/clntb) Feb 11 16:00:39 client rpc.gssd[708]: handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 ' Feb 11 16:00:39 client rpc.gssd[708]: handling krb5 upcall (/run/rpc_pipefs/nfs/clntb) Feb 11 16:00:39 client rpc.gssd[708]: process_krb5_upcall: service is '<null>' Feb 11 16:00:39 client rpc.gssd[708]: Full hostname for 'server.domain.org' is 'server.domain.org' Feb 11 16:00:39 client rpc.gssd[708]: Full hostname for 'client.domain.org' is 'client.domain.org' Feb 11 16:00:39 client rpc.gssd[708]: No key table entry found for CLIENT.DOMAIN.ORG$@DOMAIN.ORG while getting keytab entry for 'CLIENT.DOMAIN.ORG$@DOMAIN.ORG' Feb 11 16:00:39 client rpc.gssd[708]: No key table entry found for root/client.domain.org@DOMAIN.ORG while getting keytab entry for 'root/client.domain.org@DOMAIN.ORG' Feb 11 16:00:39 client rpc.gssd[708]: No key table entry found for nfs/client.domain.org@DOMAIN.ORG while getting keytab entry for 'nfs/client.domain.org@DOMAIN.ORG' Feb 11 16:00:39 client rpc.gssd[708]: Success getting keytab entry for 'host/client.domain.org@DOMAIN.ORG' Feb 11 16:00:39 client rpc.gssd[708]: WARNING: Client not found in Kerberos database while getting initial ticket for principal 'host/client.domain.org@DOMAIN.ORG' using keytab 'FILE:/etc/krb5.keytab' Feb 11 16:00:39 client rpc.gssd[708]: ERROR: No credentials found for connection to server server.domain.org Feb 11 16:00:39 client rpc.gssd[708]: doing error downcall Is it mismatch with encryption typs? Problem with DNS ? Client machine is missing reverse addresse in DNS… host client.domain.org client.domain.org has address 10.80.8.54 -------------------- host 10.80.8.54 Host 54.8.80.10.in-addr.arpa. not found: 3(NXDOMAIN) Best longina
From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Ondrej Valousek Sent: 30. januar 2014 14:38 To: End-user discussions about the System Security Services Daemon Subject: Re: [SSSD-users] sssd-1.11.1 Saucy automount
That was me. Yes, autofs works with sssd having AD backend (and using RFC2307 schema). No blushing. ________________________________ From: sssd-users-bounces@lists.fedorahosted.orgmailto:sssd-users-bounces@lists.fedorahosted.org [sssd-users-bounces@lists.fedorahosted.org] on behalf of Chris Gray [fathed@gmail.com] Sent: Thursday, January 30, 2014 11:28 AM To: End-user discussions about the System Security Services Daemon Subject: Re: [SSSD-users] sssd-1.11.1 Saucy automount This person was able to setup autofs with sssd and samba as their AD server.
https://www.mail-archive.com/sssd-users@lists.fedorahosted.org/msg00810.html
I haven't tried this, but in theory if you make the right settings in MS AD and in the config files for autofs and sssd, it should work pretty much the same.
Since you have to specify where the ou for the automount base is in the autofs config files, you don't actually need to make the automount ou at the base level, but it's up to you and your ad structure on where you want to put it. Then as long as you have krb5, ldap, and everything set right, it should work for
Chris
On Wed, Jan 29, 2014 at 4:06 AM, Longina Przybyszewska <longina@sdu.dkmailto:longina@sdu.dk> wrote: Use case is - we work towards policy, accessing any resources from any platform. All users get per automatic windows share. Additionally, Linux users have primary homedir as nfs mounted share with automount/autofs+ NIs. Some enterprise services have access only to windows share.
Linux desktops, running sssd with AD-provider should be able access both shares.
Best Longina
On Tue, 2014-02-11 at 17:27 +0000, Ondrej Valousek wrote:
Got it. You need to use short hostname - i.e. hostname should return only "client", not "client.domain.org". O.
This normally breaks other things, you should probably instead open a bug against nfs-utils so that they try to split the hostname along '.' before appending the $
I will ping Steve Dickson (mainatiner of nfs-utils) shortly about this, but filing a bug would help anyway.
Simo.
Strange, I am always using short hostnames and I did not come across any problems so far.
But in general I agree that nfs-utils should handle FQDN hostnames better. Ondrej
Odesláno ze Samsung Mobile
-------- Původní zpráva -------- Od: Simo Sorce Datum:11. 02. 2014 20:59 (GMT+01:00) Komu: End-user discussions about the System Security Services Daemon Předmět: Re: [SSSD-users] sssd-1.11.1 Saucy automount(nfs4+krb problem)
On Tue, 2014-02-11 at 17:27 +0000, Ondrej Valousek wrote:
Got it. You need to use short hostname - i.e. hostname should return only "client", not "client.domain.org". O.
This normally breaks other things, you should probably instead open a bug against nfs-utils so that they try to split the hostname along '.' before appending the $
I will ping Steve Dickson (mainatiner of nfs-utils) shortly about this, but filing a bug would help anyway.
Simo.
-- Simo Sorce * Red Hat, Inc * New York
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Thanks a lot.
I was more suspicious about the differences in joining AD between ‘msktutil’ and ‘realm’. With ‘realm’ there are more encryption types, and there is one more principal entry of host/CLIENT@DOMAIN.ORG Do I miss something in getting point here: If there is a key for the principal 'host/client.domain.org@DOMAIN.ORG' in local /etc/krb5.keytab - why there are no credentials in Kerberos database?
There are principals with short names as well
CLIENT$@DOMAIN.ORGmailto:CLIENT$@DOMAIN.ORG host/CLIENT@DOMAIN.ORGmailto:host/CLIENT@DOMAIN.ORG
Is this because for NFS4 service machine asks, there is need for credentials for machine principal, the one ending with “$”, and rpc.gssd asks about CLIENT.DOMAIN.ORG$@DOMAIN.ORGmailto:CLIENT.DOMAIN.ORG$@DOMAIN.ORG instead of CLIENT$@DOMAIN.ORG and that question depends on what ‘hostname’ returns?
=====
Feb 11 16:00:39 client rpc.gssd[708]: Success getting keytab entry for 'host/client.domain.org@DOMAIN.ORG' Feb 11 16:00:39 client rpc.gssd[708]: WARNING: Client not found in Kerberos database while getting initial ticket for principal 'host/client.domain.org@DOMAIN.ORG' using keytab 'FILE:/etc/krb5.keytab' Feb 11 16:00:39 client rpc.gssd[708]: ERROR: No credentials found for connection to server server.domain.org host 10.80.8.54 Host 54.8.80.10.in-addr.arpa. not found: 3(NXDOMAIN)
Best Longina From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Ondrej Valousek Sent: 11. februar 2014 22:34 To: End-user discussions about the System Security Services Daemon Subject: Re: [SSSD-users] sssd-1.11.1 Saucy automount(nfs4+krb problem)
Strange, I am always using short hostnames and I did not come across any problems so far.
But in general I agree that nfs-utils should handle FQDN hostnames better. Ondrej
Odesláno ze Samsung Mobile
-------- Původní zpráva -------- Od: Simo Sorce Datum:11. 02. 2014 20:59 (GMT+01:00) Komu: End-user discussions about the System Security Services Daemon Předmět: Re: [SSSD-users] sssd-1.11.1 Saucy automount(nfs4+krb problem) On Tue, 2014-02-11 at 17:27 +0000, Ondrej Valousek wrote:
Got it. You need to use short hostname - i.e. hostname should return only "client", not "client.domain.org". O.
This normally breaks other things, you should probably instead open a bug against nfs-utils so that they try to split the hostname along '.' before appending the $
I will ping Steve Dickson (mainatiner of nfs-utils) shortly about this, but filing a bug would help anyway.
Simo.
-- Simo Sorce * Red Hat, Inc * New York
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Is this because for NFS4 service machine asks, there is need for credentials for machine principal, the one ending with “$”, and rpc.gssd asks about CLIENT.DOMAIN.ORG$@DOMAIN.ORGmailto:CLIENT.DOMAIN.ORG$@DOMAIN.ORG instead of CLIENT$@DOMAIN.ORG and that question depends on what ‘hostname’ returns? Exactly.
On Wed, 12 Feb 2014, Longina Przybyszewska wrote:
Do I miss something in getting point here:
If there is a key for the principal 'host/client.domain.org@DOMAIN.ORG' in local /etc/krb5.keytab -
why there are no credentials in Kerberos database?
ServicePrincipal vs UserPrincipal. In AD, you can add as many service principals as you like (net ads keytab add blah), but these are only useful for services, as they can't get a Ticket Granting Ticket. NFS is unusual in needing a tgt. So you have ones like host/fqdn which can be used by ssh. You get one user principal for free with AD, which is 'shorthostname$'. That can generate a TGT (i.e. you can use kinit with it). You're allowed one other, which you can generate with samba via 'net ads join createupn='something/fqdn'. This can be useful for services that need it, that don't know to use the other one. So you can use that with nfs to make it all happy that way, by making the nfs/fqdn principal able to request a tgt.
Is this because for NFS4 service machine asks, there is need for credentials for machine principal, the one ending with “$”, and rpc.gssd
asks about CLIENT.DOMAIN.ORG$@DOMAIN.ORG instead of CLIENT$@DOMAIN.ORG
and that question depends on what ‘hostname’ returns?
hostname should always return the full hostname, and hostname -s should return the short host name. I'd really not change that to fix this problem.
jh
NFs mount works :-) if I change hostname-> shortname('client').
Now I would try to obtain service principal 'nfs/client.domain.org@DOMAIN.ORG' and try it again with hostname->fqdn(client.domain.org).
It is quite logic not have FQDN$ principals in Kerberos (+ long names limit problem) Thanks again for all the enlightment!
Best Longina
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of John Hodrien Sent: 12. februar 2014 11:02 To: End-user discussions about the System Security Services Daemon Subject: Re: [SSSD-users] sssd-1.11.1 Saucy automount(nfs4+krb problem)
On Wed, 12 Feb 2014, Longina Przybyszewska wrote:
Do I miss something in getting point here:
If there is a key for the principal 'host/client.domain.org@DOMAIN.ORG' in local /etc/krb5.keytab -
why there are no credentials in Kerberos database?
ServicePrincipal vs UserPrincipal. In AD, you can add as many service principals as you like (net ads keytab add blah), but these are only useful for services, as they can't get a Ticket Granting Ticket. NFS is unusual in needing a tgt. So you have ones like host/fqdn which can be used by ssh. You get one user principal for free with AD, which is 'shorthostname$'. That can generate a TGT (i.e. you can use kinit with it). You're allowed one other, which you can generate with samba via 'net ads join createupn='something/fqdn'. This can be useful for services that need it, that don't know to use the other one. So you can use that with nfs to make it all happy that way, by making the nfs/fqdn principal able to request a tgt.
Is this because for NFS4 service machine asks, there is need for credentials for machine principal, the one ending with “$”, and rpc.gssd
asks about CLIENT.DOMAIN.ORG$@DOMAIN.ORG instead of CLIENT$@DOMAIN.ORG
and that question depends on what ‘hostname’ returns?
hostname should always return the full hostname, and hostname -s should return the short host name. I'd really not change that to fix this problem.
jh
Well not exactly. rpc.gssd (i.e. NFS client side) does need a TGT. Kerberized NFS server (i.e. rpc.svcgssd) is just happy with the ServicePrincipal.
Historically, rpc.gssd only supported "nfs/fqdn" UserPrincipal names. Later on, someone from nfs-utils maintainers noticed that some people use secure NFS with M$ based KDC - and hence added support for the "client$" UPN. This is nice, but as John noticed, this support is far for being ideal :)
To make the long story short, you have 3 options now: 1. Have the nfs-utils maintainers fix this bug for you :) 2. Use short hostname 3. Define UserServicePrincipal computer attribute in AD and add something like "nfs/fqdn". This will allow Gssd to obtain a TGT using that princpal.
Ondrej
________________________________________ From: sssd-users-bounces@lists.fedorahosted.org [sssd-users-bounces@lists.fedorahosted.org] on behalf of John Hodrien [J.H.Hodrien@leeds.ac.uk] Sent: Wednesday, February 12, 2014 11:01 AM To: End-user discussions about the System Security Services Daemon Subject: Re: [SSSD-users] sssd-1.11.1 Saucy automount(nfs4+krb problem)
On Wed, 12 Feb 2014, Longina Przybyszewska wrote:
Do I miss something in getting point here:
If there is a key for the principal 'host/client.domain.org@DOMAIN.ORG' in local /etc/krb5.keytab -
why there are no credentials in Kerberos database?
ServicePrincipal vs UserPrincipal. In AD, you can add as many service principals as you like (net ads keytab add blah), but these are only useful for services, as they can't get a Ticket Granting Ticket. NFS is unusual in needing a tgt. So you have ones like host/fqdn which can be used by ssh. You get one user principal for free with AD, which is 'shorthostname$'. That can generate a TGT (i.e. you can use kinit with it). You're allowed one other, which you can generate with samba via 'net ads join createupn='something/fqdn'. This can be useful for services that need it, that don't know to use the other one. So you can use that with nfs to make it all happy that way, by making the nfs/fqdn principal able to request a tgt.
Is this because for NFS4 service machine asks, there is need for credentials for machine principal, the one ending with “$”, and rpc.gssd
asks about CLIENT.DOMAIN.ORG$@DOMAIN.ORG instead of CLIENT$@DOMAIN.ORG
and that question depends on what ‘hostname’ returns?
hostname should always return the full hostname, and hostname -s should return the short host name. I'd really not change that to fix this problem.
jh
On Wed, 12 Feb 2014, Ondrej Valousek wrote:
Well not exactly. rpc.gssd (i.e. NFS client side) does need a TGT. Kerberized NFS server (i.e. rpc.svcgssd) is just happy with the ServicePrincipal.
Sure, although if you just roll this out as standard policy for joining machines to the domain, having the nfs/fqdn UPN setup all over the shop won't break anything, and it's a rare requirement to need another UPN for a machine. If you do, there are ways of having even more UPNs for a single host.
To make the long story short, you have 3 options now:
- Have the nfs-utils maintainers fix this bug for you :)
- Use short hostname
- Define UserServicePrincipal computer attribute in AD and add something like "nfs/fqdn". This will allow Gssd to obtain a TGT using that princpal.
Personally, I think taking both option 1 *and* 3 is the best solution.
jh
Oh, yes, you talked about UPN, not SPN, sorry. Actually, I have just checked attributes in AD for my machine. I have everything! It happened that I tried a lot to get it work before send email to the mailinglist -
I have the following principals : sAMAccountName CLIENT$ servicePrincipalName HOST/CLIENT servicePrincipalName HOST/client.domain.org servicePrincipalName nfs/client.domain.org/client servicePrincipalName nfs/client.domain.org/client.domain.org userPrincipalName nfs/client.domain.org
I used 'realm' command for adding new principals for the machine (as long my 'history' can reach)
realm join -v -U USER --user-principal=host/client.domain.org --computer-ou OU="Linux computers",OU=ADResources DOMAIN.ORG
realm join -v -U USER --user-principal=nfs/client.domain.org --computer-ou OU="Linux computers",OU=ADResources DOMAIN.ORG
At last, I ' leaved' domain and 'rejoined' again - but it seems that it wasn't done clean. Now I have no UPN entry in my /etc/krb5.ketab.
How I can get it again?
What is a clean way of "leaving" domain for the machine, with removing all entries inclusiv DNS entries?
Best
longina
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of John Hodrien Sent: 12. februar 2014 11:27 To: End-user discussions about the System Security Services Daemon Subject: Re: [SSSD-users] sssd-1.11.1 Saucy automount(nfs4+krb problem)
On Wed, 12 Feb 2014, Ondrej Valousek wrote:
Well not exactly. rpc.gssd (i.e. NFS client side) does need a TGT. Kerberized NFS server (i.e. rpc.svcgssd) is just happy with the ServicePrincipal.
Sure, although if you just roll this out as standard policy for joining machines to the domain, having the nfs/fqdn UPN setup all over the shop won't break anything, and it's a rare requirement to need another UPN for a machine. If you do, there are ways of having even more UPNs for a single host.
To make the long story short, you have 3 options now:
- Have the nfs-utils maintainers fix this bug for you :) 2. Use short
hostname 3. Define UserServicePrincipal computer attribute in AD and add something like "nfs/fqdn". This will allow Gssd to obtain a TGT using that princpal.
Personally, I think taking both option 1 *and* 3 is the best solution.
jh _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Wed, 12 Feb 2014, Longina Przybyszewska wrote:
I have the following principals : servicePrincipalName nfs/client.domain.org/client servicePrincipalName nfs/client.domain.org/client.domain.org
That's a lot of slashes...?
I used 'realm' command for adding new principals for the machine (as long my 'history' can reach)
realm join -v -U USER --user-principal=host/client.domain.org --computer-ou OU="Linux computers",OU=ADResources DOMAIN.ORG
realm join -v -U USER --user-principal=nfs/client.domain.org --computer-ou OU="Linux computers",OU=ADResources DOMAIN.ORG
At last, I ' leaved' domain and 'rejoined' again - but it seems that it wasn't done clean. Now I have no UPN entry in my /etc/krb5.ketab.
Are you sure? Easiest way to test if it's a UPN is to do:
kinit -k nfs/client.domain.org
If that works, it's definitely a UPN.
What is a clean way of "leaving" domain for the machine, with removing all entries inclusiv DNS entries?
I know nothing about realm. With samba, net ads leave should be sufficient I thought.
jh
I have the following principals : servicePrincipalName nfs/client.domain.org/client servicePrincipalName nfs/client.domain.org/client.domain.org
That's a lot of slashes...?
I used 'realm' command for adding new principals for the machine (as long my 'history' can reach)
realm join -v -U USER --user-principal=host/client.domain.org --computer-ou OU="Linux computers",OU=ADResources DOMAIN.ORG
realm join -v -U USER --user-principal=nfs/client.domain.org --computer-ou OU="Linux computers",OU=ADResources DOMAIN.ORG
At last, I ' leaved' domain and 'rejoined' again - but it seems that it wasn't done clean. Now I have no UPN entry in my /etc/krb5.ketab.
Are you sure? Easiest way to test if it's a UPN is to do:
kinit -k nfs/client.domain.org
If that works, it's definitely a UPN.
What is a clean way of "leaving" domain for the machine, with removing all entries inclusiv DNS entries?
I know nothing about realm. With samba, net ads leave should be sufficient I thought.
You are right, my upn doesn’t work - there is that attribute in AD , but credentials don't work. Anyway somehow my 'client' becomes crappy with all the slashed attributes, need to remove/join again.
'Realmd' is relatively new, together with sssd it suppose to make Linux AD integration working out of the box. Almost. Realmd is based on self discovery of AD or IPA services, auto configures sssd, makes sssd.conf and starts for first time sssd. It actually works fine in Ubuntu Saucy for authentication/login until the point I wanted automount with nfs4+Kerberos working. It would be very powerful. By now I would prefer 'msktutil', I think, for doing the 'join' job - its operations are described more precisely, nothing hidden.
Best Longina
Hi Simo,
I are you getting on about this with Steve? Would it be better to open a RFE for this? I would like to know where we are standing - whether there is any chance that RHEL6 will be fixed or it would only go to RHEL 7.
Thanks, Ondrej ________________________________________ From: sssd-users-bounces@lists.fedorahosted.org [sssd-users-bounces@lists.fedorahosted.org] on behalf of Simo Sorce [simo@redhat.com] Sent: Tuesday, February 11, 2014 8:59 PM To: End-user discussions about the System Security Services Daemon Subject: Re: [SSSD-users] sssd-1.11.1 Saucy automount(nfs4+krb problem)
On Tue, 2014-02-11 at 17:27 +0000, Ondrej Valousek wrote:
Got it. You need to use short hostname - i.e. hostname should return only "client", not "client.domain.org". O.
This normally breaks other things, you should probably instead open a bug against nfs-utils so that they try to split the hostname along '.' before appending the $
I will ping Steve Dickson (mainatiner of nfs-utils) shortly about this, but filing a bug would help anyway.
Simo.
-- Simo Sorce * Red Hat, Inc * New York
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Wed, 2014-02-19 at 15:04 +0000, Ondrej Valousek wrote:
Hi Simo,
I are you getting on about this with Steve?
This is the current situation: <steved> simo: post a patch with what you want and lets talk about it....
:-)
Would it be better to open a RFE for this? I would like to know where we are standing - whether there is any chance that RHEL6 will be fixed or it would only go to RHEL 7.
An RFE for RHEL7 would be nice.
Simo.
Ok, got it. I will try to write a patch against RH6 (as this is my primary concern :) and will add it to the RFE..
As of RH7: you talked about possibility to use gssproxy to replace rpc.gssd (or was it rpc.svcgssd?). Is it relevant to this problem? Thanks O.
Odesláno ze Samsung Mobile
-------- Původní zpráva -------- Od: Simo Sorce Datum:19. 02. 2014 19:36 (GMT+01:00) Komu: End-user discussions about the System Security Services Daemon Předmět: Re: [SSSD-users] sssd-1.11.1 Saucy automount(nfs4+krb problem)
On Wed, 2014-02-19 at 15:04 +0000, Ondrej Valousek wrote:
Hi Simo,
I are you getting on about this with Steve?
This is the current situation: <steved> simo: post a patch with what you want and lets talk about it....
:-)
Would it be better to open a RFE for this? I would like to know where we are standing - whether there is any chance that RHEL6 will be fixed or it would only go to RHEL 7.
An RFE for RHEL7 would be nice.
Simo.
-- Simo Sorce * Red Hat, Inc * New York
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Created BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1067423
attached is a patch resolving the issue. Ondrej ________________________________________ From: sssd-users-bounces@lists.fedorahosted.org [sssd-users-bounces@lists.fedorahosted.org] on behalf of Simo Sorce [simo@redhat.com] Sent: Wednesday, February 19, 2014 7:35 PM To: End-user discussions about the System Security Services Daemon Subject: Re: [SSSD-users] sssd-1.11.1 Saucy automount(nfs4+krb problem)
On Wed, 2014-02-19 at 15:04 +0000, Ondrej Valousek wrote:
Hi Simo,
I are you getting on about this with Steve?
This is the current situation: <steved> simo: post a patch with what you want and lets talk about it....
:-)
Would it be better to open a RFE for this? I would like to know where we are standing - whether there is any chance that RHEL6 will be fixed or it would only go to RHEL 7.
An RFE for RHEL7 would be nice.
Simo.
-- Simo Sorce * Red Hat, Inc * New York
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users@lists.fedorahosted.org
-
John Hodrien -
Longina Przybyszewska -
Ondrej Valousek -
Simo Sorce