On Wed, 18 Feb 2015, Giuseppe Mazza wrote: > A collegue of mine lets me know that it could be a different issue. > Here is his root principal: > kadmin.local: get_principal collegue/root > Principal: collegue/r...@doc.ic.ac.uk > Expiration date: [never] > Last password change: Thu Feb 24 11:40:22 GMT 2011 > Password expiration date: [none] > Maximum ticket life: 0 days 10:00:00 > Maximum renewable life: 7 days 00:00:00 > Last modified: Wed Feb 18 11:26:15 GMT 2015 (colleg/ad...@doc.ic.ac.uk) > Last successful authentication: Wed Feb 18 11:26:22 GMT 2015 > Last failed authentication: [never] > Failed password attempts: 0 > Number of keys: 5 > Key: vno 2, des3-cbc-sha1, no salt > Key: vno 2, des-cbc-crc, no salt > Key: vno 2, des-cbc-crc, Version 4 > Key: vno 2, des-cbc-crc, AFS version 3 > Key: vno 2, arcfour-hmac, no salt > MKey: vno 1 > Attributes: REQUIRES_PRE_AUTH > Policy: default > > (Please note the user has got a DES root principals) > > > kadmin.local: get_principal host/client.doc.ic.ac.uk > Principal: host/client.doc.ic.ac...@doc.ic.ac.uk > Expiration date: [never] > Last password change: Tue Feb 17 16:06:24 GMT 2015 > Password expiration date: [none] > Maximum ticket life: 0 days 10:00:00 > Maximum renewable life: 7 days 00:00:00 > Last modified: Wed Feb 18 11:25:40 GMT 2015 (colleg/ad...@doc.ic.ac.uk) > Last successful authentication: [never] > Last failed authentication: [never] > Failed password attempts: 0 > Number of keys: 1 > Key: vno 2, aes256-cts-hmac-sha1-96, no salt > MKey: vno 1 > Attributes: REQUIRES_PRE_AUTH > Policy: machine > > > If the user does not have "Attributes: REQUIRES_PRE_AUTH" > and the machine does > ksu fails with the error message that I have posted. > > If the machine does not have "Attributes: REQUIRES_PRE_AUTH" > ksu works regardless the user's setting.
That would explain the behavior you are seeing, yes (and there is no connection to the version of the software). For unfortunate historical reasons, the REQUIRES_PRE_AUTH flag has two distinct meanings when set on a principal; one meaning applies when the principal is acting as a client, and the other when it is acting as a service. When the principal is acting as a client, this flag requires that the principal pre-authenticate itself to the KDC before a ticket is issued (e.g., via encrypted timestamp). When the flag is set on a principal acting as a server, the KDC will not issue a service ticket for that service principal unless the client's initial authentication was preauthenticated. So, having the flag set on a server but not the client will cause the client to fail to get a ticket. For this reason, unless the flag can be set on all principals in the realm all at once (such as by setting it in the default_principal_flags before realm creation), it is best to only set the flag on user principals, and not on server principals. -Ben ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
