Hi guys.
Domain seems to function okey, 'healthcheck' reports no issues, but these begin to worry me, from sssd_pac.log ... (2022-08-14 16:19:52): [pac] [accept_fd_handler] (0x0020): Access denied for uid [389]. * ... skipping repetitive backtrace ... (2022-08-14 16:19:54): [pac] [accept_fd_handler] (0x0020): Access denied for uid [389]. * ... skipping repetitive backtrace ... (2022-08-14 16:19:54): [pac] [accept_fd_handler] (0x0020): Access denied for uid [389]. * ... skipping repetitive backtrace ... (2022-08-14 16:20:00): [pac] [accept_fd_handler] (0x0020): Access denied for uid [389].
and this log is quite busy. What is that symptom of and should that be a worry?
many thanks, L.
Am Sun, Aug 14, 2022 at 04:34:30PM +0100 schrieb lejeczek via FreeIPA-users:
Hi guys.
Domain seems to function okey, 'healthcheck' reports no issues, but these begin to worry me, from sssd_pac.log ... (2022-08-14 16:19:52): [pac] [accept_fd_handler] (0x0020): Access denied for uid [389]. * ... skipping repetitive backtrace ... (2022-08-14 16:19:54): [pac] [accept_fd_handler] (0x0020): Access denied for uid [389]. * ... skipping repetitive backtrace ... (2022-08-14 16:19:54): [pac] [accept_fd_handler] (0x0020): Access denied for uid [389]. * ... skipping repetitive backtrace ... (2022-08-14 16:20:00): [pac] [accept_fd_handler] (0x0020): Access denied for uid [389].
Hi,
you can allow 389ds to send the PAC to SSSD by setting
allowed_uids = 0, 389
in the [pac] section of sssd.conf, see man sssd.conf for details.
SSSD can use the PAC to determine group-memberships of a user and since we do not want that any process can tinker with the group-memberships we allow access only from "trusted" UIDs.
HTH
bye, Sumit
and this log is quite busy. What is that symptom of and should that be a worry?
many thanks, L. _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org 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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 15/08/2022 06:16, Sumit Bose wrote:
Am Sun, Aug 14, 2022 at 04:34:30PM +0100 schrieb lejeczek via FreeIPA-users:
Hi guys.
Domain seems to function okey, 'healthcheck' reports no issues, but these begin to worry me, from sssd_pac.log ... (2022-08-14 16:19:52): [pac] [accept_fd_handler] (0x0020): Access denied for uid [389]. * ... skipping repetitive backtrace ... (2022-08-14 16:19:54): [pac] [accept_fd_handler] (0x0020): Access denied for uid [389]. * ... skipping repetitive backtrace ... (2022-08-14 16:19:54): [pac] [accept_fd_handler] (0x0020): Access denied for uid [389]. * ... skipping repetitive backtrace ... (2022-08-14 16:20:00): [pac] [accept_fd_handler] (0x0020): Access denied for uid [389].
Hi,
you can allow 389ds to send the PAC to SSSD by setting
allowed_uids = 0, 389in the [pac] section of sssd.conf, see man sssd.conf for details.
SSSD can use the PAC to determine group-memberships of a user and since we do not want that any process can tinker with the group-memberships we allow access only from "trusted" UIDs.
Okey,. so is the fact that it's dirsrv itself wants something which makes SSSD not happy, is "abnormal", unexpected and dirsrv is not such "trusted" process/id? I'm not dong anything fancy - it's a "standard" deployment with Samba.
many thanks, L.
HTH
bye, Sumit
and this log is quite busy. What is that symptom of and should that be a worry?
many thanks, L. _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org 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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On ma, 15 elo 2022, lejeczek via FreeIPA-users wrote:
On 15/08/2022 06:16, Sumit Bose wrote:
Am Sun, Aug 14, 2022 at 04:34:30PM +0100 schrieb lejeczek via FreeIPA-users:
Hi guys.
Domain seems to function okey, 'healthcheck' reports no issues, but these begin to worry me, from sssd_pac.log ... (2022-08-14 16:19:52): [pac] [accept_fd_handler] (0x0020): Access denied for uid [389]. * ... skipping repetitive backtrace ... (2022-08-14 16:19:54): [pac] [accept_fd_handler] (0x0020): Access denied for uid [389]. * ... skipping repetitive backtrace ... (2022-08-14 16:19:54): [pac] [accept_fd_handler] (0x0020): Access denied for uid [389]. * ... skipping repetitive backtrace ... (2022-08-14 16:20:00): [pac] [accept_fd_handler] (0x0020): Access denied for uid [389].
Hi,
you can allow 389ds to send the PAC to SSSD by setting
allowed_uids = 0, 389
in the [pac] section of sssd.conf, see man sssd.conf for details.
SSSD can use the PAC to determine group-memberships of a user and since we do not want that any process can tinker with the group-memberships we allow access only from "trusted" UIDs.
Okey,. so is the fact that it's dirsrv itself wants something which makes SSSD not happy, is "abnormal", unexpected and dirsrv is not such "trusted" process/id? I'm not dong anything fancy - it's a "standard" deployment with Samba.
I would say SSSD probably needs to tone down this warning. Any server application accepting Kerberos (either through GSSAPI or raw Kerberos) would load a PAC plugin from SSSD and that one would try to connect to SSSD PAC responder. We don't necessary want any of those servers to contribute to PAC cache, as Summit said.
Sumit, may be we can bump the log level for this section to some of higher debug levels?
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
lejeczek -
Sumit Bose