Jason Mogavero wrote:
> There is no .k5login file in the home directory...though the user account
> does exist on the machine, eventually the user database is going be stored
> on LDAP and there will not be individual user accounts on the ssh servers.
>
>
> Shouldn't the ACL take precedence anyway? I don't have a .k5login in the
> kdcadmin user's home directory and that one can authenticate just fine.
> (albeit from a ticket granted by the non-windows kdc and not the AD and the
> kdcadmin user principal is in the non-windows kerberos database)
That is the default if no ~/.k5login is found. i.e. [EMAIL PROTECTED] where user
matches the unix account name, and realm is the default realm of the machine.
It is easy to see if this is the problem, add a .k5login file. If that works,
then you can address how to get alongf without it.
>
> Is there some blanket way of telling the non-Windows kerberos service to
> authenticate any principle @KDCTEST.COM? (the Windows KDC) I thought the
> kadm5.acl would allow me to do that.
>
>
>
> On 8/21/06, Douglas E. Engert <[EMAIL PROTECTED]> wrote:
>
>>
>> Do you have a .k5login file in the home directory on the
>> machine with the sshd? It should list the principals that
>> are allowed to access this unix account.
>>
>> Note the return codes from the mm_answer_gss_userok is 1 when it
>> worked, 0 when it did not. So it looks like the gss authenticated you
>> but the principal was not allowed to use the unix account.
>>
>>
>>
>> Jason Mogavero wrote:
>>
>> > Ok, I found part one of my problem, in that on the non-windows KDC I
>> had
>> > not
>> > specified an encryption type and whatever is the default was not
>> working
>> > with the windows DC. I've fixed that and I can now get issued tickets
>> by
>> > the non-windows KDC. Here is the kdc.log entry for my ticket
>> generation:
>> >
>> > Aug 21 13:59:47 kdcdmz.kdctest.com krb5kdc[29511](info): TGS_REQ (5
>> etypes
>> > {23 3 1 24 -135}) 172.16.102.28: ISSUE: authtime 1156189823, etypes
>> {rep=3
>> > tkt=16 ses=1}, [EMAIL PROTECTED] for
>> > host/[EMAIL PROTECTED]
>> > Aug 21 13:59:47 kdcdmz.kdctest.com krb5kdc[29511](info): TGS_REQ (5
>> etypes
>> > {23 3 1 24 -135}) 172.16.102.28: ISSUE: authtime 1156189823, etypes
>> {rep=3
>> > tkt=16 ses=1}, [EMAIL PROTECTED] for
>> > host/[EMAIL PROTECTED]
>> >
>> > However, GSSAPI is still failing. The logging in PuTTY shows a general
>> > SSPI
>> > failure, but nothing specific other than the ssh server is kicking back
>> a
>> > reject. (note that GSSAPI works on a Linux system that connects via
>> > openssh
>> > and is authenticated the the non-windows KDC)
>> >
>> > I ran sshd in debug mode, and compared the output from a rejected
>> GSSAPI
>> > session and an accepted one. Here is the accepted:
>> >
>> > Aug 21 14:21:30 kdcvps1 sshd[19893]: debug1: Received some client
>> > credentials
>> > Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_request_send entering:
>> type
>> > 41
>> > Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_request_receive
>> entering
>> > Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: monitor_read: checking
>> request
>> > 44
>> > Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_request_send entering:
>> type
>> > 45
>> > Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_request_receive
>> entering
>> > Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: monitor_read: checking
>> request
>> > 42
>> > Aug 21 14:21:30 kdcvps1 sshd[19893]: Authorized to kdcadmin, krb5
>> principal
>> > [EMAIL PROTECTED] (krb5_kuserok)
>> > Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_answer_gss_userok:
>> sending
>> > result 1
>> > Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_request_send entering:
>> type
>> > 43
>> > Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_request_receive_expect
>> > entering: type 47
>> > Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_request_receive
>> entering
>> > Aug 21 14:21:31 kdcvps1 sshd[19893]: debug3: PAM: do_pam_account
>> > pam_acct_mgmt = 0
>> > Aug 21 14:21:31 kdcvps1 sshd[19893]: debug3: mm_request_send entering:
>> type
>> > 48
>> > Aug 21 14:21:31 kdcvps1 sshd[19893]: Accepted gssapi-with-mic for
>> kdcadmin
>> > from 172.16.102.112 port 32957 ssh2
>> >
>> > And here is the failed one:
>> >
>> > Aug 21 14:01:35 kdcvps1 sshd[19853]: debug1: Received some client
>> > credentials
>> > Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: mm_request_send entering:
>> type
>> > 41
>> > Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: mm_request_receive
>> entering
>> > Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: monitor_read: checking
>> request
>> > 44
>> > Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: mm_request_send entering:
>> type
>> > 45
>> > Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: mm_request_receive
>> entering
>> > Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: monitor_read: checking
>> request
>> > 42
>> > Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: mm_answer_gss_userok:
>> sending
>> > result 0
>> > Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: mm_request_send entering:
>> type
>> > 43
>> > Aug 21 14:01:35 kdcvps1 sshd[19853]: Failed gssapi-with-mic for
>> > jason.mogavero from 172.16.102.28 port 4292 ssh2
>> >
>> > So it seems that even though I am getting a tgt from the non-Windows
>> KDC, I
>> > am not being authorized by this "checking request 42" which I imagine
>> > checks
>> > against the non-Win KDC. I don't need to have every user in the
>> Windows
>> AD
>> > in the non-Windows KDC user database as well, do I? I thought the
>> point
>> of
>> > the one-way trust was to allow users authenticated in one realm to have
>> > access to resources in another. Is this an ACL issue? I have an entry
>> in
>> > the kadm5.acl file on the non-windows KDC that says:
>> >
>> > [EMAIL PROTECTED] *
>> >
>> > Is not not correct syntax?
>> >
>> > On 8/18/06, Douglas E. Engert <[EMAIL PROTECTED]> wrote:
>> >
>> >>
>> >>
>> >>
>> >> Jason Mogavero wrote:
>> >>
>> >> > Hello all,
>> >> >
>> >> > I am implementing a Kerberos/GSSAPI solution in a test
>> environment
>> >> and I
>> >> > am experiencing some issues with allowed windows ssh clients to be
>> >> granted
>> >> > acess to the ssh server.
>> >> >
>> >> > The background:
>> >> >
>> >> > Windows AD is primary kdc with realm name KDCTEST.COM and hostname
>> >> > adauth.kdctest.com
>> >> > MIT kdc (on CentOS 4.3, installed from rpms) is DMZ.KDCTEST.COM
>> >> >
>> >> > ssh server is hostname kdcvps1.kdctest.com
>> >> > ssh client (linux) is kdcvps2.kdctest.com
>> >> > windows ssh client is kdctest01.kdctest.com
>> >> >
>> >> > I am able to passwordlessly log into the ssh server from the Linux
>> ssh
>> >> > client via gssapi. When I connect from PuTTY or SecureCRT in GSSAPI
>> >> mode,
>> >> > it fails. PuTTY prompts me for a password and SecureCRT errors out
>> >> with
>> >> > "All available GSSAPI mechanisms failed" Here is the kdc.log
>> entry I
>> >> get:
>> >>
>> >> Sounds like the cross realm keys are not setup correctly, i.e. the
>> kvno
>> >> key or enc types are different in AD and krb KDC for the
>> >> krbtgt/[EMAIL PROTECTED] principal on both sides. You can
>> use
>> >> mmc
>> >> and ADSIEdit to look at AD at the acocunt you created for the trust to
>> >> see
>> >> the key version number on 2003.
>> >>
>> >> You could use ethereal (wireshark) on Windows to watch the client
>> contact
>> >> the
>> >> AD to get a cross realm ticket, then try and use it with the krb
>> KDC to
>> >> get
>> >> the service ticket. It would show the kvno and enctypes being used.
>> >>
>> >> It could also be the keys don't match, because of the way they where
>> >> generated from passwords on each side. I assume you used the 2003
>> ktpass
>> >> Getting a keytab with the out option could help identify problems too.
>> >>
>> >> ---snip--
>> >> --
>> >>
>> >> Douglas E. Engert <[EMAIL PROTECTED]>
>> >> Argonne National Laboratory
>> >> 9700 South Cass Avenue
>> >> Argonne, Illinois 60439
>> >> (630) 252-5444
>> >>
>> >
>>
>> --
>>
>> Douglas E. Engert <[EMAIL PROTECTED]>
>> Argonne National Laboratory
>> 9700 South Cass Avenue
>> Argonne, Illinois 60439
>> (630) 252-5444
>>
>
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
