Fix iprop with fallback

kpropd produces a client principal name with
krb5_sname_to_principal(), then converts it to a string to pass as the
client principal to kadm5_init_with_skey().  This conversion loses the
name type, so no canonicalization is performed by libkadm5.

Commit dcb79089276624d7ddf44e08d35bd6d7d7e557d2 addresses this problem
for kadmin -k by looking for the referral realm, but kpropd sets the
realm in the krb5_sname_to_principal() result.  Add an additional
check for a two-component principal with kiprop as the first
component.

(cherry picked from commit cd61bdcd6339b10e6cf3feb9f6cb369213e8d7fc)

ticket: 9056
version_fixed: 1.20

1 files changed, 6 insertions, 2 deletions

diff --git a/src/lib/kadm5/clnt/client_init.c b/src/lib/kadm5/clnt/client_init.c
index 75614bb..d4fd5e1 100644
--- a/src/lib/kadm5/clnt/client_init.c
+++ b/src/lib/kadm5/clnt/client_init.c
@@ -239,12 +239,16 @@ init_any(krb5_context context, char *client_name, enum init_type init_type,
     /*
      * Parse the client name.  If it has an empty realm, it is almost certainly
      * a host-based principal using DNS fallback processing or the referral
-     * realm, so give it the appropriate name type for canonicalization.
+     * realm, so give it the appropriate name type for canonicalization.  Also
+     * check for iprop client principals as kpropd sets the realm on the
+     * sn2princ result.
      */
     code = krb5_parse_name(handle->context, client_name, &client);
     if (code)
         goto cleanup;
-    if (init_type == INIT_SKEY && client->realm.length == 0)
+    if ((init_type == INIT_SKEY && client->realm.length == 0) ||
+        (client->length == 2 &&
+         data_eq_string(client->data[0], KIPROP_SVC_NAME)))
         client->type = KRB5_NT_SRV_HST;
 
     /*