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/ _______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
