[Freeipa-users] One way trusts

[Alexander Bokovoy]

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.


-- 
/ Alexander Bokovoy