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 Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos