| Author | Messages | |
barkills
Posts:201
 | | 06/11/2010 4:37 PM |
| So there are 3 scenarios you've touched on:
a) 2 forests with a 2 way trust between them
b) 2 forests with a 1 way trust between them
c) 1 forest
With b) you prevent constrained delegation but not unconstrained delegation (and the inability to prevent it over a 1-way trust has always seemed to me to be a security design flaw in AD).
With b) you've said that one domain does not trust the identity vetting procedures of the other forest, but that forest is willing to share their identities and group data for the other forest's authorization decisions.
With a) and b) you get sidFiltering.
With a) and b) you can have two different teams "be" domain admins. This is usually only significant for political, trust, or historical reasons.
With a) and b), you avoid investing in delegated models for a variety of Microsoft products which default to the domain/forest scope. For example, you avoid the need to figure out how to delegate SCCM privs across multiple admin teams.
With a) and b) you run the risk that any given user has multiple user accounts, with different passwords for each, and end-user confusion. And this also equates to confused group memberships and authorization. In contrast, with c) you have the possibility of a single namespace and a single user account. So in short, c) removes collaboration friction.
With c) you have fewer DCs needed, potentially fewer licenses, and potentially fewer people that need domain admin knowledge/experience.
With c) you have a smaller overall provisioning and identity vetting investment.
So ... in summary, *when the groups involved are part of the same org*, the decision between a) or b) and c) doesn't really have much to do with security. It's usually a lot more about politics or history. Or it can be motivated by specific Microsoft applications which have a domain/forest-wide scope, e.g. one of the many variants/versions of Microsoft Dynamics assumes it is the only instance deployed in a given domain/forest. In contrast, the difference between a) and b) has everything to do with security.
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Thomas Vuylsteke
Sent: Thursday, June 10, 2010 2:00 PM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Security boundary in a two domain, two-way trust scenario
Sensitivity: Confidential
Thanks for the feedback. For starters: this case is more or less fictive.
They are managed by the same IT staff. And there is no form of delegation to the users of the external forest. Those users are all (every one of them) regular AD users.
Perhaps a legal requirement is in place which would require a separate domain.
To rephrase my question, what point is it to put a small subset of users in a separate domain/forest? They are managed by the same IT staff and all they ever will do is access ISA published web-apps.
Of course, this means they have a set of domain credentials and potentially they can walk in and log on to a workstation. But that left aside.
I think this reason would apply (from the URL you reference) : Organizations that maintain a directory that is available both internally and externally (such as those that are publicly accessible by users on the Internet)
But that would only make sense if you lock down the access of the external domain to the internal domain. If you have a full two-way forest trust, the trusted domain users are almost internal domain users qua privileges. I'm just thinking of regular AD users, Administration is completely done by the same IT staff.
If any of the above is wrong, please correct me 
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Matt Casey
Sent: donderdag 10 juni 2010 22:48
To: activedir@mail.activedir.org
Subject: Re: [ActiveDir] Security boundary in a two domain, two-way trust scenario
Sensitivity: Confidential
Who administers the two forests(and the domain joined resources within)? Is it two independent groups? The security boundary between the two forests is important to maintain isolation of the individual directory services, directory data, and/or domain joined resources.
If the same admins control both forests then you need to determine what requirements of separation are you required to maintain legally, ethically, etc? If you are required to keep data/resources separate between the organizations then it may be easier to keep maintain forests. Even though they become authenticated users it is still easier to limit access to shared resources with separate domains. Once they are inside the domain things get a bit more complicated unless you are well equipped with auditing, logging, fire alarms etc to ensure users do not end up accessing resources that they shouldn't.
Take a look here, this can help with things to consider: http://technet.microsoft.com/en-us/library/cc730924(WS.10).aspx
On Thu, Jun 10, 2010 at 4:27 PM, Thomas Vuylsteke <Thomas.Vuylsteke@realdolmen.com<mailto:Thomas.Vuylsteke@realdolmen.com>> wrote:
Hey all,
I know of a setup where there is a domain for a firm which hosts the firm's users, application servers and their ISA server.
So after publishing apps by ISA, the internal users can access the apps.
Now add a two-way trust with a separate forest (single domain) which holds user accounts of "partner-firms". By using ISA + Kerberos Constrained Delegation (KCD) they allow those users on their apps.
Now I'm wondering. Is there any security benefit of having those users in a separate AD? Why not house them in the internal AD. In my opinion (I might be wrong), because of the trust, they appear as authenticated users and can do almost as much as a "native" user in the domain. Or am I seeing things wrong here?
Perhaps one benefit could be the "selective authentication" which could be potentially enabled on the trust to limit access to only the App servers. But the stuff from the directory could still be read I think (like usernames & properties).
I suppose the "allow logon to" (User-Workstations attribute: http://msdn.microsoft.com/en-us/library/ms680868(VS.85).aspx) only force users from logging on locally on other than the specified machines. But I guess network logons are still possible. Right?
Any thoughts are appreciated.
Kind regards,
Thomas Vuylsteke
http://setspn.blogpost.com
| | | |
|
|