Re: [Freeipa-users] Updated doc, synchronization question
> > > Two questions: > > > > > > - Any ETA on an updated 3.3.3 Users Guide? > > > >>> > > > >>> Our current plan is to release next documentation release along with > > > >>> FreeIPA > > > >>> 3.4, when more documentation fixes are factored in. > > > >>> > > > > Would you by any chance know when FreeIPA 3.4 will be realised? > > > > Looking to update a version 2.2 and would wait for 3.4 if its > > reasonably soon. > > > > We planned for Feb but it seems like it would slip. How much is unclear. > We might reduce the scope and cut it earlier (I mean do not slip too > much) or try to keep the scope and extend the time couple months. > We will decide in early Feb. Thanks a lot for the estimated release date. Please do make some announcement once you guys make up your mind which route to take. William > > Sorry not to have a more precise answer. > > Thanks > Dmitri > > > William > > > > > >>> Just in case you would like to check the most recent status of the > > > >>> documentation work (or even help us with it), this page describes > > > >>> the details > > > >>> > > > >>> http://www.freeipa.org/page/Contribute/Documentation > > > >>> > > > >>> including instructions how to build HTMLs out of our git tree. > > > >>> > > > >> > > > >> Thanks, I'll take a look. > > > >> > > > - Is AD/IPA synchronization still supported in 3.3.3? Will it > > always? > > > >>> > > > >>> The AD/IPA synchronization is supported only in terms in bug fixes. > > > >>> As for the > > > >>> enhancements, the FreeIPA core team is focusing on the AD trusts: > > > >>> > > > >>> http://www.freeipa.org/page/Trusts > > > >>> > > > >>> (That does not mean we are not open to contributions from the > > > >>> community) > > > >>> > > > >>> Martin > > > >>> > > > >> > > > >> Thanks for the that link - the video was helpful. Although I'm > > > >> afraid that is > > > >> making me lean towards implementing the not recommended "split brain" > > > >> approach. Although one thing that is not clear to me is weather > > > >> doing this > > > >> consumes CALs for the linux machines since they authenticate > > against AD. > > > > Linux machines do not authenticate against AD DC in single sign-on > > > > case. Instead, usually Windows users obtain their Kerberos TGT upon > > > > logon to > > > > Windows machines and then use it to obtain tickets to services on > > Linux > > > > machines, by obtaining cross-realm TGT from AD DC and presenting it to > > > > IPA KDC as a proof. So in single sign-on case it works fine -- > > > > authentication against AD happens on AD side. > > > > > > > > Of course, when AD users attempt to log in with password to IPA > > > > resources, SSSD would perform communication with AD DC to obtain > > TGT on > > > > their behalf. There is AD DC involved in making a decision whether > > > > this AD user is allowed to authenticate. On Kerberos level, however, > > > > there are no limitations from where the authentication request comes > > > > (unless it is restricted with the firewalls). CALs play role on using > > > > Windows resources after authentication happened but in IPA AD trusts > > > > case currently only IPA resources can be consumed by AD users, IPA > > users > > > > cannot yet consume Windows resources and therefore get assigned rights > > > > to access them. > > > > > > > > > > To clarify the CAL part. > > > The CALs come in two shapes: per user and per host. > > > If it is per user and you have users in AD then regardless of how you > > > integrate with IPA you have to pay these CALs. > > > If your CALs is around hosts then they are based on the count of the > > > computer objects in AD. > > > If the client system is joined directly and has kerberos identity in AD > > > domain you have an object in AD that counts towards CALs. > > > If you have client joined to IPA and either trust or sync solution in > > > place the client is not a member of AD (no computer object in AD) and > > > this does not count towards CALs. > > > > > > HTH > > > > > > > > > > > > > > > -- > > > Thank you, > > > Dmitri Pal > > > > > > Sr. Engineering Manager for IdM portfolio > > > Red Hat Inc. > > > > > > > > > > > > > > ___ > > Freeipa-users mailing list > > Freeipa-users@redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > --- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > -- next part -- > An HTML attachment was scrubbed... > URL: < https://www.redhat.com/archives/freeipa-users/attachments/20140112/fe887df9/attachment.html > > > --- ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Updated doc, synchronization question
On 01/11/2014 04:00 PM, William Muriithi wrote: > > > > Two questions: > > > > - Any ETA on an updated 3.3.3 Users Guide? > > >>> > > >>> Our current plan is to release next documentation release along with > > >>> FreeIPA > > >>> 3.4, when more documentation fixes are factored in. > > >>> > > Would you by any chance know when FreeIPA 3.4 will be realised? > > Looking to update a version 2.2 and would wait for 3.4 if its > reasonably soon. > We planned for Feb but it seems like it would slip. How much is unclear. We might reduce the scope and cut it earlier (I mean do not slip too much) or try to keep the scope and extend the time couple months. We will decide in early Feb. Sorry not to have a more precise answer. Thanks Dmitri > William > > > >>> Just in case you would like to check the most recent status of the > > >>> documentation work (or even help us with it), this page describes > > >>> the details > > >>> > > >>> http://www.freeipa.org/page/Contribute/Documentation > > >>> > > >>> including instructions how to build HTMLs out of our git tree. > > >>> > > >> > > >> Thanks, I'll take a look. > > >> > > - Is AD/IPA synchronization still supported in 3.3.3? Will it > always? > > >>> > > >>> The AD/IPA synchronization is supported only in terms in bug fixes. > > >>> As for the > > >>> enhancements, the FreeIPA core team is focusing on the AD trusts: > > >>> > > >>> http://www.freeipa.org/page/Trusts > > >>> > > >>> (That does not mean we are not open to contributions from the > > >>> community) > > >>> > > >>> Martin > > >>> > > >> > > >> Thanks for the that link - the video was helpful. Although I'm > > >> afraid that is > > >> making me lean towards implementing the not recommended "split brain" > > >> approach. Although one thing that is not clear to me is weather > > >> doing this > > >> consumes CALs for the linux machines since they authenticate > against AD. > > > Linux machines do not authenticate against AD DC in single sign-on > > > case. Instead, usually Windows users obtain their Kerberos TGT upon > > > logon to > > > Windows machines and then use it to obtain tickets to services on > Linux > > > machines, by obtaining cross-realm TGT from AD DC and presenting it to > > > IPA KDC as a proof. So in single sign-on case it works fine -- > > > authentication against AD happens on AD side. > > > > > > Of course, when AD users attempt to log in with password to IPA > > > resources, SSSD would perform communication with AD DC to obtain > TGT on > > > their behalf. There is AD DC involved in making a decision whether > > > this AD user is allowed to authenticate. On Kerberos level, however, > > > there are no limitations from where the authentication request comes > > > (unless it is restricted with the firewalls). CALs play role on using > > > Windows resources after authentication happened but in IPA AD trusts > > > case currently only IPA resources can be consumed by AD users, IPA > users > > > cannot yet consume Windows resources and therefore get assigned rights > > > to access them. > > > > > > > To clarify the CAL part. > > The CALs come in two shapes: per user and per host. > > If it is per user and you have users in AD then regardless of how you > > integrate with IPA you have to pay these CALs. > > If your CALs is around hosts then they are based on the count of the > > computer objects in AD. > > If the client system is joined directly and has kerberos identity in AD > > domain you have an object in AD that counts towards CALs. > > If you have client joined to IPA and either trust or sync solution in > > place the client is not a member of AD (no computer object in AD) and > > this does not count towards CALs. > > > > HTH > > > > > > > > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager for IdM portfolio > > Red Hat Inc. > > > > > > > > ___ > Freeipa-users mailing list > Freeipa-users@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Updated doc, synchronization question
> Two questions: > > - Any ETA on an updated 3.3.3 Users Guide? > >>> > >>> Our current plan is to release next documentation release along with > >>> FreeIPA > >>> 3.4, when more documentation fixes are factored in. > >>> Would you by any chance know when FreeIPA 3.4 will be realised? Looking to update a version 2.2 and would wait for 3.4 if its reasonably soon. William > >>> Just in case you would like to check the most recent status of the > >>> documentation work (or even help us with it), this page describes > >>> the details > >>> > >>> http://www.freeipa.org/page/Contribute/Documentation > >>> > >>> including instructions how to build HTMLs out of our git tree. > >>> > >> > >> Thanks, I'll take a look. > >> > - Is AD/IPA synchronization still supported in 3.3.3? Will it always? > >>> > >>> The AD/IPA synchronization is supported only in terms in bug fixes. > >>> As for the > >>> enhancements, the FreeIPA core team is focusing on the AD trusts: > >>> > >>> http://www.freeipa.org/page/Trusts > >>> > >>> (That does not mean we are not open to contributions from the > >>> community) > >>> > >>> Martin > >>> > >> > >> Thanks for the that link - the video was helpful. Although I'm > >> afraid that is > >> making me lean towards implementing the not recommended "split brain" > >> approach. Although one thing that is not clear to me is weather > >> doing this > >> consumes CALs for the linux machines since they authenticate against AD. > > Linux machines do not authenticate against AD DC in single sign-on > > case. Instead, usually Windows users obtain their Kerberos TGT upon > > logon to > > Windows machines and then use it to obtain tickets to services on Linux > > machines, by obtaining cross-realm TGT from AD DC and presenting it to > > IPA KDC as a proof. So in single sign-on case it works fine -- > > authentication against AD happens on AD side. > > > > Of course, when AD users attempt to log in with password to IPA > > resources, SSSD would perform communication with AD DC to obtain TGT on > > their behalf. There is AD DC involved in making a decision whether > > this AD user is allowed to authenticate. On Kerberos level, however, > > there are no limitations from where the authentication request comes > > (unless it is restricted with the firewalls). CALs play role on using > > Windows resources after authentication happened but in IPA AD trusts > > case currently only IPA resources can be consumed by AD users, IPA users > > cannot yet consume Windows resources and therefore get assigned rights > > to access them. > > > > To clarify the CAL part. > The CALs come in two shapes: per user and per host. > If it is per user and you have users in AD then regardless of how you > integrate with IPA you have to pay these CALs. > If your CALs is around hosts then they are based on the count of the > computer objects in AD. > If the client system is joined directly and has kerberos identity in AD > domain you have an object in AD that counts towards CALs. > If you have client joined to IPA and either trust or sync solution in > place the client is not a member of AD (no computer object in AD) and > this does not count towards CALs. > > HTH > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Updated doc, synchronization question
On 01/09/2014 07:51 PM, Alexander Bokovoy wrote: > On Thu, 09 Jan 2014, Orion Poplawski wrote: >> On 01/09/2014 06:07 AM, Martin Kosek wrote: >>> On 01/08/2014 07:16 PM, Orion Poplawski wrote: Two questions: - Any ETA on an updated 3.3.3 Users Guide? >>> >>> Our current plan is to release next documentation release along with >>> FreeIPA >>> 3.4, when more documentation fixes are factored in. >>> >>> Just in case you would like to check the most recent status of the >>> documentation work (or even help us with it), this page describes >>> the details >>> >>> http://www.freeipa.org/page/Contribute/Documentation >>> >>> including instructions how to build HTMLs out of our git tree. >>> >> >> Thanks, I'll take a look. >> - Is AD/IPA synchronization still supported in 3.3.3? Will it always? >>> >>> The AD/IPA synchronization is supported only in terms in bug fixes. >>> As for the >>> enhancements, the FreeIPA core team is focusing on the AD trusts: >>> >>> http://www.freeipa.org/page/Trusts >>> >>> (That does not mean we are not open to contributions from the >>> community) >>> >>> Martin >>> >> >> Thanks for the that link - the video was helpful. Although I'm >> afraid that is >> making me lean towards implementing the not recommended "split brain" >> approach. Although one thing that is not clear to me is weather >> doing this >> consumes CALs for the linux machines since they authenticate against AD. > Linux machines do not authenticate against AD DC in single sign-on > case. Instead, usually Windows users obtain their Kerberos TGT upon > logon to > Windows machines and then use it to obtain tickets to services on Linux > machines, by obtaining cross-realm TGT from AD DC and presenting it to > IPA KDC as a proof. So in single sign-on case it works fine -- > authentication against AD happens on AD side. > > Of course, when AD users attempt to log in with password to IPA > resources, SSSD would perform communication with AD DC to obtain TGT on > their behalf. There is AD DC involved in making a decision whether > this AD user is allowed to authenticate. On Kerberos level, however, > there are no limitations from where the authentication request comes > (unless it is restricted with the firewalls). CALs play role on using > Windows resources after authentication happened but in IPA AD trusts > case currently only IPA resources can be consumed by AD users, IPA users > cannot yet consume Windows resources and therefore get assigned rights > to access them. > To clarify the CAL part. The CALs come in two shapes: per user and per host. If it is per user and you have users in AD then regardless of how you integrate with IPA you have to pay these CALs. If your CALs is around hosts then they are based on the count of the computer objects in AD. If the client system is joined directly and has kerberos identity in AD domain you have an object in AD that counts towards CALs. If you have client joined to IPA and either trust or sync solution in place the client is not a member of AD (no computer object in AD) and this does not count towards CALs. HTH -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Updated doc, synchronization question
On Thu, 09 Jan 2014, Orion Poplawski wrote: On 01/09/2014 06:07 AM, Martin Kosek wrote: On 01/08/2014 07:16 PM, Orion Poplawski wrote: Two questions: - Any ETA on an updated 3.3.3 Users Guide? Our current plan is to release next documentation release along with FreeIPA 3.4, when more documentation fixes are factored in. Just in case you would like to check the most recent status of the documentation work (or even help us with it), this page describes the details http://www.freeipa.org/page/Contribute/Documentation including instructions how to build HTMLs out of our git tree. Thanks, I'll take a look. - Is AD/IPA synchronization still supported in 3.3.3? Will it always? The AD/IPA synchronization is supported only in terms in bug fixes. As for the enhancements, the FreeIPA core team is focusing on the AD trusts: http://www.freeipa.org/page/Trusts (That does not mean we are not open to contributions from the community) Martin Thanks for the that link - the video was helpful. Although I'm afraid that is making me lean towards implementing the not recommended "split brain" approach. Although one thing that is not clear to me is weather doing this consumes CALs for the linux machines since they authenticate against AD. Linux machines do not authenticate against AD DC in single sign-on case. Instead, usually Windows users obtain their Kerberos TGT upon logon to Windows machines and then use it to obtain tickets to services on Linux machines, by obtaining cross-realm TGT from AD DC and presenting it to IPA KDC as a proof. So in single sign-on case it works fine -- authentication against AD happens on AD side. Of course, when AD users attempt to log in with password to IPA resources, SSSD would perform communication with AD DC to obtain TGT on their behalf. There is AD DC involved in making a decision whether this AD user is allowed to authenticate. On Kerberos level, however, there are no limitations from where the authentication request comes (unless it is restricted with the firewalls). CALs play role on using Windows resources after authentication happened but in IPA AD trusts case currently only IPA resources can be consumed by AD users, IPA users cannot yet consume Windows resources and therefore get assigned rights to access them. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Updated doc, synchronization question
On 01/09/2014 06:07 AM, Martin Kosek wrote: > On 01/08/2014 07:16 PM, Orion Poplawski wrote: >> Two questions: >> >> - Any ETA on an updated 3.3.3 Users Guide? > > Our current plan is to release next documentation release along with FreeIPA > 3.4, when more documentation fixes are factored in. > > Just in case you would like to check the most recent status of the > documentation work (or even help us with it), this page describes the details > > http://www.freeipa.org/page/Contribute/Documentation > > including instructions how to build HTMLs out of our git tree. > Thanks, I'll take a look. >> - Is AD/IPA synchronization still supported in 3.3.3? Will it always? > > The AD/IPA synchronization is supported only in terms in bug fixes. As for the > enhancements, the FreeIPA core team is focusing on the AD trusts: > > http://www.freeipa.org/page/Trusts > > (That does not mean we are not open to contributions from the community) > > Martin > Thanks for the that link - the video was helpful. Although I'm afraid that is making me lean towards implementing the not recommended "split brain" approach. Although one thing that is not clear to me is weather doing this consumes CALs for the linux machines since they authenticate against AD. Currently we have two main office locations (DNS cora.nwra.com and nwra.com) plus some remote users and a 389-ds LDAP server for the Linux boxes and an AD domain (NWRA.LOCAL). We are using the LDAP/AD password/user sync module to sync users and passwords. Essentially, all of our Linux users are Windows users and vice versa, and we have well established UIDs on both sides. We would like to move to using Kerberos on the Linux machines and to be able to have as much SSO capability as possible. Am I correct in assuming that this either requires a single KDC or trusts between KDCs? While trusts are being promoted as the way to go for this, I'm afraid it will require a lot of tweaking to our current setup. Or perhaps not. We currently maintain DNS outside of both AD and would do the same IPA. We're happy to apply custom configurations via puppet, etc. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Updated doc, synchronization question
On 01/08/2014 07:16 PM, Orion Poplawski wrote: > Two questions: > > - Any ETA on an updated 3.3.3 Users Guide? Our current plan is to release next documentation release along with FreeIPA 3.4, when more documentation fixes are factored in. Just in case you would like to check the most recent status of the documentation work (or even help us with it), this page describes the details http://www.freeipa.org/page/Contribute/Documentation including instructions how to build HTMLs out of our git tree. > - Is AD/IPA synchronization still supported in 3.3.3? Will it always? The AD/IPA synchronization is supported only in terms in bug fixes. As for the enhancements, the FreeIPA core team is focusing on the AD trusts: http://www.freeipa.org/page/Trusts (That does not mean we are not open to contributions from the community) Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Updated doc, synchronization question
Two questions: - Any ETA on an updated 3.3.3 Users Guide? - Is AD/IPA synchronization still supported in 3.3.3? Will it always? Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
