help with Active Directory Kerberos authentication

[Rohit Kumar Mehta]

Thanks Russ, I think you might have found something.
I did the command you suggested ssh -ddd 2>/tmp/err.txt
and found an interesting message in the long file it created.

	debug1: Miscellaneous failure
	No principal in keytab matches desired name.

My krb5.keytab looks like this:
	nfsv4etch:~# ktutil
	ktutil:  rkt /etc/krb5.keytab
	ktutil:  l
	slot KVNO Principal
	---- ---- 		 
---------------------------------------------------------------------
	1    4 host/nfsv4etch.engr.uconn.edu at AD.ENGR.UCONN.EDU

Does that look like it's generated properly?

Rohit

Russ Allbery wrote:
> Rohit Kumar Mehta <rohitm at engr.uconn.edu> writes:
> 
> 
>>I tried that command and it seems to work:
> 
> 
>>nfsv4etch:~# kinit -S host/nfsv4etch.engr.uconn.edu rohitm at AD.ENGR.UCONN.EDU
>>Password for rohitm at AD.ENGR.UCONN.EDU:
>>nfsv4etch:~# klist
>>Ticket cache: FILE:/tmp/krb5cc_0
>>Default principal: rohitm at AD.ENGR.UCONN.EDU
> 
> 
>>Valid starting     Expires            Service principal
>>10/10/06 17:19:07  10/11/06 03:19:12
>>host/nfsv4etch.engr.uconn.edu at AD.ENGR.UCONN.EDU
>>        renew until 10/11/06 17:19:07
> 
> 
> 
>>Kerberos 4 ticket cache: /tmp/tkt0
>>klist: You have no tickets cached
> 
> 
> Hm, it's very strange that telnet wasn't able to obtain the same
> credential itself when it tried.
> 
> 
>>However even with the host credentials, I can't get in:
> 
> 
>>nfsv4etch:~# telnet -k AD.ENGR.UCONN.EDU -l rohitm nfsv4etch.engr.uconn.edu
>>Trying 192.168.1.137...
>>Connected to nfsv4etch.engr.uconn.edu (192.168.1.137).
>>Escape character is '^]'.
>>telnetd: Authorization failed.
>>Connection closed by foreign host.
>>nfsv4etch:~# ssh rohitm at nfsv4etch.engr.uconn.edu
>>rohitm at nfsv4etch.engr.uconn.edu's password:
>>Permission denied, please try again.
>>rohitm at nfsv4etch.engr.uconn.edu's password:
>>Permission denied, please try again.
>>rohitm at nfsv4etch.engr.uconn.edu's password:
>>Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
> 
> 
> I think for ssh you're going to need to run the server with sshd -ddd and
> see what it says about the GSSAPI exchange to try to figure out why things
> are going wrong... although if the client isn't even obtaining a host
> principal, I'm not sure what would be going wrong.
>