On ti, 30 elo 2022, liang fei via FreeIPA-users wrote:
liang fei via FreeIPA-users wrote:
Need a lot more information.
What version of IPA on client and server, and what distribution?
What is the context? Is this a new problem? Did it ever work? It appears
you're running this on a server, please confirm.
We need the apache error log (snippet) and relation lines from the KDC log.
Per your subsequent message, this probably has nothing to do with
certificates but the output is illuminating.
a-error: Error setting up ccache for "host" service on client using
default keytab: No such file or directory.
You are apparently missing /etc/krb5.keytab
Goes back to the history question. What has been going on with this
installation?
rob
freeipa4.3 All operations are performed on the CA machine,
This is long time unsupported version already. Is there any chance you'd
move to something newer?
Yes, for some reason, /etc/krb5.keytab does not exist and
/etc/apache2.ipa.keytab kinit was unsuccessful, so I did the following.
Keytab for httpd service was moved to /var/lib/ipa/gssproxy/http.keytab
in 2016. We stopped using /etc/httpd/conf/ipa.keytab (or
/etc/apache2/ipa.keytab for Debian and Ubuntu) in that time.
ipa-getkeytab -p host/host.xx.com -k /etc/krb5.keytab
ipa-getkeytab -p HTTP/host.xx.com -e aes256-cts -k
/tmp/spnego.service.keytab
ipa-getkeytab -p HTTP/host.xx.com -e aes128-cts -k
/tmp/spnego.service.keytab
ipa-getkeytab -p HTTP/host.xx.com -e des3-hmac-sha1 -k
/tmp/spnego.service.keytab
ipa-getkeytab -p HTTP/host.xx.com -e arcfour-hmac -k
/tmp/spnego.service.keytab
ipa-getkeytab -p HTTP/host.xx.com -e camellia128-cts -k
/tmp/spnego.service.keytab
ipa-getkeytab -p HTTP/host.xx.com -e camellia256-cts -k
/tmp/spnego.service.keytab
cp /tmp/spnego.service.keytab /etc/security/ketabs
cp /tmp/spnego.service.keytab /etc/apache2/ipa.keytab
This exception should be an error related to the
/etc/apache2/ipa.keytab file, because I have a native /etc/krb5.keytab
file on another test machine.Only perform the ipa - getkeytab - p - e
aes256 HTTP/host.xx.com - CTS - k/TMP/spnego. Service. Keytabr
operation, so this exception,
ipa user-find admin
...
ipa: ERROR: error marshalling data for XML-RPC transport: message: need a <type
'unicode'>; got 'No valid Negotiate header in server response' (a <type 'str'>)
tailf /var/logs/apach2/error
[Tue Aug 30 11:32:32.237368 2022] [auth_gssapi:error] [pid 57977:tid
140374488082176] [client 10.12.65.188:64398] gss_accept_sec_context() failed:
[No credentials were supplied, or the credentials were unavailable or
inaccessible (Unknown error)], referer: https://ipa-test-xx.com/ipa/xml
Perhaps your configuration lacks the rest of config files? May be it
would be better to stand up a separate machine using the same version,
for a test deployment and see what configuration files are present there
and what files they reference. This way you'd have a reference point to
compare your 'broken' replica against and would be able to recover
those.
The 'auth_gssapi:error' message above says that whatever a client sent
as a Kerberos-based negotiation cannot be understood by the GSSAPI
mechanism or the mechanism used was not allowed. Judging by 'No valid
Negotiate header in server response' on the client side it may well be
that configuration of mod_auth_gssapi + gssproxy was not correct on this
machine.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
