Hey All, The primary master I have has the kadmin principal for it: kadmin/ipa03.mws.mds.xyz(a)MWS.MDS.XYZ The slave (idmipa04) doesn't have a corresponding kadmin/... principal entry. Can't find these principals in the UI.

1) Should the slave installer have created the slave kadmin/... principal? 2) If I wanted to create one, should the pass be any random string or something specific? 3) Are there specific IPA commands to create the kadmin/... principals with?

On 8/22/2019 2:46 AM, Alexander Bokovoy via FreeIPA-users wrote: >On ke, 21 elo 2019, TomK via FreeIPA-users wrote: >>Hey All, >> >>The primary master I have has the kadmin principal for it: >> >>kadmin/ipa03.mws.mds.xyz(a)MWS.MDS.XYZ >> >>The slave (idmipa04) doesn't have a corresponding kadmin/... >>principal entry.  Can't find these principals in the UI. > >It is only created on the first master because it is part of the process >that is run within 'kdb5_util create'. This process is not run on >replica deployment because we already have all the needed master keys >and the database layout. > >We don't really use KADMIN protocol over network in FreeIPA, so this >principal is rather unutilized. > >>1) Should the slave installer have created the slave kadmin/... >>principal? >>2) If I wanted to create one, should the pass be any random string >>or something specific? >>3) Are there specific IPA commands to create the kadmin/... >>principals with? > >What do you need it for? What operations do you miss from FreeIPA >CLI/API? I'm getting the following on the IPA KDC that I'm tying to a VIP. The VIP is handled by HAproxy and is meant to provide redundancy in case of failure in a single IPA node without having to reconfigure servers for a new IP: [root@idmipa03 ~]# tail -f /var/log/krb5kdc.log Aug 21 22:36:14 idmipa03.mws.mds.xyz krb5kdc[5618](info): closing down fd 11 Aug 21 22:36:14 idmipa03.mws.mds.xyz krb5kdc[5618](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 192.168.0.154: ISSUE: authtime 1566441372, etypes {rep=18 tkt=18 ses=18}, HTTP/idmipa03.mws.mds.xyz(a)MWS.MDS.XYZ for ldap/idmipa03.mws.mds.xyz(a)MWS.MDS.XYZ Aug 21 22:36:14 idmipa03.mws.mds.xyz krb5kdc[5618](info): ... CONSTRAINED-DELEGATION s4u-client=cmadmin-530029b6(a)MWS.MDS.XYZ Aug 21 22:36:14 idmipa03.mws.mds.xyz krb5kdc[5618](info): closing down fd 11 Aug 21 22:36:16 idmipa03.mws.mds.xyz krb5kdc[5619](info): AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 192.168.0.134: SERVER_NOT_FOUND: cmadmin-530029b6(a)MWS.MDS.XYZ for kadmin/idmipa04.mws.mds.xyz(a)MWS.MDS.XYZ, Server not found in Kerberos database Aug 21 22:36:16 idmipa03.mws.mds.xyz krb5kdc[5619](info): closing down fd 11 Aug 21 22:36:16 idmipa03.mws.mds.xyz krb5kdc[5616](info): AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 192.168.0.134: NEEDED_PREAUTH: cmadmin-530029b6(a)MWS.MDS.XYZ for kadmin/admin(a)MWS.MDS.XYZ, Additional pre-authentication required Aug 21 22:36:16 idmipa03.mws.mds.xyz krb5kdc[5616](info): closing down fd 11 Aug 21 22:36:16 idmipa03.mws.mds.xyz krb5kdc[5619](info): AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 192.168.0.134: ISSUE: authtime 1566441376, etypes {rep=18 tkt=18 ses=18}, cmadmin-530029b6(a)MWS.MDS.XYZ for kadmin/admin(a)MWS.MDS.XYZ Aug 21 22:36:16 idmipa03.mws.mds.xyz krb5kdc[5619](info): closing down fd 11 Aug 21 22:38:20 idmipa03.mws.mds.xyz krb5kdc[5617](info): AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 192.168.0.134: NEEDED_PREAUTH: cmadmin-530029b6(a)MWS.MDS.XYZ for krbtgt/MWS.MDS.XYZ(a)MWS.MDS.XYZ, Additional pre-authentication required Aug 21 22:38:20 idmipa03.mws.mds.xyz krb5kdc[5617](info): closing down fd 11 Aug 21 22:38:20 idmipa03.mws.mds.xyz krb5kdc[5618](info): AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 192.168.0.134: ISSUE: authtime 1566441500, etypes {rep=18 tkt=18 ses=18}, cmadmin-530029b6(a)MWS.MDS.XYZ for krbtgt/MWS.MDS.XYZ(a)MWS.MDS.XYZ Aug 21 22:38:20 idmipa03.mws.mds.xyz krb5kdc[5618](info): closing down fd 11 Aug 21 22:38:21 idmipa03.mws.mds.xyz krb5kdc[5619](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 192.168.0.134: ISSUE: authtime 1566441500, etypes {rep=18 tkt=18 ses=18}, cmadmin-530029b6(a)MWS.MDS.XYZ for HTTP/idmipa03.mws.mds.xyz(a)MWS.MDS.XYZ Aug 21 22:38:21 idmipa03.mws.mds.xyz krb5kdc[5619](info): closing down fd 11 Aug 21 22:38:21 idmipa03.mws.mds.xyz krb5kdc[5619](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 192.168.0.154: ISSUE: authtime 1566441500, etypes {rep=18 tkt=18 ses=18}, HTTP/idmipa03.mws.mds.xyz(a)MWS.MDS.XYZ for ldap/idmipa03.mws.mds.xyz(a)MWS.MDS.XYZ Aug 21 22:38:21 idmipa03.mws.mds.xyz krb5kdc[5619](info): ... CONSTRAINED-DELEGATION s4u-client=cmadmin-530029b6(a)MWS.MDS.XYZ Aug 21 22:38:21 idmipa03.mws.mds.xyz krb5kdc[5619](info): closing down fd 11 Aug 21 22:38:21 idmipa03.mws.mds.xyz krb5kdc[5619](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 192.168.0.154: ISSUE: authtime 1566441500, etypes {rep=18 tkt=18 ses=18}, HTTP/idmipa03.mws.mds.xyz(a)MWS.MDS.XYZ for ldap/idmipa03.mws.mds.xyz(a)MWS.MDS.XYZ Aug 21 22:38:21 idmipa03.mws.mds.xyz krb5kdc[5619](info): ... CONSTRAINED-DELEGATION s4u-client=cmadmin-530029b6(a)MWS.MDS.XYZ Aug 21 22:38:21 idmipa03.mws.mds.xyz krb5kdc[5619](info): closing down fd 11 The message that appears in the client is: + kadmin -k -t /tmp/cmf9215806201763456498.keytab -p cmadmin-530029b6(a)MWS.MDS.XYZ -r MWS.MDS.XYZ -q 'modprinc -maxrenewlife "432000 sec" hue/cm-r01en02.mws.mds.xyz(a)MWS.MDS.XYZ' kadmin: Communication failure with server while initializing kadmin interface

(Sorry, I don't have better timestamps off the client) I haven't fully investigated this so some assumptions are present however, if my interpretation is on target, the command fails because the VIP invariably points to the secondary node where the kadmin/.... principal doesn't exist (Hence the message.) I'm simply running a keepalived between the nodes, (No HAproxy). Since services bind on any interface on either host, I don't really need anything like HAproxy for now. Still, on multiple attempts to use the KDC, the client will eventually hit the secondary node ( idmipa04 ) and therefore apparently hit that snag (My interpretation of what I see at least). The credentials I give to this application include admin(a)MWS.MDS.XYZ . > >KADMIN protocol isn't really useful in FreeIPA case. KADMIN doesn't have >proper access controls since all operations there are still done under >super-privileged identity when the request comes to KDB layer rather >than the original requester identity. It is, thus, not possible to >re-bind to LDAP from KDB driver as the original requester to make sure >LDAP server enforces proper access controls per each entry. > >kadmin daemon has own static definition, kadm5.acl, for access control. >However, it is useless for the dynamic multi-master environments like >FreeIPA. > -- Thx, TK.