-----Original Message-----
>From: Michael ORourke <mrorou...@earthlink.net>
>Sent: Apr 8, 2016 11:01 AM
>To: Sumit Bose <sb...@redhat.com>, freeipa-users@redhat.com
>Subject: Re: [Freeipa-users] AD Integration change propagation timing
>
>-----Original Message-----
>>From: Sumit Bose <sb...@redhat.com>
>>Sent: Apr 8, 2016 3:36 AM
>>To: freeipa-users@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
>

*UPDATE*

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. 

-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

-- 
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

Reply via email to