11:25 p.m.
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.