[Freeipa-users] Is there any delay after applied rules to user?

[Martin Kosek]

On 07/29/2015 05:03 PM, Dewangga wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello!
>
> Thanks for the hints both of you, yes the sssd_cache is in play.

Good!

> I've set the cache to false, is it have any impact to ipa
> server/client (performance, security or another issue)?

Disabling cache for testing is fine, it is not that fine for production 
environment. Without cache enabled, SSSD would always ask server so it would 
have performance impact, yes.

It should not be visible with couple clients, but once you work with big 
network, it will.

> On 7/29/2015 21:39, Jakub Hrozek wrote:
>> On Wed, Jul 29, 2015 at 04:32:42PM +0200, Martin Kosek wrote:
>>> On 07/29/2015 03:22 PM, Dewangga Bachrul Alam wrote:
>>>> Hello!
>>>>
>>>> I'm using FreeIPA 4.1.x on CentOS 7, Is there any delay after
>>>> applied some rules to specified user?
>>>>
>>>> [root at ipa ~]# ipa sudorule-show Rule name: wheel Rule name:
>>>> Wheel Enabled: TRUE Host category: all Command category: all
>>>> RunAs User category: all RunAs Group category: all Sudo order:
>>>> 1 Users: dewangga User Groups: wheel Sudo Option:
>>>> !authenticate
>>>>
>>>>
>>>> On ipa-client, user `dewangga` asking for password when
>>>> execute command `sudo -l`
>>>>
>>>> [dewangga at sherief-repository ~]$ sudo -l [sudo] password for
>>>> dewangga:
>>>>
>>>> Here is `ipa user-show dewangga` result :
>>>>
>>>> $ ipa user-show dewangga User login: dewangga First name:
>>>> Dewangga Last name: Alam Home directory: /home/dewangga Login
>>>> shell: /bin/bash Email address: [removed] UID: 642000001 GID:
>>>> 642000001 Account disabled: False Password: False Member of
>>>> groups: wheel Member of Sudo rule: Wheel Kerberos keys
>>>> available: False SSH public key fingerprint: [removed]
>>>> mahaesa-key (ssh-rsa)
>>>>
>>>> Any helps are appreciated. Thanks
>>>
>>> I suspect that SSSD cache is in play. You can try to remove it
>>> ("man sss_cache" or remove it manually "stop sssd, remove
>>> /var/lib/sss/db/* and start sssd again").
>>
>> I think restarting SSSD should help here. You can read the type of
>> sudo refreshes sssd does in man sssd-sudo.
>>
>> If it doesn't, we need sssd logs.
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (MingW32)
>
> iQEcBAEBAgAGBQJVuOsyAAoJEF1+odKB6YIxN8YH+gLezNhWVzS8UDipFM7cBR5b
> xxj7M0rnkemHlvTVx5tzDkibTDzc3zLlcqX36EtdFWCp4N4uTvchnEbhzilcYW/T
> kRCAbLtHndhknx8U+eNrKw3EtrErSaDYjADboqqjyuiUfG7xaHwsomqje2F0PvFf
> c8wOkLxg1eLAZH3zTnZpHxW1PVx4Tdb+7RjwAEr4YFHoDhpe/k422H74ji2wPe3X
> 5MYJSbtxEra5qfDGsFN9nRKZkVPf/useSlBVH/mtonpT2YYTkdOIJqRaZw1xAG2V
> Dmuo4dIeZseKDg79easC2AeRtjckvjBo1NPJ4zfBtL8TJ9MZmpScOSh/zCF5miM=
> =cKjO
> -----END PGP SIGNATURE-----
>