Re: [Freeipa-users] GSSAPI authentication from trusted AD domain
On Wed, May 03, 2017 at 11:28:18AM +0200, Tiemen Ruiten wrote: > Tickets on the FreeIPA host after connecting (with a password): > > [adm.tie...@clients.rdmedia.com@neodymium ~]$ klist > Ticket cache: KEYRING:persistent:998801112:krb_ccache_ZzERoB1 > Default principal: adm.tie...@clients.rdmedia.com > > Valid starting Expires Service principal > 05/03/2017 11:26:03 05/03/2017 21:26:03 krbtgt/ > clients.rdmedia@clients.rdmedia.com > renew until 05/04/2017 11:26:03 > > > > Tickets on the AD laptop after a connection attempt: > > C:\Users\adm.tiemen.CLIENTS>klist > > Current LogonId is 0:0x587aa > > Cached Tickets: (2) > > #0> Client: adm.tiemen @ CLIENTS.RDMEDIA.COM > Server: krbtgt/CLIENTS.RDMEDIA.COM @ CLIENTS.RDMEDIA.COM > KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 > Ticket Flags 0x40e1 -> forwardable renewable initial > pre_authent name_canonicalize > Start Time: 5/3/2017 11:12:46 (local) > End Time: 5/3/2017 21:12:46 (local) > Renew Time: 5/10/2017 11:12:46 (local) > Session Key Type: AES-256-CTS-HMAC-SHA1-96 > Cache Flags: 0x1 -> PRIMARY > Kdc Called: vm-win-01.clients.rdmedia.com > > #1> Client: adm.tiemen @ CLIENTS.RDMEDIA.COM > Server: LDAP/vm-win-01.clients.rdmedia.com/clients.rdmedia.com @ > CLIENTS.RDMEDIA.COM > KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 > Ticket Flags 0x40a5 -> forwardable renewable pre_authent > ok_as_delegate name_canonicalize > Start Time: 5/3/2017 11:12:46 (local) > End Time: 5/3/2017 21:12:46 (local) > Renew Time: 5/10/2017 11:12:46 (local) > Session Key Type: AES-256-CTS-HMAC-SHA1-96 > Cache Flags: 0 > Kdc Called: vm-win-01.clients.rdmedia.com There is no ticket for host/neodymium.test.ams.i.rdmedia@test.ams.i.rdmedia.com nor a cross-realm ticket krbtgt/test.ams.i.rdmedia@clients.rdmedia.com So it looks the ssh client in the Windows host didn't try to get a Kerberos ticket for the IPA client. Did you use the FQDN neodymium.test.ams.i.rdmedia.com when trying to connect to the IPA client? According to the logs it looks like you are using kitty, have you tried to use putty? bye, Sumit > > > > > On 2 May 2017 at 19:45, Tiemen Ruiten wrote: > > > It's a CentOS 7.3 host, the version of sssd is 1.14.0, so there's no need > > for mapping. However on the AD host: > > > > Microsoft Windows [Version 6.3.9600] > > > > (c) 2013 Microsoft Corporation. All rights reserved. > > > > > > adm.tiemen@VM-WIN-01 C:\Users\adm.tiemen>klist > > > > > > Current LogonId is 0:0x603b58 > > > > > > Cached Tickets: (0) > > > > > > adm.tiemen@VM-WIN-01 C:\Users\adm.tiemen> > > > > Note that this is the domain controller and I'm logged in using the > > experimental Win32-OpenSSH server. Not sure if that makes a difference. I > > am not currently in the office, so unfortunately can't turn on the only > > joined laptop in this domain. > > > > How can I ensure a proper ticket is generated? > > > > On 2 May 2017 at 18:25, Sumit Bose wrote: > > > >> On Tue, May 02, 2017 at 05:46:34PM +0200, Tiemen Ruiten wrote: > >> > I think I just realised that my expectation may be wrong: GSSAPI login > >> with > >> > a FreeIPA user logged in on an AD host to a FreeIPA host works. So is it > >> > correct to also expect passwordless login with an AD user to a FreeIPA > >> host? > >> > >> The AD user case should work as well. > >> > >> First please send the SSSD version you use on the IPA client, > >> alternatively you can check if > >> /var/lib/sss/pubconf/krb5.include.d/localauth_plugin exists or not. This > >> would tell if SSSD can map the user name to the Kerberos principal of if > >> additional configuration is needed. > >> > >> On the AD host please check after trying to connect with ssh if there is > >> a proper service ticket for the IPA client by calling 'klist' in cmd.exe > >> or PowerShell. > >> > >> bye, > >> Sumit > >> > >> > > >> > On 2 May 2017 at 17:40, Jason B. Nance wrote: > >> > > >> > > Hi Tiemen, > >> > > > >> > > To be clear, what I'm trying to do: log in from an AD account > >> > > (adm.tiemen), from an AD host (leon.clients.rdmedia.com) to a FreeIPA > >> > > host (neodymium.test.ams.i.rdmedia.com) with the same AD account. I > >> > > expect to be logged in through GSSAPI, instead I get a password > >> prompt. > >> > > > >> > > I'm assuming that you are coming from a Windows client that is domain > >> > > joined and logged into that Windows client with the same domain > >> credentials > >> > > that you are using to connect to the IPA-joined host. Do you also > >> have > >> > > your SSH client configured to attempt GSSAPI? It appears that you do > >> from > >> > > the logs you provided but I'm just double-checking. > >> > > > >> > > In my setup I've found that this feature does not work all of the > >> time. > >> > > I've not yet been able to track it down a
Re: [Freeipa-users] GSSAPI authentication from trusted AD domain
Tickets on the FreeIPA host after connecting (with a password): [adm.tie...@clients.rdmedia.com@neodymium ~]$ klist Ticket cache: KEYRING:persistent:998801112:krb_ccache_ZzERoB1 Default principal: adm.tie...@clients.rdmedia.com Valid starting Expires Service principal 05/03/2017 11:26:03 05/03/2017 21:26:03 krbtgt/ clients.rdmedia@clients.rdmedia.com renew until 05/04/2017 11:26:03 Tickets on the AD laptop after a connection attempt: C:\Users\adm.tiemen.CLIENTS>klist Current LogonId is 0:0x587aa Cached Tickets: (2) #0> Client: adm.tiemen @ CLIENTS.RDMEDIA.COM Server: krbtgt/CLIENTS.RDMEDIA.COM @ CLIENTS.RDMEDIA.COM KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40e1 -> forwardable renewable initial pre_authent name_canonicalize Start Time: 5/3/2017 11:12:46 (local) End Time: 5/3/2017 21:12:46 (local) Renew Time: 5/10/2017 11:12:46 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x1 -> PRIMARY Kdc Called: vm-win-01.clients.rdmedia.com #1> Client: adm.tiemen @ CLIENTS.RDMEDIA.COM Server: LDAP/vm-win-01.clients.rdmedia.com/clients.rdmedia.com @ CLIENTS.RDMEDIA.COM KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a5 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize Start Time: 5/3/2017 11:12:46 (local) End Time: 5/3/2017 21:12:46 (local) Renew Time: 5/10/2017 11:12:46 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0 Kdc Called: vm-win-01.clients.rdmedia.com On 2 May 2017 at 19:45, Tiemen Ruiten wrote: > It's a CentOS 7.3 host, the version of sssd is 1.14.0, so there's no need > for mapping. However on the AD host: > > Microsoft Windows [Version 6.3.9600] > > (c) 2013 Microsoft Corporation. All rights reserved. > > > adm.tiemen@VM-WIN-01 C:\Users\adm.tiemen>klist > > > Current LogonId is 0:0x603b58 > > > Cached Tickets: (0) > > > adm.tiemen@VM-WIN-01 C:\Users\adm.tiemen> > > Note that this is the domain controller and I'm logged in using the > experimental Win32-OpenSSH server. Not sure if that makes a difference. I > am not currently in the office, so unfortunately can't turn on the only > joined laptop in this domain. > > How can I ensure a proper ticket is generated? > > On 2 May 2017 at 18:25, Sumit Bose wrote: > >> On Tue, May 02, 2017 at 05:46:34PM +0200, Tiemen Ruiten wrote: >> > I think I just realised that my expectation may be wrong: GSSAPI login >> with >> > a FreeIPA user logged in on an AD host to a FreeIPA host works. So is it >> > correct to also expect passwordless login with an AD user to a FreeIPA >> host? >> >> The AD user case should work as well. >> >> First please send the SSSD version you use on the IPA client, >> alternatively you can check if >> /var/lib/sss/pubconf/krb5.include.d/localauth_plugin exists or not. This >> would tell if SSSD can map the user name to the Kerberos principal of if >> additional configuration is needed. >> >> On the AD host please check after trying to connect with ssh if there is >> a proper service ticket for the IPA client by calling 'klist' in cmd.exe >> or PowerShell. >> >> bye, >> Sumit >> >> > >> > On 2 May 2017 at 17:40, Jason B. Nance wrote: >> > >> > > Hi Tiemen, >> > > >> > > To be clear, what I'm trying to do: log in from an AD account >> > > (adm.tiemen), from an AD host (leon.clients.rdmedia.com) to a FreeIPA >> > > host (neodymium.test.ams.i.rdmedia.com) with the same AD account. I >> > > expect to be logged in through GSSAPI, instead I get a password >> prompt. >> > > >> > > I'm assuming that you are coming from a Windows client that is domain >> > > joined and logged into that Windows client with the same domain >> credentials >> > > that you are using to connect to the IPA-joined host. Do you also >> have >> > > your SSH client configured to attempt GSSAPI? It appears that you do >> from >> > > the logs you provided but I'm just double-checking. >> > > >> > > In my setup I've found that this feature does not work all of the >> time. >> > > I've not yet been able to track it down and I'm assuming it has >> something >> > > to do with connections to domain controllers timing out, but at this >> point >> > > that is speculation. >> > > >> > > So to answer your question, yes, that should work. Sorry I don't have >> > > more information for you, I guess I'm basically "me too"ing your post. >> > > >> > > Regards, >> > > >> > > j >> > > >> > > Is this supposed to work? Did I miss something? >> > > >> > > Below the SSH log from the FreeIPA host with LogLevel DEBUG3: >> > > >> > > May 2 17:10:32 neodymium sshd[572]: debug3: fd 5 is not O_NONBLOCK >> > > May 2 17:10:32 neodymium sshd[572]: debug1: Forked child 752. >> > > May 2 17:10:32 neodymium sshd[572]: debug3: send_rexec_state: >> entering fd >> > > = 8 config len 922 >> > > May 2 17:10
Re: [Freeipa-users] GSSAPI authentication from trusted AD domain
It's a CentOS 7.3 host, the version of sssd is 1.14.0, so there's no need for mapping. However on the AD host: Microsoft Windows [Version 6.3.9600] (c) 2013 Microsoft Corporation. All rights reserved. adm.tiemen@VM-WIN-01 C:\Users\adm.tiemen>klist Current LogonId is 0:0x603b58 Cached Tickets: (0) adm.tiemen@VM-WIN-01 C:\Users\adm.tiemen> Note that this is the domain controller and I'm logged in using the experimental Win32-OpenSSH server. Not sure if that makes a difference. I am not currently in the office, so unfortunately can't turn on the only joined laptop in this domain. How can I ensure a proper ticket is generated? On 2 May 2017 at 18:25, Sumit Bose wrote: > On Tue, May 02, 2017 at 05:46:34PM +0200, Tiemen Ruiten wrote: > > I think I just realised that my expectation may be wrong: GSSAPI login > with > > a FreeIPA user logged in on an AD host to a FreeIPA host works. So is it > > correct to also expect passwordless login with an AD user to a FreeIPA > host? > > The AD user case should work as well. > > First please send the SSSD version you use on the IPA client, > alternatively you can check if > /var/lib/sss/pubconf/krb5.include.d/localauth_plugin exists or not. This > would tell if SSSD can map the user name to the Kerberos principal of if > additional configuration is needed. > > On the AD host please check after trying to connect with ssh if there is > a proper service ticket for the IPA client by calling 'klist' in cmd.exe > or PowerShell. > > bye, > Sumit > > > > > On 2 May 2017 at 17:40, Jason B. Nance wrote: > > > > > Hi Tiemen, > > > > > > To be clear, what I'm trying to do: log in from an AD account > > > (adm.tiemen), from an AD host (leon.clients.rdmedia.com) to a FreeIPA > > > host (neodymium.test.ams.i.rdmedia.com) with the same AD account. I > > > expect to be logged in through GSSAPI, instead I get a password prompt. > > > > > > I'm assuming that you are coming from a Windows client that is domain > > > joined and logged into that Windows client with the same domain > credentials > > > that you are using to connect to the IPA-joined host. Do you also have > > > your SSH client configured to attempt GSSAPI? It appears that you do > from > > > the logs you provided but I'm just double-checking. > > > > > > In my setup I've found that this feature does not work all of the time. > > > I've not yet been able to track it down and I'm assuming it has > something > > > to do with connections to domain controllers timing out, but at this > point > > > that is speculation. > > > > > > So to answer your question, yes, that should work. Sorry I don't have > > > more information for you, I guess I'm basically "me too"ing your post. > > > > > > Regards, > > > > > > j > > > > > > Is this supposed to work? Did I miss something? > > > > > > Below the SSH log from the FreeIPA host with LogLevel DEBUG3: > > > > > > May 2 17:10:32 neodymium sshd[572]: debug3: fd 5 is not O_NONBLOCK > > > May 2 17:10:32 neodymium sshd[572]: debug1: Forked child 752. > > > May 2 17:10:32 neodymium sshd[572]: debug3: send_rexec_state: > entering fd > > > = 8 config len 922 > > > May 2 17:10:32 neodymium sshd[572]: debug3: ssh_msg_send: type 0 > > > May 2 17:10:32 neodymium sshd[572]: debug3: send_rexec_state: done > > > May 2 17:10:32 neodymium sshd[752]: debug3: oom_adjust_restore > > > May 2 17:10:32 neodymium sshd[752]: Set /proc/self/oom_score_adj to 0 > > > May 2 17:10:32 neodymium sshd[752]: debug1: rexec start in 5 out 5 > > > newsock 5 pipe 7 sock 8 > > > May 2 17:10:32 neodymium sshd[752]: debug1: inetd sockets after > dupping: > > > 3, 3 > > > May 2 17:10:32 neodymium sshd[752]: Connection from 192.168.10.155 > port > > > 53106 on 192.168.50.63 port 22 > > > May 2 17:10:32 neodymium sshd[752]: debug1: Client protocol version > 2.0; > > > client software version PuTTY_KiTTY > > > May 2 17:10:32 neodymium sshd[752]: debug1: no match: PuTTY_KiTTY > > > May 2 17:10:32 neodymium sshd[752]: debug1: Enabling compatibility > mode > > > for protocol 2.0 > > > May 2 17:10:32 neodymium sshd[752]: debug1: Local version string > > > SSH-2.0-OpenSSH_6.6.1 > > > May 2 17:10:32 neodymium sshd[752]: debug2: fd 3 setting O_NONBLOCK > > > May 2 17:10:32 neodymium sshd[752]: debug3: ssh_sandbox_init: > preparing > > > rlimit sandbox > > > May 2 17:10:32 neodymium sshd[752]: debug2: Network child is on pid > 753 > > > May 2 17:10:32 neodymium sshd[752]: debug3: preauth child monitor > started > > > May 2 17:10:32 neodymium sshd[752]: debug1: SELinux support disabled > > > [preauth] > > > May 2 17:10:32 neodymium sshd[752]: debug3: privsep user:group 74:74 > > > [preauth] > > > May 2 17:10:32 neodymium sshd[752]: debug1: permanently_set_uid: 74/74 > > > [preauth] > > > May 2 17:10:32 neodymium sshd[752]: debug1: list_hostkey_types: > > > ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] > > > May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_send entering: > > > type 42 [preauth] > > >
Re: [Freeipa-users] GSSAPI authentication from trusted AD domain
On Tue, May 02, 2017 at 05:46:34PM +0200, Tiemen Ruiten wrote: > I think I just realised that my expectation may be wrong: GSSAPI login with > a FreeIPA user logged in on an AD host to a FreeIPA host works. So is it > correct to also expect passwordless login with an AD user to a FreeIPA host? The AD user case should work as well. First please send the SSSD version you use on the IPA client, alternatively you can check if /var/lib/sss/pubconf/krb5.include.d/localauth_plugin exists or not. This would tell if SSSD can map the user name to the Kerberos principal of if additional configuration is needed. On the AD host please check after trying to connect with ssh if there is a proper service ticket for the IPA client by calling 'klist' in cmd.exe or PowerShell. bye, Sumit > > On 2 May 2017 at 17:40, Jason B. Nance wrote: > > > Hi Tiemen, > > > > To be clear, what I'm trying to do: log in from an AD account > > (adm.tiemen), from an AD host (leon.clients.rdmedia.com) to a FreeIPA > > host (neodymium.test.ams.i.rdmedia.com) with the same AD account. I > > expect to be logged in through GSSAPI, instead I get a password prompt. > > > > I'm assuming that you are coming from a Windows client that is domain > > joined and logged into that Windows client with the same domain credentials > > that you are using to connect to the IPA-joined host. Do you also have > > your SSH client configured to attempt GSSAPI? It appears that you do from > > the logs you provided but I'm just double-checking. > > > > In my setup I've found that this feature does not work all of the time. > > I've not yet been able to track it down and I'm assuming it has something > > to do with connections to domain controllers timing out, but at this point > > that is speculation. > > > > So to answer your question, yes, that should work. Sorry I don't have > > more information for you, I guess I'm basically "me too"ing your post. > > > > Regards, > > > > j > > > > Is this supposed to work? Did I miss something? > > > > Below the SSH log from the FreeIPA host with LogLevel DEBUG3: > > > > May 2 17:10:32 neodymium sshd[572]: debug3: fd 5 is not O_NONBLOCK > > May 2 17:10:32 neodymium sshd[572]: debug1: Forked child 752. > > May 2 17:10:32 neodymium sshd[572]: debug3: send_rexec_state: entering fd > > = 8 config len 922 > > May 2 17:10:32 neodymium sshd[572]: debug3: ssh_msg_send: type 0 > > May 2 17:10:32 neodymium sshd[572]: debug3: send_rexec_state: done > > May 2 17:10:32 neodymium sshd[752]: debug3: oom_adjust_restore > > May 2 17:10:32 neodymium sshd[752]: Set /proc/self/oom_score_adj to 0 > > May 2 17:10:32 neodymium sshd[752]: debug1: rexec start in 5 out 5 > > newsock 5 pipe 7 sock 8 > > May 2 17:10:32 neodymium sshd[752]: debug1: inetd sockets after dupping: > > 3, 3 > > May 2 17:10:32 neodymium sshd[752]: Connection from 192.168.10.155 port > > 53106 on 192.168.50.63 port 22 > > May 2 17:10:32 neodymium sshd[752]: debug1: Client protocol version 2.0; > > client software version PuTTY_KiTTY > > May 2 17:10:32 neodymium sshd[752]: debug1: no match: PuTTY_KiTTY > > May 2 17:10:32 neodymium sshd[752]: debug1: Enabling compatibility mode > > for protocol 2.0 > > May 2 17:10:32 neodymium sshd[752]: debug1: Local version string > > SSH-2.0-OpenSSH_6.6.1 > > May 2 17:10:32 neodymium sshd[752]: debug2: fd 3 setting O_NONBLOCK > > May 2 17:10:32 neodymium sshd[752]: debug3: ssh_sandbox_init: preparing > > rlimit sandbox > > May 2 17:10:32 neodymium sshd[752]: debug2: Network child is on pid 753 > > May 2 17:10:32 neodymium sshd[752]: debug3: preauth child monitor started > > May 2 17:10:32 neodymium sshd[752]: debug1: SELinux support disabled > > [preauth] > > May 2 17:10:32 neodymium sshd[752]: debug3: privsep user:group 74:74 > > [preauth] > > May 2 17:10:32 neodymium sshd[752]: debug1: permanently_set_uid: 74/74 > > [preauth] > > May 2 17:10:32 neodymium sshd[752]: debug1: list_hostkey_types: > > ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] > > May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_send entering: > > type 42 [preauth] > > May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive_expect > > entering: type 43 [preauth] > > May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive entering > > [preauth] > > May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive entering > > May 2 17:10:32 neodymium sshd[752]: debug3: monitor_read: checking > > request 42 > > May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_send entering: > > type 43 > > May 2 17:10:32 neodymium sshd[752]: debug1: SSH2_MSG_KEXINIT sent > > [preauth] > > May 2 17:10:32 neodymium sshd[752]: debug1: SSH2_MSG_KEXINIT received > > [preauth] > > May 2 17:10:32 neodymium sshd[752]: debug2: kex_parse_kexinit: > > gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+ > > al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,curve > > 25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2- > > n
Re: [Freeipa-users] GSSAPI authentication from trusted AD domain
Hi Tiemen, > To be clear, what I'm trying to do: log in from an AD account (adm.tiemen), > from > an AD host ( [ http://leon.clients.rdmedia.com/ | leon.clients.rdmedia.com ] ) > to a FreeIPA host ( [ http://neodymium.test.ams.i.rdmedia.com/ | > neodymium.test.ams.i.rdmedia.com ] ) with the same AD account. I expect to be > logged in through GSSAPI, instead I get a password prompt. I'm assuming that you are coming from a Windows client that is domain joined and logged into that Windows client with the same domain credentials that you are using to connect to the IPA-joined host. Do you also have your SSH client configured to attempt GSSAPI? It appears that you do from the logs you provided but I'm just double-checking. In my setup I've found that this feature does not work all of the time. I've not yet been able to track it down and I'm assuming it has something to do with connections to domain controllers timing out, but at this point that is speculation. So to answer your question, yes, that should work. Sorry I don't have more information for you, I guess I'm basically "me too"ing your post. Regards, j > Is this supposed to work? Did I miss something? > Below the SSH log from the FreeIPA host with LogLevel DEBUG3: > May 2 17:10:32 neodymium sshd[572]: debug3: fd 5 is not O_NONBLOCK > May 2 17:10:32 neodymium sshd[572]: debug1: Forked child 752. > May 2 17:10:32 neodymium sshd[572]: debug3: send_rexec_state: entering fd = 8 > config len 922 > May 2 17:10:32 neodymium sshd[572]: debug3: ssh_msg_send: type 0 > May 2 17:10:32 neodymium sshd[572]: debug3: send_rexec_state: done > May 2 17:10:32 neodymium sshd[752]: debug3: oom_adjust_restore > May 2 17:10:32 neodymium sshd[752]: Set /proc/self/oom_score_adj to 0 > May 2 17:10:32 neodymium sshd[752]: debug1: rexec start in 5 out 5 newsock 5 > pipe 7 sock 8 > May 2 17:10:32 neodymium sshd[752]: debug1: inetd sockets after dupping: 3, 3 > May 2 17:10:32 neodymium sshd[752]: Connection from 192.168.10.155 port 53106 > on > 192.168.50.63 port 22 > May 2 17:10:32 neodymium sshd[752]: debug1: Client protocol version 2.0; > client > software version PuTTY_KiTTY > May 2 17:10:32 neodymium sshd[752]: debug1: no match: PuTTY_KiTTY > May 2 17:10:32 neodymium sshd[752]: debug1: Enabling compatibility mode for > protocol 2.0 > May 2 17:10:32 neodymium sshd[752]: debug1: Local version string > SSH-2.0-OpenSSH_6.6.1 > May 2 17:10:32 neodymium sshd[752]: debug2: fd 3 setting O_NONBLOCK > May 2 17:10:32 neodymium sshd[752]: debug3: ssh_sandbox_init: preparing rlimit > sandbox > May 2 17:10:32 neodymium sshd[752]: debug2: Network child is on pid 753 > May 2 17:10:32 neodymium sshd[752]: debug3: preauth child monitor started > May 2 17:10:32 neodymium sshd[752]: debug1: SELinux support disabled [preauth] > May 2 17:10:32 neodymium sshd[752]: debug3: privsep user:group 74:74 [preauth] > May 2 17:10:32 neodymium sshd[752]: debug1: permanently_set_uid: 74/74 > [preauth] > May 2 17:10:32 neodymium sshd[752]: debug1: list_hostkey_types: > ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] > May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_send entering: type 42 > [preauth] > May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive_expect > entering: > type 43 [preauth] > May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive entering > [preauth] > May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive entering > May 2 17:10:32 neodymium sshd[752]: debug3: monitor_read: checking request 42 > May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_send entering: type 43 > May 2 17:10:32 neodymium sshd[752]: debug1: SSH2_MSG_KEXINIT sent [preauth] > May 2 17:10:32 neodymium sshd[752]: debug1: SSH2_MSG_KEXINIT received > [preauth] > May 2 17:10:32 neodymium sshd[752]: debug2: kex_parse_kexinit: > gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==, > [ mailto:curve25519-sha...@libssh.org | curve25519-sha...@libssh.org ] > ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > [preauth] > May 2 17:10:32 neodymium sshd[752]: debug2: kex_parse_kexinit: > ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] > May 2 17:10:32 neodymium sshd[752]: debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, [ > mailto:aes128-...@openssh.com | aes128-...@openssh.com ] , [ > mailto:aes256-...@openssh.com | aes256-...@openssh.com ] , [ > mailto:chacha20-poly1...@openssh.com | chacha20-poly1...@openssh.com ] > ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, [ > mailto:rijndael-...@lysator.liu.se | rijndael-...@lysator.liu.se ] [preauth] > May 2 17:10:32 neodymium sshd[752]: debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, [ > mailto:aes128-...@openssh.com | aes12
Re: [Freeipa-users] GSSAPI authentication from trusted AD domain
> I think I just realised that my expectation may be wrong: GSSAPI login with a > FreeIPA user logged in on an AD host to a FreeIPA host works. So is it correct > to also expect passwordless login with an AD user to a FreeIPA host? If your FreeIPA domain trusts the AD domain, then yes, you can use an AD user to login to a FreeIPA-joined Linux host from a domain-joined Windows client where you are logged into the Windows client as the AD user (assuming you have your HBACs setup to allow - if you didn't password auth wouldn't work either). Unless you've configured "default_domain_suffix" in sssd.conf the user name is "adu...@addomain.tld". If you have configured "default_domain_suffix" make sure that your user names in AD don't conflict with the user names in IPA. Regards, j > On 2 May 2017 at 17:40, Jason B. Nance < [ mailto:ja...@tresgeek.net | > ja...@tresgeek.net ] > wrote: >> Hi Tiemen, >>> To be clear, what I'm trying to do: log in from an AD account (adm.tiemen), >>> from >>> an AD host ( [ http://leon.clients.rdmedia.com/ | leon.clients.rdmedia.com >>> ] ) >>> to a FreeIPA host ( [ http://neodymium.test.ams.i.rdmedia.com/ | >>> neodymium.test.ams.i.rdmedia.com ] ) with the same AD account. I expect to >>> be >>> logged in through GSSAPI, instead I get a password prompt. >> I'm assuming that you are coming from a Windows client that is domain joined >> and >> logged into that Windows client with the same domain credentials that you are >> using to connect to the IPA-joined host. Do you also have your SSH client >> configured to attempt GSSAPI? It appears that you do from the logs you >> provided >> but I'm just double-checking. >> In my setup I've found that this feature does not work all of the time. I've >> not >> yet been able to track it down and I'm assuming it has something to do with >> connections to domain controllers timing out, but at this point that is >> speculation. >> So to answer your question, yes, that should work. Sorry I don't have more >> information for you, I guess I'm basically "me too"ing your post. >> Regards, >> j >>> Is this supposed to work? Did I miss something? >>> Below the SSH log from the FreeIPA host with LogLevel DEBUG3: >>> May 2 17:10:32 neodymium sshd[572]: debug3: fd 5 is not O_NONBLOCK >>> May 2 17:10:32 neodymium sshd[572]: debug1: Forked child 752. >>> May 2 17:10:32 neodymium sshd[572]: debug3: send_rexec_state: entering fd = >>> 8 >>> config len 922 >>> May 2 17:10:32 neodymium sshd[572]: debug3: ssh_msg_send: type 0 >>> May 2 17:10:32 neodymium sshd[572]: debug3: send_rexec_state: done >>> May 2 17:10:32 neodymium sshd[752]: debug3: oom_adjust_restore >>> May 2 17:10:32 neodymium sshd[752]: Set /proc/self/oom_score_adj to 0 >>> May 2 17:10:32 neodymium sshd[752]: debug1: rexec start in 5 out 5 newsock 5 >>> pipe 7 sock 8 >>> May 2 17:10:32 neodymium sshd[752]: debug1: inetd sockets after dupping: 3, >>> 3 >>> May 2 17:10:32 neodymium sshd[752]: Connection from 192.168.10.155 port >>> 53106 on >>> 192.168.50.63 port 22 >>> May 2 17:10:32 neodymium sshd[752]: debug1: Client protocol version 2.0; >>> client >>> software version PuTTY_KiTTY >>> May 2 17:10:32 neodymium sshd[752]: debug1: no match: PuTTY_KiTTY >>> May 2 17:10:32 neodymium sshd[752]: debug1: Enabling compatibility mode for >>> protocol 2.0 >>> May 2 17:10:32 neodymium sshd[752]: debug1: Local version string >>> SSH-2.0-OpenSSH_6.6.1 >>> May 2 17:10:32 neodymium sshd[752]: debug2: fd 3 setting O_NONBLOCK >>> May 2 17:10:32 neodymium sshd[752]: debug3: ssh_sandbox_init: preparing >>> rlimit >>> sandbox >>> May 2 17:10:32 neodymium sshd[752]: debug2: Network child is on pid 753 >>> May 2 17:10:32 neodymium sshd[752]: debug3: preauth child monitor started >>> May 2 17:10:32 neodymium sshd[752]: debug1: SELinux support disabled >>> [preauth] >>> May 2 17:10:32 neodymium sshd[752]: debug3: privsep user:group 74:74 >>> [preauth] >>> May 2 17:10:32 neodymium sshd[752]: debug1: permanently_set_uid: 74/74 >>> [preauth] >>> May 2 17:10:32 neodymium sshd[752]: debug1: list_hostkey_types: >>> ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] >>> May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_send entering: type >>> 42 >>> [preauth] >>> May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive_expect >>> entering: >>> type 43 [preauth] >>> May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive entering >>> [preauth] >>> May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive entering >>> May 2 17:10:32 neodymium sshd[752]: debug3: monitor_read: checking request >>> 42 >>> May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_send entering: type >>> 43 >>> May 2 17:10:32 neodymium sshd[752]: debug1: SSH2_MSG_KEXINIT sent [preauth] >>> May 2 17:10:32 neodymium sshd[752]: debug1: SSH2_MSG_KEXINIT received >>> [preauth] >>> May 2 17:10:32 neodymium sshd[752]: debug2: kex_parse_kexinit: >>> gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-
Re: [Freeipa-users] GSSAPI authentication from trusted AD domain
I think I just realised that my expectation may be wrong: GSSAPI login with a FreeIPA user logged in on an AD host to a FreeIPA host works. So is it correct to also expect passwordless login with an AD user to a FreeIPA host? On 2 May 2017 at 17:40, Jason B. Nance wrote: > Hi Tiemen, > > To be clear, what I'm trying to do: log in from an AD account > (adm.tiemen), from an AD host (leon.clients.rdmedia.com) to a FreeIPA > host (neodymium.test.ams.i.rdmedia.com) with the same AD account. I > expect to be logged in through GSSAPI, instead I get a password prompt. > > I'm assuming that you are coming from a Windows client that is domain > joined and logged into that Windows client with the same domain credentials > that you are using to connect to the IPA-joined host. Do you also have > your SSH client configured to attempt GSSAPI? It appears that you do from > the logs you provided but I'm just double-checking. > > In my setup I've found that this feature does not work all of the time. > I've not yet been able to track it down and I'm assuming it has something > to do with connections to domain controllers timing out, but at this point > that is speculation. > > So to answer your question, yes, that should work. Sorry I don't have > more information for you, I guess I'm basically "me too"ing your post. > > Regards, > > j > > Is this supposed to work? Did I miss something? > > Below the SSH log from the FreeIPA host with LogLevel DEBUG3: > > May 2 17:10:32 neodymium sshd[572]: debug3: fd 5 is not O_NONBLOCK > May 2 17:10:32 neodymium sshd[572]: debug1: Forked child 752. > May 2 17:10:32 neodymium sshd[572]: debug3: send_rexec_state: entering fd > = 8 config len 922 > May 2 17:10:32 neodymium sshd[572]: debug3: ssh_msg_send: type 0 > May 2 17:10:32 neodymium sshd[572]: debug3: send_rexec_state: done > May 2 17:10:32 neodymium sshd[752]: debug3: oom_adjust_restore > May 2 17:10:32 neodymium sshd[752]: Set /proc/self/oom_score_adj to 0 > May 2 17:10:32 neodymium sshd[752]: debug1: rexec start in 5 out 5 > newsock 5 pipe 7 sock 8 > May 2 17:10:32 neodymium sshd[752]: debug1: inetd sockets after dupping: > 3, 3 > May 2 17:10:32 neodymium sshd[752]: Connection from 192.168.10.155 port > 53106 on 192.168.50.63 port 22 > May 2 17:10:32 neodymium sshd[752]: debug1: Client protocol version 2.0; > client software version PuTTY_KiTTY > May 2 17:10:32 neodymium sshd[752]: debug1: no match: PuTTY_KiTTY > May 2 17:10:32 neodymium sshd[752]: debug1: Enabling compatibility mode > for protocol 2.0 > May 2 17:10:32 neodymium sshd[752]: debug1: Local version string > SSH-2.0-OpenSSH_6.6.1 > May 2 17:10:32 neodymium sshd[752]: debug2: fd 3 setting O_NONBLOCK > May 2 17:10:32 neodymium sshd[752]: debug3: ssh_sandbox_init: preparing > rlimit sandbox > May 2 17:10:32 neodymium sshd[752]: debug2: Network child is on pid 753 > May 2 17:10:32 neodymium sshd[752]: debug3: preauth child monitor started > May 2 17:10:32 neodymium sshd[752]: debug1: SELinux support disabled > [preauth] > May 2 17:10:32 neodymium sshd[752]: debug3: privsep user:group 74:74 > [preauth] > May 2 17:10:32 neodymium sshd[752]: debug1: permanently_set_uid: 74/74 > [preauth] > May 2 17:10:32 neodymium sshd[752]: debug1: list_hostkey_types: > ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] > May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_send entering: > type 42 [preauth] > May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive_expect > entering: type 43 [preauth] > May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive entering > [preauth] > May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive entering > May 2 17:10:32 neodymium sshd[752]: debug3: monitor_read: checking > request 42 > May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_send entering: > type 43 > May 2 17:10:32 neodymium sshd[752]: debug1: SSH2_MSG_KEXINIT sent > [preauth] > May 2 17:10:32 neodymium sshd[752]: debug1: SSH2_MSG_KEXINIT received > [preauth] > May 2 17:10:32 neodymium sshd[752]: debug2: kex_parse_kexinit: > gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+ > al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,curve > 25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2- > nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange- > sha256,diffie-hellman-group-exchange-sha1,diffie-hellman- > group14-sha1,diffie-hellman-group1-sha1 [preauth] > May 2 17:10:32 neodymium sshd[752]: debug2: kex_parse_kexinit: > ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] > May 2 17:10:32 neodymium sshd[752]: debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes1 > 28-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com > ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc, > aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se [preauth] > May 2 17:10:32 neodymium sshd[752]: debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
[Freeipa-users] GSSAPI authentication from trusted AD domain
Hello, I now have a working two-way trust between Active Directory ( clients.rdmedia.com) and FreeIPA (i.rdmedia.com). Users from the AD can authenticate to FreeIPA hosts and the other way around. Great! Next, I'm trying to achieve passwordless Single Sign On through GSSAPI for Windows clients to FreeIPA hosts. This doesn't seem to be working, despite setting ipa host-mod --ok-as-delegate=TRUE To be clear, what I'm trying to do: log in from an AD account (adm.tiemen), from an AD host (leon.clients.rdmedia.com) to a FreeIPA host ( neodymium.test.ams.i.rdmedia.com) with the same AD account. I expect to be logged in through GSSAPI, instead I get a password prompt. Is this supposed to work? Did I miss something? Below the SSH log from the FreeIPA host with LogLevel DEBUG3: May 2 17:10:32 neodymium sshd[572]: debug3: fd 5 is not O_NONBLOCK May 2 17:10:32 neodymium sshd[572]: debug1: Forked child 752. May 2 17:10:32 neodymium sshd[572]: debug3: send_rexec_state: entering fd = 8 config len 922 May 2 17:10:32 neodymium sshd[572]: debug3: ssh_msg_send: type 0 May 2 17:10:32 neodymium sshd[572]: debug3: send_rexec_state: done May 2 17:10:32 neodymium sshd[752]: debug3: oom_adjust_restore May 2 17:10:32 neodymium sshd[752]: Set /proc/self/oom_score_adj to 0 May 2 17:10:32 neodymium sshd[752]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8 May 2 17:10:32 neodymium sshd[752]: debug1: inetd sockets after dupping: 3, 3 May 2 17:10:32 neodymium sshd[752]: Connection from 192.168.10.155 port 53106 on 192.168.50.63 port 22 May 2 17:10:32 neodymium sshd[752]: debug1: Client protocol version 2.0; client software version PuTTY_KiTTY May 2 17:10:32 neodymium sshd[752]: debug1: no match: PuTTY_KiTTY May 2 17:10:32 neodymium sshd[752]: debug1: Enabling compatibility mode for protocol 2.0 May 2 17:10:32 neodymium sshd[752]: debug1: Local version string SSH-2.0-OpenSSH_6.6.1 May 2 17:10:32 neodymium sshd[752]: debug2: fd 3 setting O_NONBLOCK May 2 17:10:32 neodymium sshd[752]: debug3: ssh_sandbox_init: preparing rlimit sandbox May 2 17:10:32 neodymium sshd[752]: debug2: Network child is on pid 753 May 2 17:10:32 neodymium sshd[752]: debug3: preauth child monitor started May 2 17:10:32 neodymium sshd[752]: debug1: SELinux support disabled [preauth] May 2 17:10:32 neodymium sshd[752]: debug3: privsep user:group 74:74 [preauth] May 2 17:10:32 neodymium sshd[752]: debug1: permanently_set_uid: 74/74 [preauth] May 2 17:10:32 neodymium sshd[752]: debug1: list_hostkey_types: ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_send entering: type 42 [preauth] May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive_expect entering: type 43 [preauth] May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive entering [preauth] May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive entering May 2 17:10:32 neodymium sshd[752]: debug3: monitor_read: checking request 42 May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_send entering: type 43 May 2 17:10:32 neodymium sshd[752]: debug1: SSH2_MSG_KEXINIT sent [preauth] May 2 17:10:32 neodymium sshd[752]: debug1: SSH2_MSG_KEXINIT received [preauth] May 2 17:10:32 neodymium sshd[752]: debug2: kex_parse_kexinit: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==, curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth] May 2 17:10:32 neodymium sshd[752]: debug2: kex_parse_kexinit: ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] May 2 17:10:32 neodymium sshd[752]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-...@lysator.liu.se [preauth] May 2 17:10:32 neodymium sshd[752]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-...@lysator.liu.se [preauth] May 2 17:10:32 neodymium sshd[752]: debug2: kex_parse_kexinit: hmac-md5-...@openssh.com,hmac-sha1-...@openssh.com,umac-64-...@openssh.com, umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com, hmac-sha2-512-...@openssh.com,hmac-ripemd160-...@openssh.com, hmac-sha1-96-...@openssh.com,hmac-md5-96-...@openssh.com,hmac-md5,hmac-sha1, umac...@openssh.com,umac-...@openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth] May 2 17:10:32 neodymium sshd[752]: debug2: kex_parse_kexinit: hmac-md5-...@openssh.com,hmac-sha1-...@openssh.com,umac-64-...@openssh.com,
