> >>>> 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 > >>> > >>> <a href="http://www.freeipa.org/page/Contribute/Documentation">http://www.freeipa.org/page/Contribute/Documentation</a> > >>> > >>> 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: > >>> > >>> <a href="http://www.freeipa.org/page/Trusts">http://www.freeipa.org/page/Trusts</a> > >>> > >>> (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. > >