[Freeipa-users] One way trusts

[Dmitri Pal]

On 01/13/2014 11:50 PM, Alexander Bokovoy wrote:
> Hi,
>
> On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote:
>> Hi Dimitri,
>>
>>> Just to be sure I understand.  You have internal users - they are in
>>> AD. You have external users - they are in LDAP.  You merge two
>>> directories and you want to replace this setup with IPA.
>>
>> Yes.
>>
>>> It seems that to support your use case you would need to make the
>>> external users be IPA users and make AD and IPA trust each other.
>>
>> I think I concur about migrating my external users into IPA and making
>> IPA trust AD. I may be ignorant of some AD nuance, but I do not see why
>> AD needs to trust IPA. AD does not need to trust my LDAP clients
>> currently.
> IPA needs to be able to look up users and groups in AD. To do so, it
> uses Kerberos authentication against AD's Global Catalog services with
> own credentials (per each IPA host). We are using cross-realm
> Kerberos trust here, AD DC trusts cross-realm TGT issued by IPA KDC and
> vice versa, so IPA hosts can bind as their own identity (host/...) to
> AD.
>
> Since we don't implement fully all services needed to grant privileges
> beyond read-only in AD, these binds to AD Global Catalog become
> read-only. They are still required. An alternative would have been to
> always keep an account in AD for each IPA host that needs to query user
> and group identities from AD. We decided to go with the cross-realm
> Kerberos trust instead since it gives better way of privilege separation.
> Cross-realm Kerberos trust is known as cross-forest domain trust in AD
> speak since there are more protocol layers than Kerberos involved (SMB
> protocol, in particular, is used to set up and verify trust
> relationship).
>
> Once we implement AD GC service, AD admins will be able to subject IPA
> users/hosts to further limit their access to other AD services beyond
> simple read-only access to AD LDAP and SMB services. As result, in
> future more fine-grained privilege and security separation between AD
> and IPA will be possible.
>
>>
>>> Also if external users do not authenticate using Kerberos (for example
>>> they always use a special portal) then it does not matter what trust
>>> is between AD and IPA because those users will not have kerberos
>>> tickets that are leveraged in SSO in trust case.
>>
>> I want to be able to point either an LDAP or a Kerberos client at IPA,
>> and have it authenticate my "enterprise" and "external" users for me.
>> I'm not going to tangle with SSO at the moment. Right now, we're just
>> establishing an identity store.
> That is what provided by IPA's AD trusts. IPA machines can resolve
> identities of the users and groups in AD and can authenticate those
> users on logons, subject to HBAC policies.
>
>>> IPA can trust AD. Formally it is a mutual trust but in reality IPA
>>> does not have global catalog support for users in IPA to be able to
>>> access the resources in AD.
>>
>> In many of the tutorials/HOWTOs, I see that there is a requirement to
>> provide credentials having the permission to add a computer to the
>> domain, or being a member of an AD administration group. I'm a lowly
>> standard "User" in the AD. I don't know if that means I can add a
>> computer to the domain or not. I know I lack the ability to edit AD
>> entries that aren't mine, so I really need a solution that does not
>> require creating a trust relationship inside AD.
> Both AD integration solutions we have (synchronization and cross-forest
> domain trusts) assume having higher level access privileges at the time
> integration is set up. I'm unaware of other mechanisms that would give
> you the same flexibility and level of privilege separation between the
> AD and IPA domains. Having a standard 'User' account in AD only entitles
> you to join up to 10 machines in AD. These machine will become a part of
> AD domain and are subject of their policies which are quite extended by
> default. Cross-forest domain trusts, on the other hand, are subject to
> inter-domain trust relationship policies which are better constrained.
>
> One could try to fiddle with AD-joined machine accounts to represent IPA
> hosts but it is very much uncharted territory since there will be no
> integration whatsoever on any of IPA features (access controls to IPA
> services, ID allocation, etc) and everything will need to be set up and
> maintained manually, including periodical refreshes of the machine
> accounts. In addition, Kerberos authentication will simply not work as
> AD has certain assumption over DNS namespace mapping to Kerberos realms.
>
>
>> Is there a way for me to comment out the AD->IPA trust creation, or
>> would that break the IPA->AD trust?
> The latter, since AD->IPA part of the trust is used to query AD users
> and groups. In other words, it is used to provide the key resources
> needed to operate IPA->AD trust part.
>
>
The shorter answer is: to setup any integration you need to ask AD admin
to help you out to setup trust or sync and then you can continue on your
own.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/