Hi Alexander,
thank you for your fast reply.
I've already executed: # ipa host-mod --ok-as-delegate=TRUE but still cant
log in using GSSAPI to ipa clients.
Please find answers below:
1. Yes, logging to Linux IPA Client (Centos 6.6) without entering password
is not working from AD-joined Windows station with PuTTY. Logging to IPA
Master server without entering password (using gssapi) works ok.
2. -
3. Logging in to ipa clients from AD-joined Windows station with Putty
(0.64) always requires password and then Kerberos ticket is available in
the shell.
After I changed loglevel in /etc/sshd/sshd_config on ipa client to LogLevel
Debug i found in /var/log/secure:
debug1: userauth-request for user leszek service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for leszek
...
debug1: Postponed gssapi-with-mic for leszek from X.X.X.X
debug1: Got no client credentials
Failed gssapi-with-mic for user leszek
After entering password and logging to system I found this in
/var/log/secure:
...
debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism
/var/log/sssd/sssd_domain.log
...
[ipa_subdom_get_forest] (0x0400: 4th component is not 'trust', nothing to
do.
...
Any ideas?
/lm
2015-05-25 13:25 GMT+02:00 Alexander Bokovoy aboko...@redhat.com:
On Mon, 25 May 2015, crony wrote:
Hi All,
we have setup FreeIPA 4.1 (Centos 7) Trust with Windows 2008R2. All (HBAC,
SUDO) works pretty well except SSH SSO using GSSAPI from Windows AD
clients
(ex. putty) to Linux client machines (Centos 6). Password authentication
works, just gssapi fails.
Do you have have anything in the SSH server logs when using high enough
debug level?
SSH GSSAPI (single sign-on) should just work fine. On contrary, delegation
or forwarding
of credentials (i.e. Kerberos TGT from AD side being available after
login to SSH server) should not work unless ok-as-delegate flag is set
on the host principal -- see 'ipa host-mod --ok-as-delegate=TRUE'.
So what exactly is not working:
1. Logging in without entering a password from AD-joined Windows
station with PuTTY?
2. Logging in without the password works but no Kerberos ticket
available in the shell?
3. Logging in always requires password and then Kerberos ticket is not
available in the shell?
4. Something else?
Actually, there is one scenario where SSH GSSAPI authentication works -
when connecting to FreeIPA master or replica (trust were established
here),
but not to FreeIPA host clients.
Important sections of configuration files (servers/clients):
/etc/ssh/sshd_config:
GSSAPIAuthentication yes
KerberosAuthentication yes
Remove 'KerberosAuthentication yes', you don't want it to be used, only
GSSAPI.
/etc/krb5.conf:
auth_to_local = RULE:[1:$1 at $0](^.* at WINDOWS.DOMAIN$)s/ at
WINDOWS.DOMAIN/ at windows.domain/
auth_to_local = DEFAULT
You don't need to specify auth_to_local rules in krb5.conf in RHEL 7.1
because we now have this filled in by SSSD. As you are claiming FreeIPA
4.1 is in use, it means CentOS 7.1, thus SSSD automatically contributing
auth_to_local plugin.
BTW. after I log in by password to linux client machine I can use gssapi
within the same host by ssh-ing in a loop to the localhost, so locally
GSSAPI works here.
This is expected and is by design.
Is there something I missed?
Any help would be greatly appreciated.
Answer my questions above, I suspect all you need is to mark the host
principal as available for delegation.
--
/ Alexander Bokovoy
--
Pozdrawiam Leszek Miś
www: http://cronylab.pl
www: http://emerge.pl
Nothing is secure, paranoia is your friend.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
