11:03 p.m.
RHEL7 w/ sssd 1.13.0-40.el7_2.2. Connecting via SSH from PuTTY from a
Windows box. GSSAPI is set up and also configured to allow credential
delegation. When I connect, I am not prompted for a password and get
into the system just fine.
However, klist shows nothing in my credential cache:
$ klist
klist: Credentials cache file '/tmp/krb5cc_1766242567' not found
(I also see no other differently named krb5cc file under /tmp).
If I first SSH into a host runing winbind from the same PuTTY, I
properly get a cached ticket there and can then ssh to the RHEL7 host
and the ticket is properly forwarded across (klist shows it in the
output).
$ klist
Ticket cache: FILE:/tmp/krb5cc_1766242567_CMtqGFX6EG
Default principal: username(a)DOMAIN.COM
Valid starting Expires Service principal
04/20/2016 20:57:41 04/21/2016 03:04:48 krbtgt/DOMAIN.COM(a)DOMAIN.COM
renew until 04/27/2016 17:04:48
Have run sssd in foreground w/ debug and looked for krb5 message, but
not even seeing it attempt to create or use ccache.
Figured someone here might be able to set me down the right course?
Thanks in advance.
Ray
My sssd.conf:
[sssd]
config_file_version = 2
domains = domain.com
services = nss, pam
debug_level = 0
override_space = _
[nss]
debug_level = 0
override_shell = /bin/bash
allowed_shells = /bin/bash, /bin/tcsh
vetoed_shells = /bin/csh
shell_fallback = /bin/bash
[pam]
debug_level = 0
[domain/domain.com]
debug_level = 0
id_provider = ad
access_provider = ad
ignore_group_members = true
cache_credentials = True
ldap_group_nesting_level = 5
ldap_idmap_range_min = 200000
ldap_idmap_range_max = 2000200000
ldap_idmap_range_size = 500000
krb5_realm = DOMAIN.COM
override_homedir = /home/%u
ldap_referrals = false
#krb5_ccachedir = /tmp
#krb5_ccname_template = FILE:%d/krb5cc_%U_XXXXXX
krb5_renewable_lifetime = 12h
krb5_renew_interval = 1h
krb5_store_password_if_offline = True
krb5.conf:
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = DOMAIN.COM
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
rdns = false
forwardable = true
#default_ccache_name =
[realms]
DOMAIN.COM = {
#kdc = kerberos.example.com
#admin_server = kerberos.example.com
}
[domain_realm]
.domain.com = DOMAIN.COM
domain.com = DOMAIN.COM
2:56 a.m.
New subject: Dear lazyweb... not getting cached ticket from PuTTY login
On Wed, Apr 20, 2016 at 09:03:54PM -0700, Ray Van Dolson wrote:
RHEL7 w/ sssd 1.13.0-40.el7_2.2. Connecting via SSH from PuTTY from
a
Windows box. GSSAPI is set up and also configured to allow credential
delegation. When I connect, I am not prompted for a password and get
into the system just fine.
However, klist shows nothing in my credential cache:
$ klist
klist: Credentials cache file '/tmp/krb5cc_1766242567' not found
(I also see no other differently named krb5cc file under /tmp).
RHEL7 should by default use Kernel keyring based ccaches.
If I first SSH into a host runing winbind from the same PuTTY, I
properly get a cached ticket there and can then ssh to the RHEL7 host
and the ticket is properly forwarded across (klist shows it in the
output).
$ klist
Ticket cache: FILE:/tmp/krb5cc_1766242567_CMtqGFX6EG
Default principal: username(a)DOMAIN.COM
Valid starting Expires Service principal
04/20/2016 20:57:41 04/21/2016 03:04:48 krbtgt/DOMAIN.COM(a)DOMAIN.COM
renew until 04/27/2016 17:04:48
Have run sssd in foreground w/ debug and looked for krb5 message, but
not even seeing it attempt to create or use ccache.
In this case SSSD has nothing to do with ccache handling, everything is
done by sshd.
Figured someone here might be able to set me down the right course?
If you enable debug logging with sshd e.g. by setting 'LogLevel DEBUG3'
in /etc/ssh/sshd_config the output in /var/log/secure should tell you
where sshd stores the ticket. I see messages like:
Apr 21 09:47:42 ipa-devel sshd[6044]: debug1: ssh_krb5_cc_gen: Setting ccname to
KEYRING:persistent:1140000000
Apr 21 09:47:43 ipa-devel sshd[6052]: debug1: Setting KRB5CCNAME to
KEYRING:persistent:1140000000:1140000000
Apr 21 09:47:43 ipa-devel sshd[6052]: debug3: Copy environment:
KRB5CCNAME=KEYRING:persistent:1140000000:1140000000
HTH
bye,
Sumit
>
> Thanks in advance.
>
> Ray
>
> My sssd.conf:
>
> [sssd]
> config_file_version = 2
> domains = domain.com
> services = nss, pam
> debug_level = 0
> override_space = _
> [nss]
> debug_level = 0
> override_shell = /bin/bash
> allowed_shells = /bin/bash, /bin/tcsh
> vetoed_shells = /bin/csh
> shell_fallback = /bin/bash
> [pam]
> debug_level = 0
> [domain/domain.com]
> debug_level = 0
> id_provider = ad
> access_provider = ad
> ignore_group_members = true
> cache_credentials = True
> ldap_group_nesting_level = 5
> ldap_idmap_range_min = 200000
> ldap_idmap_range_max = 2000200000
> ldap_idmap_range_size = 500000
> krb5_realm = DOMAIN.COM
> override_homedir = /home/%u
> ldap_referrals = false
> #krb5_ccachedir = /tmp
> #krb5_ccname_template = FILE:%d/krb5cc_%U_XXXXXX
> krb5_renewable_lifetime = 12h
> krb5_renew_interval = 1h
> krb5_store_password_if_offline = True
>
> krb5.conf:
>
> [logging]
> default = FILE:/var/log/krb5libs.log
> kdc = FILE:/var/log/krb5kdc.log
> admin_server = FILE:/var/log/kadmind.log
>
> [libdefaults]
> default_realm = DOMAIN.COM
> dns_lookup_realm = true
> dns_lookup_kdc = true
> ticket_lifetime = 24h
> renew_lifetime = 7d
> rdns = false
> forwardable = true
> #default_ccache_name =
>
> [realms]
> DOMAIN.COM = {
> #kdc = kerberos.example.com
> #admin_server = kerberos.example.com
> }
>
> [domain_realm]
> .domain.com = DOMAIN.COM
> domain.com = DOMAIN.COM
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
4:13 a.m.
New subject: Dear lazyweb... not getting cached ticket from PuTTY login
On Thu, 21 Apr 2016, Sumit Bose wrote:
In this case SSSD has nothing to do with ccache handling, everything
is
done by sshd.
I was suspicious about windows not providing a forwardable ticket by default,
and it not being ssh or sssd's fault.
Have you managed SSO with delegation to a machine not running sssd using
putty?
jh
4:39 a.m.
New subject: Dear lazyweb... not getting cached ticket from PuTTY login
On Thu, Apr 21, 2016 at 10:13:20AM +0100, John Hodrien wrote:
On Thu, 21 Apr 2016, Sumit Bose wrote:
>In this case SSSD has nothing to do with ccache handling, everything is
>done by sshd.
I was suspicious about windows not providing a forwardable ticket by default,
and it not being ssh or sssd's fault.
Have you managed SSO with delegation to a machine not running sssd using
putty?
ah, this reminds me that the host must be configured to be trusted for
delegation, see AD's 'AD Users and Computers' tool, find your target
host and check the 'Delegation' tab.
HTH
bye,
Sumit
>
> jh
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
6:27 a.m.
New subject: Dear lazyweb... not getting cached ticket from PuTTY login
On Thu, 21 Apr 2016, Sumit Bose wrote:
On Thu, Apr 21, 2016 at 10:13:20AM +0100, John Hodrien wrote:
> On Thu, 21 Apr 2016, Sumit Bose wrote:
>
> >In this case SSSD has nothing to do with ccache handling, everything is
> >done by sshd.
>
> I was suspicious about windows not providing a forwardable ticket by default,
> and it not being ssh or sssd's fault.
>
> Have you managed SSO with delegation to a machine not running sssd using
> putty?
ah, this reminds me that the host must be configured to be trusted for
delegation, see AD's 'AD Users and Computers' tool, find your target
host and check the 'Delegation' tab.
We see a failure connecting from a windows machine with putty, but success
from a linux machine. Neither machine appears to be configured for delegation
within AD (both listed as Do not trust this computer for delegation).
jh
11:14 a.m.
New subject: Dear lazyweb... not getting cached ticket from PuTTY login
On Thu, Apr 21, 2016 at 11:39:02AM +0200, Sumit Bose wrote:
On Thu, Apr 21, 2016 at 10:13:20AM +0100, John Hodrien wrote:
> On Thu, 21 Apr 2016, Sumit Bose wrote:
>
> >In this case SSSD has nothing to do with ccache handling, everything is
> >done by sshd.
>
> I was suspicious about windows not providing a forwardable ticket by default,
> and it not being ssh or sssd's fault.
>
> Have you managed SSO with delegation to a machine not running sssd using
> putty?
ah, this reminds me that the host must be configured to be trusted for
delegation, see AD's 'AD Users and Computers' tool, find your target
host and check the 'Delegation' tab.
HTH
bye,
Sumit
So, this solves my problem, but still leaves me a little bit puzzled as
to why some scenarios work without it.
SERVER1: RHEL7+sssd joined to AD but is not explicitly trusted for
delegation.
SERVER2: RHEL6+sssd joined to AD but is not explicitly trusted for
delegation.
CLIENT1: Windows 7, joined to AD. Running PuTTY w/ 'Allow GSSAPI
credential delegation' set.
CLIENT2: Windows 7, not joined to AD but has TGT via MIT Keberos w/
PuTTY set up exactly the same as CLIENT1
If I connect from CLIENT1 to SERVER1, I don't get a TGT in my cache.
If I connect from CLIENT1 to SERVER2, I don't get a TGT in my cache,
but if I manually kinit once on SERVER2 and then ssh -K to SERVER1, I
get a TGT in SERVER1's cache.
If I connect from CLIENT2 to either SERVER1 or SERVER2 I get a TGT in
their caches.
So it seems like the delegation trust setting against the server
computer object in AD is only needed for clients using PuTTY with
native Windows kerberos.
Clients using OpenSSH or MIT kerberos seem to work fine even without
the delegation trust setting...
I see some references to this behaviour elsewhere[1]...
This is probably something I should follow up with on the SSH list or
servervault though. :)
Ray
[1]
http://serverfault.com/questions/646854/putty-kerberos-gssapi-authenticat...
12:15 p.m.
New subject: Dear lazyweb... not getting cached ticket from PuTTY login
On Sat, Apr 23, 2016 at 09:14:17AM -0700, Ray Van Dolson wrote:
On Thu, Apr 21, 2016 at 11:39:02AM +0200, Sumit Bose wrote:
> On Thu, Apr 21, 2016 at 10:13:20AM +0100, John Hodrien wrote:
> > On Thu, 21 Apr 2016, Sumit Bose wrote:
> >
> > >In this case SSSD has nothing to do with ccache handling, everything is
> > >done by sshd.
> >
> > I was suspicious about windows not providing a forwardable ticket by default,
> > and it not being ssh or sssd's fault.
> >
> > Have you managed SSO with delegation to a machine not running sssd using
> > putty?
>
> ah, this reminds me that the host must be configured to be trusted for
> delegation, see AD's 'AD Users and Computers' tool, find your target
> host and check the 'Delegation' tab.
>
> HTH
>
> bye,
> Sumit
So, this solves my problem, but still leaves me a little bit puzzled as
to why some scenarios work without it.
SERVER1: RHEL7+sssd joined to AD but is not explicitly trusted for
delegation.
SERVER2: RHEL6+sssd joined to AD but is not explicitly trusted for
delegation.
CLIENT1: Windows 7, joined to AD. Running PuTTY w/ 'Allow GSSAPI
credential delegation' set.
CLIENT2: Windows 7, not joined to AD but has TGT via MIT Keberos w/
PuTTY set up exactly the same as CLIENT1
If I connect from CLIENT1 to SERVER1, I don't get a TGT in my cache.
If I connect from CLIENT1 to SERVER2, I don't get a TGT in my cache,
but if I manually kinit once on SERVER2 and then ssh -K to SERVER1, I
get a TGT in SERVER1's cache.
If I connect from CLIENT2 to either SERVER1 or SERVER2 I get a TGT in
their caches.
So it seems like the delegation trust setting against the server
computer object in AD is only needed for clients using PuTTY with
native Windows kerberos.
Clients using OpenSSH or MIT kerberos seem to work fine even without
the delegation trust setting...
I see some references to this behaviour elsewhere[1]...
This is probably something I should follow up with on the SSH list or
servervault though. :)
Ray
[1]
http://serverfault.com/questions/646854/putty-kerberos-gssapi-authenticat...
Found the answer:
http://mailman.mit.edu/pipermail/kerberos/2014-April/019805.html
In short, Wnidows SSPI implementation on the client side checks the
trusted delegation setting for the target in AD, whereas the MIT
implementation doesn't.
Interesting read (the whole thread).
Ray
2:32 a.m.
New subject: Dear lazyweb... not getting cached ticket from PuTTY login
On Sat, Apr 23, 2016 at 10:15:48AM -0700, Ray Van Dolson wrote:
On Sat, Apr 23, 2016 at 09:14:17AM -0700, Ray Van Dolson wrote:
> On Thu, Apr 21, 2016 at 11:39:02AM +0200, Sumit Bose wrote:
> > On Thu, Apr 21, 2016 at 10:13:20AM +0100, John Hodrien wrote:
> > > On Thu, 21 Apr 2016, Sumit Bose wrote:
> > >
> > > >In this case SSSD has nothing to do with ccache handling, everything
is
> > > >done by sshd.
> > >
> > > I was suspicious about windows not providing a forwardable ticket by
default,
> > > and it not being ssh or sssd's fault.
> > >
> > > Have you managed SSO with delegation to a machine not running sssd using
> > > putty?
> >
> > ah, this reminds me that the host must be configured to be trusted for
> > delegation, see AD's 'AD Users and Computers' tool, find your
target
> > host and check the 'Delegation' tab.
> >
> > HTH
> >
> > bye,
> > Sumit
>
> So, this solves my problem, but still leaves me a little bit puzzled as
> to why some scenarios work without it.
>
> SERVER1: RHEL7+sssd joined to AD but is not explicitly trusted for
> delegation.
> SERVER2: RHEL6+sssd joined to AD but is not explicitly trusted for
> delegation.
> CLIENT1: Windows 7, joined to AD. Running PuTTY w/ 'Allow GSSAPI
> credential delegation' set.
> CLIENT2: Windows 7, not joined to AD but has TGT via MIT Keberos w/
> PuTTY set up exactly the same as CLIENT1
>
> If I connect from CLIENT1 to SERVER1, I don't get a TGT in my cache.
>
> If I connect from CLIENT1 to SERVER2, I don't get a TGT in my cache,
> but if I manually kinit once on SERVER2 and then ssh -K to SERVER1, I
> get a TGT in SERVER1's cache.
>
> If I connect from CLIENT2 to either SERVER1 or SERVER2 I get a TGT in
> their caches.
>
> So it seems like the delegation trust setting against the server
> computer object in AD is only needed for clients using PuTTY with
> native Windows kerberos.
>
> Clients using OpenSSH or MIT kerberos seem to work fine even without
> the delegation trust setting...
>
> I see some references to this behaviour elsewhere[1]...
>
> This is probably something I should follow up with on the SSH list or
> servervault though. :)
>
> Ray
>
> [1]
http://serverfault.com/questions/646854/putty-kerberos-gssapi-authenticat...
Found the answer:
http://mailman.mit.edu/pipermail/kerberos/2014-April/019805.html
In short, Wnidows SSPI implementation on the client side checks the
trusted delegation setting for the target in AD, whereas the MIT
implementation doesn't.
Interesting read (the whole thread).
yes, I think this answers all your questions. Since you have access to
your TGT you are free to copy it to any host you want. The trusted for
delegation checking should just prevent sending the TGT automatically to
un-trusted hosts. E.g. on a Linux/UNIX system the root user can
typically read the credential cache of every user and if the TGT is
forwarded to a compromised host the attacker can use the TGT to access
all of the users resources in the network. So delegation should in
general be used with care.
bye,
Sumit
>
> Ray
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
2920
days inactive
2924
days old
sssd-users@lists.fedorahosted.org
7 comments
4 participants
participants (4)
-
John Hodrien -
Ray Van Dolson -
Ray Van Dolson -
Sumit Bose