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.
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
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
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
>> (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
>> but not to FreeIPA host clients.
>> Important sections of configuration files (servers/clients):
>> GSSAPIAuthentication yes
>> KerberosAuthentication yes
> Remove 'KerberosAuthentication yes', you don't want it to be used, only
>> 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ś
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