[Freeipa-users] Updated doc, synchronization question

[William Muriithi]

> >>>> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140111/24e26051/attachment.htm>