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 ::ffff: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 ::ffff: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 ::ffff: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 ::ffff: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 ::ffff: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     Expires            Service 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     Expires            Service 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           [email protected]
> > https://mailman.mit.edu/mailman/listinfo/kerberos
> > 
> 
> 
> 
> ________________________________________________
> Kerberos mailing list           [email protected]
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 


-- 
Michael B Allen
PHP Active Directory Kerberos SSO
http://www.ioplex.com/
________________________________________________
Kerberos mailing list           [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos

Reply via email to