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

Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.

Looking to carve out IT costs?

Freeipa-users mailing list

Reply via email to