Hi Greg,
Yup - Running 1.10+dfsg~beta1 - the default on my Ubuntu systems.
In retrospect I should have not just followed the pkinit setup
instructions blindly, running openssl commands without giving them some
thought. Without specifying days it will default to 30 days, and combined
with the
Hi All,
Thanks again for the help getting anonymous kinit running! We have been running
in production for over a month and things are going… well. Until today.
This week a new error occurred on the KDC side:
Oct 11 21:25:57 sso krb5kdc[10394](info): AS_REQ (4 etypes {18 17 16 23})
10.0.1.13:
I should add, this error occurs when running kinit -n.
I can still kinit as a user on an already setup host and get a TGT.
- James
James Croall | Senior Product Manager
Coverity | 185 Berry Street | Suite 6500, Lobby 3 | San Francisco, CA
94107
Office: 415.694.5354 | Mobile: 202.246.6613 |
Poking around with strace, and running krb5kdc with debug enabled, I see
no smoking gun that there is a lack memory problem.
Searching the kerberos mailing list and other forums I see similar
reports, but no explanation of cause or possible solutions. A bit lost
here. It was working great for a
There are certainly some places in the pkinit code where the return value
is initialized to ENOMEM which can get returned for failures other than
memory allocation. It's hard to venture a guess as to which one(s) you
are running into, though.
Do you have a sense for how reproducible the
Since discovering the symptoms it is reproducible every time - from
systems that are able to kinit normally, it happens when I kinit -n. From
the new systems that are trying to bootstrap, it happens when I kinit -n.
Nothing has (to my knowledge) changed on these hosts. Indeed the KDC and
normal
Some sleuthing and adding DEBUG to pkinit.so reveals:
pkinit_find_realm_context: returning context at 0x20108c0 for realm
'TRIAL.COVERITY.COM'
pkinit_return_padata: entered!
KDC picked etype = 18
received DH key delivery AS REQ
building certificate chain
cert = /C=US/ST=CA/L=San
On 10/11/2013 11:54 PM, James Croall wrote:
AHA! I must have accidentally set the certificate to expire in a month
rather than a year. Approximate times line up. Reasonable user error. Very
poor error reporting though!
I believe I improved the error reporting for this case in 1.11:
