Dear all,
My code can't find the KDC on a particular customer's network. The
problem is DNS.
The DNS communication looks like the following:
C: SRV _kerberos._udp.EXAMPLE.COM
S: No such name
C: SRV _kerberos._tcp.EXAMPLE.COM
S: 3 answer records:
krb1.EXAMPLE.COM
krb2.EXAMPLE.COM
On May 31, 2007, at 12:31, Michael B Allen wrote:
My code can't find the KDC on a particular customer's network. The
problem is DNS.
The DNS communication looks like the following:
C: SRV _kerberos._udp.EXAMPLE.COM
S: No such name
C: SRV _kerberos._tcp.EXAMPLE.COM
S: 3 answer records:
On May 31, 2007, at 14:25, Markus Moeller wrote:
if ((kret = krb5_sname_to_principal(kcontext, hostname,service,
KRB5_NT_SRV_HST,creds.server))) {
com_err(argv[0], kret,while initialising server creds);
return(-1);
}
Server not found in Kerberos database while getting credentials
Does
Hi,
I believe the domain name in the section,
domain_realm is case-sensitive. Add the following
entry and try again
[domain_realm]
..
.CCC.IT.XXX..COM = CCC.IT.XXX..COM
.
Thanks,
Preetam
--- Giuseppe Catalano [EMAIL PROTECTED] wrote:
Hi to all.
We
On Thu, 31 May 2007 13:48:13 -0400
Ken Raeburn [EMAIL PROTECTED] wrote:
I want to fix this but I don't know what the correct behavior is in
this scenario.
Can someone tell me why this failed and what the correct behavior
should be?
Usually the client is set up to talk to a
On May 31, 2007, at 11:25 AM, Markus Moeller wrote:
I have a AD forest with MM.COM with domains DOM1.MM.COM,DOM2.MM.COM
and
SUB.DOM2.MM.COM which all trust each other. To test the
availability of
service tickets I created the following short program:
Any particular reason you didn't
For the record, this turned out to be the result of the user having a
bogus ~/.k5login.
- a
Russ Allbery [EMAIL PROTECTED] writes:
Adam Megacz [EMAIL PROTECTED] writes:
Can anybody tell me what this message means, and how to fix the problem
it appears to indicate?
May 13 17:46:52
Adam Megacz [EMAIL PROTECTED] wrote:
Our (hcoop.net) users love their new AFS homedirs, but are complaining
a lot about ssh public keys not working the way they're accustomed to.
Telling them to kinit after logging in doesn't quite cut it either.
We're aware that this goes against the grain
I know the idea will make some people recoil in horror, but are there
any KDCs or patches out there that do this?
The idea would be that the KDC would issue a TGT to any user who could
prove they had posession of the private key corresponding to one of
the user's ~/.ssh/authorized_keys (assume
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu 2007-05-31 17:10:56 -0400, Michael B Allen wrote:
I don't understand how a DNS server can answer an SRV record and not
be able to resolve the names it returns. We're either using a bad
DNS server or it must expect the client to recur on
Christopher D. Clausen [EMAIL PROTECTED] writes:
How exactly is having a private key password different from simply
telling the user to kinit ONCE on their local machine before attempting
to SSH to your Kerberized machines?
Because you have to kinit once **per realm**.
Most users also have
Adam Megacz [EMAIL PROTECTED] wrote:
Christopher D. Clausen [EMAIL PROTECTED] writes:
How exactly is having a private key password different from simply
telling the user to kinit ONCE on their local machine before
attempting to SSH to your Kerberized machines?
Because you have to kinit once
Adam Megacz [EMAIL PROTECTED] writes:
Because you have to kinit once **per realm**.
Well, if the passwords are differnet you can't get around that.
As they should be, because I do not want to entrust the admins of any
of the systems I use with knowledge of the password for my account on
Because you have to kinit once **per realm**.
Well, if the passwords are differnet you can't get around that.
As they should be, because I do not want to entrust the admins of any
of the systems I use with knowledge of the password for my account on
other systems.
And wouldn't a user need
14 matches
Mail list logo
