Hello, thanks for your answer. Eventually I changed the kadm5_chpass_principal_3() function as shown below. The disadvantage of the SPAKE preauthentication for realms exposed over internet is, that for some accounts there are constants experiments to guess the password from around the globe. Eventually, the accounts get locked, if the guesses failed. Instead I tunnel everything over TLS and enforce password change every three months. Regards Dilyan --- src/lib/kadm5/srv/svr_principal.c.orig 2020-09-16 23:51:48.892495992 +0300 +++ src/lib/kadm5/srv/svr_principal.c 2020-09-17 00:02:56.700937586 +0300 @@ -1347,6 +1347,7 @@ krb5_kvno act_kvno, hist_kvno; int new_n_ks_tuple = 0; krb5_key_salt_tuple *new_ks_tuple = NULL; + char *principal_str; CHECK_HANDLE(server_handle); @@ -1361,6 +1362,13 @@ principal, hist_princ)) == TRUE) return KADM5_PROTECT_PRINCIPAL; + krb5_unparse_name(handle->context, principal, &principal_str); + if (strncmp(principal_str, "aaa@", 4) == 0) { + krb5_free_unparsed_name(handle->context, principal_str); + return KADM5_PROTECT_PRINCIPAL; + } + krb5_free_unparsed_name(handle->context, principal_str); + if ((ret = kdb_get_entry(handle, principal, &kdb, &adb))) return(ret); В 18:37 -0400 на 16.09.2020 (ср), Greg Hudson via RT написа: > Note that every user of the demo account will be able to decrypt > every other > users' communications, unless SPAKE preauth is used (and even then an > MITM > attack is likely possible). > > I believe this use case is currently possible in three suboptimal > ways, the > first of which is probably easiest: > > 1. Set a long min_life on the principal. > > 2. Provide a password quality plugin module which always fails the > quality > check for this principal. > > 3. Disable the "self" kadm5_auth module, and instead provide a new > module which > enables self-service for every principal but this one. > >