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
debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism

[ipa_subdom_get_forest] (0x0400: 4th component is not 'trust', nothing to

Any ideas?


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
>  /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:
Go to http://freeipa.org for more info on the project

Reply via email to