Re: Cross Realm MIT - Windows Close But No Cigar
What does sshd -ddde show when you connect ? Do you use a .k5login or auth_to_local ? Markus Michael B Allen [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello, I struggling with cross realm auth and I'd appreciate it if someone can give me pointers. The problem seems to be with enctypes. So I just asserted RC4 everywhere and now I'm getting all the right tickets but ssh and smbclient still aren't quite satisfied. Info about the two domains and ssh / smbclient test results follows. S.W.NET MIT 1.3.4-46 on CentOS 4.4 I created KDC as usual but before creating the db I put the following in my kdc.conf: supported_enctypes = arcfour-hmac:normal I created some principals and it confirmed the enctype was archfour-hmac: kadmin.local: ktadd [EMAIL PROTECTED] Entry for principal [EMAIL PROTECTED] with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab. krb5.conf is standard except I added W.NET to the [realms] and [domain_realm] sections (not sure if that's necessary). I created a host/[EMAIL PROTECTED] principal and exported it to the /etc/krb5.keytab (for ssh). W.NET W2K3 standard ktsetup /addkdc S.W.NET ls1.s.w.net ktpass /MitRealmName S.W.NET /TrustEncryp RC4 Created two-way trust with AD Domains and Trusts. Rebooted. So with everything setup like above I tried ssh and smbclient. -- Testing with SSH with W.NET TGT -- Ssh doesn't tell me much: $ ssh -vvv [EMAIL PROTECTED] ... debug1: Next authentication method: gssapi-with-mic debug3: Trying to reverse map address 192.168.2.20. debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug2: we did not send a packet, disable method but I can see I have the right tickets: $ klist Ticket cache: FILE:/tmp/krb5cc_500 Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 05/02/07 21:35:40 05/03/07 07:36:11 krbtgt/[EMAIL PROTECTED] renew until 05/03/07 21:35:40 05/02/07 21:36:23 05/03/07 07:36:11 krbtgt/[EMAIL PROTECTED] renew until 05/03/07 21:35:40 05/02/07 21:36:04 05/03/07 07:36:11 host/[EMAIL PROTECTED] renew until 05/02/07 21:36:04 Ssh with an S.W.NET TGT to ls1.s.w.net works fine (no password). -- Testing with smbclient with S.W.NET TGT -- $ smbclient -k //dc1.w.net/tmp signing_good: BAD SIG: seq 1 SMB Signature verification failed on incoming packet! session setup failed: Server packet had invalid SMB signature! again I have the right tickets: $ klist Ticket cache: FILE:/tmp/krb5cc_500 Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 05/02/07 21:27:56 05/03/07 21:27:56 krbtgt/[EMAIL PROTECTED] 05/02/07 21:33:35 05/03/07 21:27:56 krbtgt/[EMAIL PROTECTED] 05/02/07 21:33:55 05/03/07 07:33:55 [EMAIL PROTECTED] The signature in the SMB response packet is identical to the one in the request packet (i.e. it was echo'd). Any ideas? Do I need to do anything special with DNS? Mike -- Michael B Allen PHP Active Directory Kerberos SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Cross Realm MIT - Windows Close But No Cigar
On Thu, 3 May 2007 23:33:29 +0100 Markus Moeller [EMAIL PROTECTED] wrote: What does sshd -ddde show when you connect ? Do you use a .k5login or auth_to_local ? Hi Markus, I'm not familiar with .k5login or auth_to_local. The only thing I changed in sshd_config was I turned of UsePAM. I actually think the trust is valid. I've been trying it with my HTTP SSO code and the GSS calls are definitely succeeding. It's something that happends after the auth (e.g. RC4 salting or session key problem). Thanks, Mike debug1: userauth-request for user ioplex service ssh-connection method gssapi-with-mic debug1: attempt 1 failures 1 debug2: input_userauth_request: try method gssapi-with-mic debug3: mm_request_send entering: type 38 debug3: monitor_read: checking request 38 debug3: mm_request_receive_expect entering: type 39 debug3: mm_request_receive entering debug3: mm_request_send entering: type 39 debug3: mm_request_receive entering Postponed gssapi-with-mic for ioplex from :::192.168.2.16 port 48735 ssh2 debug3: mm_request_send entering: type 40 debug3: monitor_read: checking request 40 debug3: mm_request_receive_expect entering: type 41 debug3: mm_request_receive entering debug1: Got no client credentials debug3: mm_request_send entering: type 41 debug3: mm_request_receive entering debug3: mm_request_send entering: type 44 debug3: mm_request_receive_expect entering: type 45 debug3: mm_request_receive entering debug3: monitor_read: checking request 44 debug3: mm_request_send entering: type 45 debug3: mm_request_receive entering debug3: mm_request_send entering: type 42 debug3: mm_request_receive_expect entering: type 43 debug3: mm_request_receive entering debug3: monitor_read: checking request 42 debug3: mm_answer_gss_userok: sending result 0 debug3: mm_request_send entering: type 43 Failed gssapi-with-mic for ioplex from :::192.168.2.16 port 48735 ssh2 debug3: mm_request_receive entering debug3: mm_ssh_gssapi_userok: user not authenticated Failed gssapi-with-mic for ioplex from :::192.168.2.16 port 48735 ssh2 debug1: userauth-request for user ioplex service ssh-connection method gssapi-with-mic debug1: attempt 2 failures 2 debug2: input_userauth_request: try method gssapi-with-mic Failed gssapi-with-mic for ioplex from :::192.168.2.16 port 48735 ssh2 debug1: userauth-request for user ioplex service ssh-connection method gssapi-with-mic debug1: attempt 3 failures 3 debug2: input_userauth_request: try method gssapi-with-mic Failed gssapi-with-mic for ioplex from :::192.168.2.16 port 48735 ssh2 debug1: userauth-request for user ioplex service ssh-connection method publickey debug1: attempt 4 failures 4 Michael B Allen [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello, I struggling with cross realm auth and I'd appreciate it if someone can give me pointers. The problem seems to be with enctypes. So I just asserted RC4 everywhere and now I'm getting all the right tickets but ssh and smbclient still aren't quite satisfied. Info about the two domains and ssh / smbclient test results follows. S.W.NET MIT 1.3.4-46 on CentOS 4.4 I created KDC as usual but before creating the db I put the following in my kdc.conf: supported_enctypes = arcfour-hmac:normal I created some principals and it confirmed the enctype was archfour-hmac: kadmin.local: ktadd [EMAIL PROTECTED] Entry for principal [EMAIL PROTECTED] with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab. krb5.conf is standard except I added W.NET to the [realms] and [domain_realm] sections (not sure if that's necessary). I created a host/[EMAIL PROTECTED] principal and exported it to the /etc/krb5.keytab (for ssh). W.NET W2K3 standard ktsetup /addkdc S.W.NET ls1.s.w.net ktpass /MitRealmName S.W.NET /TrustEncryp RC4 Created two-way trust with AD Domains and Trusts. Rebooted. So with everything setup like above I tried ssh and smbclient. -- Testing with SSH with W.NET TGT -- Ssh doesn't tell me much: $ ssh -vvv [EMAIL PROTECTED] ... debug1: Next authentication method: gssapi-with-mic debug3: Trying to reverse map address 192.168.2.20. debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug2: we did not send a packet, disable method but I can see I have the right tickets: $ klist Ticket cache: FILE:/tmp/krb5cc_500 Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 05/02/07 21:35:40 05/03/07 07:36:11 krbtgt/[EMAIL PROTECTED] renew
Re: Cross Realm MIT - Windows Close But No Cigar
Michael B Allen [EMAIL PROTECTED] wrote: On Thu, 3 May 2007 23:33:29 +0100 Markus Moeller [EMAIL PROTECTED] wrote: What does sshd -ddde show when you connect ? Do you use a .k5login or auth_to_local ? Hi Markus, I'm not familiar with .k5login or auth_to_local. The only thing I changed in sshd_config was I turned of UsePAM. Kerberos only handles authentication. You need something for authorization. By default, the kerberos libraries will match principals in the local default realm to local users. (principal == local user name.) [EMAIL PROTECTED] can login as cclausen. [EMAIL PROTECTED] cannot login without authorization. I actually think the trust is valid. I've been trying it with my HTTP SSO code and the GSS calls are definitely succeeding. It's something that happends after the auth (e.g. RC4 salting or session key problem). Setting up a trust does NOT automatically grant authorization for the foreign realm. Try creating a ~/.k5login file in the home directory of the user you are logging in as listing authorized Kerberos principals, one per line. (AD.UIUC.EDU is a Windows AD domain. ILLIGAL.UIUC.EDU is a MIT realm.) For instance: C:\klist Ticket cache: API:[EMAIL PROTECTED] Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 05/03/07 20:26:36 05/04/07 06:26:36 krbtgt/[EMAIL PROTECTED] C:\putty ial.illigal.uiuc.edu C:\klist Ticket cache: API:[EMAIL PROTECTED] Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 05/03/07 20:26:36 05/04/07 06:26:36 krbtgt/[EMAIL PROTECTED] 05/03/07 20:26:36 05/04/07 06:26:36 krbtgt/[EMAIL PROTECTED] 05/03/07 20:26:58 05/04/07 06:26:36 host/[EMAIL PROTECTED] On the remote system: [EMAIL PROTECTED]:~$ cat .k5login [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]:~$ klist Ticket cache: FILE:/tmp/krb5cc_1000_L30429 Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 05/03/07 20:26:58 05/04/07 06:26:36 krbtgt/[EMAIL PROTECTED] [EMAIL PROTECTED]:~$ cat /etc/krb5.conf | grep default [libdefaults] default_realm = ILLIGAL.UIUC.EDU [EMAIL PROTECTED]:~$ CDC Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Cross Realm MIT - Windows Close But No Cigar
On Thu, 3 May 2007 20:31:55 -0500 Christopher D. Clausen [EMAIL PROTECTED] wrote: Try creating a ~/.k5login file in the home directory of the user you are logging in as listing authorized Kerberos principals, one per line. That was it! SSH now works cross realm. I was clueless about .k5login. Now I wonder what smbclient's problem is with the bad echo'd signatures. Wheres Andrew Bartlett when you need him ... Mmm, UIUC. I have droves of family in Champaign. Thanks, Mike -- Michael B Allen PHP Active Directory Kerberos SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Cross Realm MIT - Windows Close But No Cigar
Michael B Allen [EMAIL PROTECTED] wrote: On Thu, 3 May 2007 20:31:55 -0500 Christopher D. Clausen [EMAIL PROTECTED] wrote: Try creating a ~/.k5login file in the home directory of the user you are logging in as listing authorized Kerberos principals, one per line. That was it! SSH now works cross realm. I was clueless about .k5login. You can use an auth_to_local rule in krb5.conf instead. Search this list for a post a few weeks back for some to try. Now I wonder what smbclient's problem is with the bad echo'd signatures. Wheres Andrew Bartlett when you need him ... After I broke AD.UIUC.EDU (yes, campus wide) several years ago using samba, I haven't touched it. But I suspect that is a question for a samba list. I assume you have looked at the KDC logs and possible some network traces to try and figure out what is going on? Mmm, UIUC. I have droves of family in Champaign. I don't. Thats why I moved here :-) CDC Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Cross Realm MIT - Windows Close But No Cigar
Hello, I struggling with cross realm auth and I'd appreciate it if someone can give me pointers. The problem seems to be with enctypes. So I just asserted RC4 everywhere and now I'm getting all the right tickets but ssh and smbclient still aren't quite satisfied. Info about the two domains and ssh / smbclient test results follows. S.W.NET MIT 1.3.4-46 on CentOS 4.4 I created KDC as usual but before creating the db I put the following in my kdc.conf: supported_enctypes = arcfour-hmac:normal I created some principals and it confirmed the enctype was archfour-hmac: kadmin.local: ktadd [EMAIL PROTECTED] Entry for principal [EMAIL PROTECTED] with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab. krb5.conf is standard except I added W.NET to the [realms] and [domain_realm] sections (not sure if that's necessary). I created a host/[EMAIL PROTECTED] principal and exported it to the /etc/krb5.keytab (for ssh). W.NET W2K3 standard ktsetup /addkdc S.W.NET ls1.s.w.net ktpass /MitRealmName S.W.NET /TrustEncryp RC4 Created two-way trust with AD Domains and Trusts. Rebooted. So with everything setup like above I tried ssh and smbclient. -- Testing with SSH with W.NET TGT -- Ssh doesn't tell me much: $ ssh -vvv [EMAIL PROTECTED] ... debug1: Next authentication method: gssapi-with-mic debug3: Trying to reverse map address 192.168.2.20. debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug2: we did not send a packet, disable method but I can see I have the right tickets: $ klist Ticket cache: FILE:/tmp/krb5cc_500 Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 05/02/07 21:35:40 05/03/07 07:36:11 krbtgt/[EMAIL PROTECTED] renew until 05/03/07 21:35:40 05/02/07 21:36:23 05/03/07 07:36:11 krbtgt/[EMAIL PROTECTED] renew until 05/03/07 21:35:40 05/02/07 21:36:04 05/03/07 07:36:11 host/[EMAIL PROTECTED] renew until 05/02/07 21:36:04 Ssh with an S.W.NET TGT to ls1.s.w.net works fine (no password). -- Testing with smbclient with S.W.NET TGT -- $ smbclient -k //dc1.w.net/tmp signing_good: BAD SIG: seq 1 SMB Signature verification failed on incoming packet! session setup failed: Server packet had invalid SMB signature! again I have the right tickets: $ klist Ticket cache: FILE:/tmp/krb5cc_500 Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 05/02/07 21:27:56 05/03/07 21:27:56 krbtgt/[EMAIL PROTECTED] 05/02/07 21:33:35 05/03/07 21:27:56 krbtgt/[EMAIL PROTECTED] 05/02/07 21:33:55 05/03/07 07:33:55 [EMAIL PROTECTED] The signature in the SMB response packet is identical to the one in the request packet (i.e. it was echo'd). Any ideas? Do I need to do anything special with DNS? Mike -- Michael B Allen PHP Active Directory Kerberos SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
