Eric Ashley via FreeIPA-users wrote:
On Friday, July 8th, 2022 at 1:02 PM, Rob Crittenden
<rcritten(a)redhat.com> wrote:
>
> Not sure what you mean by "wire traffic". It's a vault so perhaps you
> stored some keys there. IPA already encrypts all its own internal traffic.
When I first installed FreeIPA it did not yet default to encrypted traffic for all
accesses.
Can you expand on this? Literally all the KRA does is store secrets. It
does not protect traffic unless you manually use those secrets to do so.
>
>> I've checked the list archive and can't see any instances that are
>> related to the issues ipa-healthcheck reports. ipa-healthcheck reports
>> the following:
>>
>> [
>> {
>> "source": "ipahealthcheck.ipa.idns",
>> "check": "IPADNSSystemRecordsCheck",
>> "result": "WARNING",
>> "uuid": "432017b9-ef12-44a5-8843-35fd6424d85f",
>> "when": "20220708144958Z",
>> "duration": "0.031444",
>> "kw": {
>> "msg": "Expected URI record missing",
>> "key":
>> "_kerberos.ipa.example.com.:krb5srv:m:tcp:ipaserv.ipa.example.com."
>> }
>> },
>> {
>> "source": "ipahealthcheck.ipa.idns",
>> "check": "IPADNSSystemRecordsCheck",
>> "result": "WARNING",
>> "uuid": "498649c8-1460-4f34-807b-1b06c08f3aec",
>> "when": "20220708144958Z",
>> "duration": "0.031469",
>> "kw": {
>> "msg": "Expected URI record missing",
>> "key":
>> "_kerberos.ipa.example.com.:krb5srv:m:udp:ipaserv.ipa.example.com."
>> }
>> },
>> {
>> "source": "ipahealthcheck.ipa.idns",
>> "check": "IPADNSSystemRecordsCheck",
>> "result": "WARNING",
>> "uuid": "3a6c7f80-3ce9-4ba0-b821-d731eb6929a3",
>> "when": "20220708144958Z",
>> "duration": "0.033407",
>> "kw": {
>> "msg": "Expected URI record missing",
>> "key":
>> "_kpasswd.ipa.example.com.:krb5srv:m:tcp:ipaserv.ipa.example.com."
>> }
>> },
>
>
> URI records are not required but your installation supports them. If you
> want to utilize them you can add the missing ones. Or you can ignore these.
>
These look like it's looking for service records, which all exist. The first element
of the key looks like it wants a service record without the protocol. I don't know
what one of those is supposed to look like. I have _kerberos TXT record for the realm and
_kerberos._tcp and _kerberos._udp service records. What exactly is it looking for in
addition?
There are URI records like:
kpasswd.example.test. 3600 IN URI 0 100 "krb5srv:m:tcp:ipa.example.test."
>> {
>>
>> "source": "ipahealthcheck.ipa.proxy",
>> "check": "IPAProxySecretCheck",
>> "result": "CRITICAL",
>> "uuid": "6820b5b3-08a9-4632-a834-a71d1ae0d84b",
>> "when": "20220708144958Z",
>> "duration": "0.000894",
>> "kw": {
>> "key": "proxy_secrets",
>> "proxy_conf": "/etc/httpd/conf.d/ipa-pki-proxy.conf",
>> "msg": "No ProxyPassMatch secrets found in {proxy_conf}"
>> }
>> },
>
>
> There should be a shared secret for the AJP communication between IPA
> and the CA.
>
> in /etc/httpd/conf.d/ipa-pki-proxy.conf you should have a few lines like:
>
> ProxyPassMatch ajp://localhost:8009 secret=<something>
>
>
> The same secret should be in /etc/pki/pki-tomcat/server.xml:
>
> <Connector port="8009" protocol="AJP/1.3"
redirectPort="8443"
> address="127.0.0.1" secret="<something>"
name="Connector1"/>
>
> <Connector port="8009" protocol="AJP/1.3"
redirectPort="8443"
> address="::1" secret="<something>"
name="Connector2"/>
>
This is a regex bug if the secret contains any special characters. Mine happens to start
with a special character, which the script regular expression at
freeipa-healthcheck/src/ipahealthcheck/ipa/proxy.py:89 (PROXY_RE = r'\s+ProxyPassMatch
ajp://localhost:8009 secret=(\w+)$') parses as empty.
I've reported it at
https://pagure.io/freeipa/issue/9203
The word match for 'secret=(\w+)$' fails if the first character of the secret
isn't alphanumeric. It would incorrectly handle a secret with embedded special
characters, though I don't think it would trigger an error, except when the initial
alphanumeric portion of the secret was in fact different.
Ok yeah, bad regex.
rob