Re: [Freeipa-users] AD Integration change propagation timing
-Original Message- >From: Michael ORourke >Sent: Apr 8, 2016 11:01 AM >To: Sumit Bose , freeipa-users@redhat.com >Subject: Re: [Freeipa-users] AD Integration change propagation timing > >-Original Message- >>From: Sumit Bose >>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
Re: [Freeipa-users] AD Integration change propagation timing
-Original Message- >From: Sumit Bose >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 > >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
Re: [Freeipa-users] AD Integration change propagation timing
On Fri, Apr 08, 2016 at 09:36:11AM +0200, Sumit Bose wrote: > 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. Yes, just please be aware of https://fedorahosted.org/sssd/ticket/2899 which was fixed only recently and we haven't released sssd-1.13.4 yet upstream. -- 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
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. 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
[Freeipa-users] AD Integration change propagation timing
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. 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
