On Mon, Oct 11, 2010 at 02:12:24PM -0400, Greg Hudson wrote:
No, it's not the domain heuristic, which is off by default anyway; it's
the next step after the domain heuristic, which is to use the parent
domain (uppercased) without trying to decide whether it's a real realm
or not.
So you'd
I'm using the pre-packaged MIT Kerberos 1.6.1 on CentOS 5.5 to set up a test
environment, where I am lazy, and simply set the various passwords to match
the usernames (I have no need for real security here -- this is just a
dataless test environment).
I do this, so that I can debug problems by
Phillip Moore w.phillip.mo...@gmail.com writes:
When setting up the environment, I create the principals using:
add_principal -pw $principal $princi...@$realm
Then I extract the keytab file for use in the test suite using:
ktadd -k /path/to/$principal.keytab $principal
I've
On Oct 12, 2010, at 12:06, Phillip Moore wrote:
Then I extract the keytab file for use in the test suite using:
ktadd -k /path/to/$principal.keytab $principal
I've discovered that as soon as I run ktadd, then I can no longer manually
authenticate as that principal anymore.
Yes, that's
On Tue, 2010-10-12 at 04:36 -0400, Brian Candler wrote:
On Mon, Oct 11, 2010 at 02:12:24PM -0400, Greg Hudson wrote:
No, it's not the domain heuristic, which is off by default anyway; it's
the next step after the domain heuristic, which is to use the parent
domain (uppercased) without
Man, I'm glad I'm doing this in a dataless environment that I can toss out
and rebuild.
I hope the following is a known and fixed problem. The kadmin and
kadmin.local behavior in this case is incredibly bad.
Here's how I *was* doing this:
echo ktadd -k /home/root/keytabs/$user.keytab $user |
Phillip Moore w.phillip.mo...@gmail.com says:
...
it handles it is disturbing:
[r...@rpcore tmp]# echo ktadd -norandkey -k /var/tmp/foo.keytab efsops |
kadmin.local
Authenticating as principal root/ad...@test.efs with password.
kadmin.local: kadmin.local: Principal -norandkey does not
