[Freeipa-users] Updated doc, synchronization question

[Dmitri Pal]

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/