Scotty,
From your entry in the kdc.log it looks to me like you do have a valid
admin principal and your password is correct, so I am guessing your
permissions for that principal are wrong.
Look in your /krb5/var/krb5kdc/kadm5.acl file on the kerberos master, to
see if the principal you are u
I am not sure how compatible the heimdahl and mit kerberos dump/load
programs are. I suspect they can be made to work.
In a nutshell, try the following.
1. Dump the kerberos database on your MIT master to a file, you do this
with dump subcommand of kdb5_util.
2. Build your shiny new Heimdahl kd
Kevin Coffman is right, you should only start the kadmind server on the
admin_server which is the master server. Your startup script is starting
kadmind on the slave, ... or you are manually trying to start it on the
slave.
If it is the startup script that is starting kadmind, then I suggest y
Celia Clark wrote:
> [safeTgram (optim1) receive status: NOT encrypted, NOT signed.]
>
>
> Hi,
>
> I am having problems with using kinit, with keytab and username/password.
>
> When issuing the kinit command I get the following error:
> kinit: Cannot contact any KDC for requested realm while gettin
Hi Arnoud,
Use of DNS is controlled via krb5.conf, with three directives. I looked
at the MIT man page for krb5.conf. Note that this is different to the
man page from vendors such as Sun, you should be looking at the file
/krb5/man/man5/krb5.conf.5. In any case these directives are described
I had similar type problems building with Solaris 2.5.1 (sigh!)
I took a different tack with the "uint" problem:
1. I patched krb5-1.4.3/src/lib/gssapi/krb5/gssapi_krb5.hin so it did
not use inttypes.h, and replaced it with the one typedef it seemed to
really need:
typedef u_longlon
mit.edu/kerberos/www/krb5-1.4/krb5-1.4.3/doc/krb5-admin/Clock-Skew.html
for more details.
Jeremy Thomas Hunt wrote:
> [safeTgram (optim1) receive status: NOT encrypted, NOT signed.]
>
>
> David A. Resler wrote:
>
>> Over the past couple of weeks we have been seeing a
David A. Resler wrote:
> Over the past couple of weeks we have been seeing a handful of users
> not be able to get a Kerberos ticket because the date on their
> computer has been set to the year 2142.
>
> Once the date is corrected, they can get tickets without any further
> problems.
>
> So far
