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?
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland