>From: Michael ORourke <mrorou...@earthlink.net>
>Sent: Apr 8, 2016 11:01 AM
>To: Sumit Bose <sb...@redhat.com>, firstname.lastname@example.org
>Subject: Re: [Freeipa-users] AD Integration change propagation timing
>>From: Sumit Bose <sb...@redhat.com>
>>Sent: Apr 8, 2016 3:36 AM
>>Subject: Re: [Freeipa-users] AD Integration change propagation timing
>>On Thu, Apr 07, 2016 at 10:28:22PM -0400, Michael ORourke wrote:
>>> I have a question regarding AD Integration with FreeIPA (CentOS 7.1/freeipa
>>> 4.2.0) and Windows Server 2008 R2 with a Functional Level forest of 2008 R2.
>>> Given a simple scenario of a group in active directory that is mapped to a
>>> POSIX group in FreeIPA, if a change is made on the AD side such as adding a
>>> user to an AD group, how long should it take on the FreeIPA side before the
>>> change would show up? What would the maximum time it could take before the
>>> change propagates to a server joined to FreeIPA? What if a user was logged
>>> into the server and was waiting on the change (assuming the MS PAC was
>>> cached by sssd)? This would be for a simple forest trust with FreeIPA and a
>>> medium/small AD environment. Also, assuming that sssd was not restarted
>>> and/or the cache flushed.
>>> I'm not looking for exact timing, just some estimates.
>>By default SSSD has a cache timeout of 5400s aka 1.5h, see then
>>entry_cache_timeout and following entries in man sssd.conf for details.
>>In the worst case on a client you have to add the timeout of the client
>>and the server.
>Thanks for the response!
>Here's another scenario... we would like to leverage HBAC rules for users in
>AD groups (assigning the rule to a local posix group which maps back to an AD
>group). So the AD admins would add users to an AD group, which correlates to
>a particular HBAC rule, which grants user access to the host(s).
>Example: AD user tries to login to server joined to IPA, but is denied
>(missing HBAC group membership), so the user puts in a request to the local AD
>team which gets approved and that user is added to the appropriate AD group.
>If the user tries to login to that same server again, it could take up to 1.5h
>for the cache to expire before the user is allowed to login?
>Or is it not cached at the server, because the user was not granted access to
>the server initially? My assumption is that it would only require the Windows
>client to refresh their Kerberos tkt to get a new PAC. Which is easy enough
>to test out.
I tried testing the scenario above by first clearing the Kerberos tkt on the
client, but access was denied. Then I cleared the cache on the target linux
server, sss_cache -E, restarted SSSD, and access was denied. Then I cleared
cache on the IPA server, and restarted SSSD, access granted! So I suspect
clearing the target server's cache had no impact, but haven't proved that yet.
>>If the user logs in the group memberships are updated unconditionally.
>>But this won't effect existing session they will always have the same
>>group memberships as at login time, i.e. the 'id' command will always
>>return the same list of group-memberships even if 'id username' from a
>>different session will tell something different. This is a general
>>UNIX/Linux feature and can be seen with local groups managed in
>>/etc/groups as well.
>>Another thing to take care of is the PAC. Since the PAC is part of the
>>Kerberos ticket it won't change as long as the ticket is valid. E.g. if
>>you log in from a Window client to an IPA client with putty using GSSAPI
>>authentication you get a service ticket for the IPA client which
>>includes the PAC and is stored on the Windows client. If you then change
>>the group memberships of the user in AD and make sure the IPA client
>>sees the new groups memberships, e.g. by invalidating the cache on the
>>client and the server, a fresh login with putty might still show the old
>>group memberships again, because the PAC in the valid Kerberos ticket is
>>not refreshed and might force the client to use the group-membership
>>data from the PAC. In this case you have to call 'klist /purge' on the
>>Windows client to remove the tickets to get a fresh PAC.
>>> Manage your subscription for the Freeipa-users mailing list:
>>> Go to http://freeipa.org for more info on the project
>>Manage your subscription for the Freeipa-users mailing list:
>>Go to http://freeipa.org for more info on the project
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project