Hey All,
The primary master I have has the kadmin principal for it:
kadmin/ipa03.mws.mds.xyz@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?
Thx for taking a look.
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@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.
- Should the slave installer have created the slave kadmin/... principal?
- 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?
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.
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@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.
- 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@MWS.MDS.XYZ for ldap/idmipa03.mws.mds.xyz@MWS.MDS.XYZ Aug 21 22:36:14 idmipa03.mws.mds.xyz krb5kdc[5618](info): ... CONSTRAINED-DELEGATION s4u-client=cmadmin-530029b6@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@MWS.MDS.XYZ for kadmin/idmipa04.mws.mds.xyz@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@MWS.MDS.XYZ for kadmin/admin@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@MWS.MDS.XYZ for kadmin/admin@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@MWS.MDS.XYZ for krbtgt/MWS.MDS.XYZ@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@MWS.MDS.XYZ for krbtgt/MWS.MDS.XYZ@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@MWS.MDS.XYZ for HTTP/idmipa03.mws.mds.xyz@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@MWS.MDS.XYZ for ldap/idmipa03.mws.mds.xyz@MWS.MDS.XYZ Aug 21 22:38:21 idmipa03.mws.mds.xyz krb5kdc[5619](info): ... CONSTRAINED-DELEGATION s4u-client=cmadmin-530029b6@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@MWS.MDS.XYZ for ldap/idmipa03.mws.mds.xyz@MWS.MDS.XYZ Aug 21 22:38:21 idmipa03.mws.mds.xyz krb5kdc[5619](info): ... CONSTRAINED-DELEGATION s4u-client=cmadmin-530029b6@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@MWS.MDS.XYZ -r MWS.MDS.XYZ -q 'modprinc -maxrenewlife "432000 sec" hue/cm-r01en02.mws.mds.xyz@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@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.
On pe, 23 elo 2019, TomK wrote:
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@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.
- 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@MWS.MDS.XYZ for ldap/idmipa03.mws.mds.xyz@MWS.MDS.XYZ Aug 21 22:36:14 idmipa03.mws.mds.xyz krb5kdc[5618](info): ... CONSTRAINED-DELEGATION s4u-client=cmadmin-530029b6@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@MWS.MDS.XYZ for kadmin/idmipa04.mws.mds.xyz@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@MWS.MDS.XYZ for kadmin/admin@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@MWS.MDS.XYZ for kadmin/admin@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@MWS.MDS.XYZ for krbtgt/MWS.MDS.XYZ@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@MWS.MDS.XYZ for krbtgt/MWS.MDS.XYZ@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@MWS.MDS.XYZ for HTTP/idmipa03.mws.mds.xyz@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@MWS.MDS.XYZ for ldap/idmipa03.mws.mds.xyz@MWS.MDS.XYZ Aug 21 22:38:21 idmipa03.mws.mds.xyz krb5kdc[5619](info): ... CONSTRAINED-DELEGATION s4u-client=cmadmin-530029b6@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@MWS.MDS.XYZ for ldap/idmipa03.mws.mds.xyz@MWS.MDS.XYZ Aug 21 22:38:21 idmipa03.mws.mds.xyz krb5kdc[5619](info): ... CONSTRAINED-DELEGATION s4u-client=cmadmin-530029b6@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@MWS.MDS.XYZ -r MWS.MDS.XYZ -q 'modprinc -maxrenewlife "432000 sec" hue/cm-r01en02.mws.mds.xyz@MWS.MDS.XYZ' kadmin: Communication failure with server while initializing kadmin interface
You can set this value through IPA CLI by use of krbtpolicy commands. See 'ipa help krbtpolicy'.
(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@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.
freeipa-users@lists.fedorahosted.org