The joys of ActiveDirectory and Kerberized SSH

[Tom Yu]

"Foley, Joe" <jfoley at irobot.com> writes:

> At some point the problem appeared to be the AD server giving back more
> than one answer to a query on a principal.  This was very hard to detect
> because different clients failed in very different ways.  Doing a kinit
> with the keytab for the principal "hq-svn/host" would fail, but

Are you sure this isn't "host/hq-svn" or "host/" followed by the
fully-qualified domain name of "hq-svn"?

> "hq-svn%" worked.

I would expect this to be something like "HQ-SVN$" to correspond with
the NetBIOS name of the host.  I have not seen the percent sign in
these contexts.

I would like to know more details about the "AD server giving back
more than one answer" situation.  How did you determine this, and what
different answers was it giving back?

> Once we had figured that out, the next step was to try again. Once again
> there was an error. In this case the error was "No such file or
> directory."  with not hint as to what file or directory the thing might
> have been looking for.
>
> In fact, using ltrace didn't help this. I have no idea where it actually
> looks up that file name.
>
> It turns out that it was looking for keytab file. The only reason I
> realized that was because I started trying to think of the mechanism,
> and how it all worked.

Ubuntu 8.04 uses krb5-1.6.3.  The recent krb5-1.7 release has many
enhancements, which include providing extended error information
strings in more places, including in the situation you describe.
There is also a patch queued for the upcoming krb5-1.6.4 maintenance
release to add that extended error reporting information.

> To summarize, the error messages for problems like this *must* say what
> exactly is wrong, what resource is wrong or missing, preferably with as
> much context as possible.   It's not reasonable to hope that ltrace or
> strace will give you enough information.  It is also not reasonable for
> the sys-admin to be expected to run through the entire installation
> procedure again.  Sys-admin's are harried, and need shortcuts and
> complete error messages.

Thanks for letting us know.  We have been working on improving our
error reporting for some time now, mostly by adding extended error
information to places where the existing fixed strings provide
insufficient information.  Having additional reports like yours can
help us with that effort.