Closed crispd closed 9 months ago
Thanks, Jim!
Kerberos accounts in poor state. Getting errors when attempting to get ticket for my accounts, instead of the expected password prompt. (things like user & realm are sanitized throughout this ticket)
C:\Program Files (x86)\MIT\Kerberos\bin> kinit <my_username>@<realm_1>
kinit(v5): Looping detected inside krb5_get_in_tkt while getting initial credentials
C:\Program Files (x86)\MIT\Kerberos\bin> kinit <my_username>@<realm_2>
kinit(v5): KDC has no support for encryption type while getting initial credentials
What is expected instead of these errors?
Password for <username>@<realm>:
Contact the help desk to try and get 'things reset'
C:\Program Files (x86)\MIT\Kerberos\bin
C:\temp\StartXApp.log
klist
command (no args) located in (1) above; it should show something for Ticket cache:
and Default principal
. Also note the command plink <user>@<gateway_host>
.I will contact the 'help desk' and see what they may be able to reset, try things again, and update this issue as I find out more.
Looking at your kerberos principal, your kerberos password has not been changed since July 2008. We'll reset your kerberos password. Walk into the help desk on the ground floor of Wilson Hall and we'll give you the new password (which you yourself should change once you get the chance). Note that once you login, it will take 20-30min before this authentication gets recognized by the various services throughout the lab. Let us know if you run into more difficulties.
As soon as I opened the Network Identification Manager, I was provided a simple password text entry prompt, and after entering the one they gave me (post reset), I seemed to be able to get a krb5 ticket (realm = FNAL.GOV) I will try to access the controls network with this ticket later today
This situation is probably not that all that common. It's been some 15 years since I've last worked here, and there's been a number of things that don't appear to cope with this time gap very well. In another example, Elvin had to clarify to whoever manages the eshopper licenses that I am no longer a seasonal employee.
No idea why it would work sometimes and not others... nor why certificate management with this kind of scope isn't robust enough to ensure that new employees are given valid certificates to begin with. For now, I hope this issue thread is enough to help whomever may encounter a related problem.
I'm going to close this issue.
Controls Network Authentication Issues (WIN10)
Behavior
Validity of identity <my_username>@<realm> couldn't be determined
(can't even make an attempt)Looping detected inside krb5_get_in_tkt
Context
Controls Customizations Information
version (v2.3.27)To Reproduce
Affected System(s)