[Freeipa-users] AD Integration change propagation timing

[Michael ORourke]

-----Original Message-----
>From: Sumit Bose <sbose at redhat.com>
>Sent: Apr 8, 2016 3:36 AM
>To: freeipa-users at redhat.com
>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.

-Mike

>
>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.
>
>HTH
>
>bye,
>Sumit
>
>> 
>> Thanks,
>> Mike
>> 
>> -- 
>> Manage your subscription for the Freeipa-users mailing list:
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> Go to http://freeipa.org for more info on the project
>
>-- 
>Manage your subscription for the Freeipa-users mailing list:
>https://www.redhat.com/mailman/listinfo/freeipa-users
>Go to http://freeipa.org for more info on the project