On 09/17/2014 12:38 AM, Greg Scott wrote:
Thanks everyone for the advice.  Here's a sanitized version of what I put 
together for my end user customer.  Feel free to use any of this text as you 
see fit.


Here's the scoop with IdM and AD trusts.  It's an "official" 2-way trust with 
the currently shipping IdM version - I think it's 3.3.5 right now.  It's an official 
2-way trust, but de-facto it's only one way because IdM doesn't have all the pieces it 
needs yet to allow AD to trust IdM.   So IdM can trust AD but right now AD cannot trust 
IdM.  Red Hat Support told us that in the support case and I confirmed it with the 
upstream community.  So even though it says it's a 2-way trust, it's really only one way.

Somewhere in the future, around version 4.3 or so, so it's a long way away, the plan is 
for IdM to have the pieces it needs for AD to trust IdM.  When that time comes, there are 
a number of options for ***?.  One is to stick with today's current version. "If it 
ain't broke, don't fix it."  Another is to continue upgrading to the current 
versions as they become available and redo the trust to be an official one way trust when 
the time comes.   Another option - just leave it as a 2-way trust.

The decision doesn't come up for a long time - if I had to guess, I'd put it 
sometime after 2015.  That's just my guess because the people doing the 
development don't know themselves and they're the ones building this stuff.  
It's a long time out.  And even then, it's not a huge decision.  Let's say ***? 
decides to leave it as a 2-way trust.  What are the consequences?  Are there 
now suddenly 2 sources of truth?  Is there a security hole?  Is AD suddenly 

My answer would be no, no, and no.

On sources of truth - There will always be a few unique users in the Linux IdM 
domain.  User root, for example, and probably a few others.  This is true 
whether there is no trust, a one-way trust, or a 2-way trust.  IdM is like a 
Windows forest with one domain.  And AD is a forest with at least one domain.  
By definition, both forests have their own individual entities.

On security holes - with a 2-way trust, the AD Administrator now has the 
ability to regulate access to AD resources from IdM users and groups.  If the 
AD Admin takes no action, then nobody on the IdM side can access anything on 
the AD side.   Just because the AD administrator has this ability does not 
imply the he will use it.  If he doesn't use it - the default action - nothing 

Is AD suddenly vulnerable?  No.  Even with a 2-way trust, the AD Admin has to 
take specific actions in cooperation with others to allow anyone from IdM to 
access anything inside AD.

My opinion isn't worth the disk space to store this text and free opinions are 
worth what you pay for them.   So test it yourself.  ***? has the tools right 
now.  Build a Windows forest - independent of your Dev forest - and do some 
experiments with 2-way cross forest trusts.   Set up and destroy a few trust 
relationships with your existing Dev domain/forest and my proposed test forest 
and grant permissions to a few groups from one side into the other side.  You 
can do it with one Windows VM.  Now substitute IdM for that test Windows forest 
when the time comes and the issues are exactly the same.

One more point on vulnerability.  I know the choice to copy AD users into IdM 
is well-known, safe, and comfortable at ***?.  That's the way they did it last 
time.  But this choice requires non Microsoft software on the ***? AD domain 
controllers.  So thinking it through - which represents the most risk?  Setting 
up a cross forest trust where the AD administrator retains total control over 
everything, or putting foreign software on the Windows domain controllers to 
copy user passwords to an untrusted entity?

-       Greg

This deserves a wiki page, blog and a keynote at a couple conferences.

Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

Manage your subscription for the Freeipa-users mailing list:
Go To http://freeipa.org for more info on the project

Reply via email to