hdb: Do not apply new service key delay to clients
The new [hdb] new_service_key_delay parameter should not apply to principal entries when used as clients. Otherwise new passwords would not take effect immediately, and that would be very confusing.
This commit is contained in:
@@ -1161,10 +1161,11 @@ fix_keys(krb5_context context,
|
||||
size_t i;
|
||||
|
||||
/*
|
||||
* If we want a specific kvno, or if we're not decrypting the keys, or if
|
||||
* there's no new-key delay, then we're out.
|
||||
* If we want a specific kvno, or if the caller doesn't want new keys
|
||||
* delayed, or if there's no new-key delay configured, or we're not
|
||||
* fetching for use as a service principal, then we're out.
|
||||
*/
|
||||
if (!(flags & HDB_F_DECRYPT) || kvno || h->entry.flags.virtual ||
|
||||
if (!(flags & HDB_F_DELAY_NEW_KEYS) || kvno || h->entry.flags.virtual ||
|
||||
h->entry.flags.virtual_keys || db->new_service_key_delay <= 0)
|
||||
return 0;
|
||||
|
||||
|
@@ -66,6 +66,7 @@ enum hdb_lockop{ HDB_RLOCK, HDB_WLOCK };
|
||||
#define HDB_F_FOR_AS_REQ 4096 /* fetch is for a AS REQ */
|
||||
#define HDB_F_FOR_TGS_REQ 8192 /* fetch is for a TGS REQ */
|
||||
#define HDB_F_PRECHECK 16384 /* check that the operation would succeed */
|
||||
#define HDB_F_DELAY_NEW_KEYS 32768 /* apply [hdb] new_service_key_delay */
|
||||
|
||||
/* hdb_capability_flags */
|
||||
#define HDB_CAP_F_HANDLE_ENTERPRISE_PRINCIPAL 1
|
||||
|
Reference in New Issue
Block a user