Hello Dèjì, good thoughts, but not sure that I agree
with all you say - I believe Dave's scenario could benefit from a separate
forest - see some comments below.
Cheers,
Guido
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Deji Akomolafe
Sent: Saturday, January 08, 2005 12:30 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Forest trusts vs trusts within forests
Without disagreeing with any
of the points you made, don't you think multi-forest deployment is an "overkill"
for what he's trying to achieve?
Let's look at the SOW again:
The
motivations for considering another forest are the
following:
1) we
have some remote sites with workstations that authenticate to the domain so
they can be managed with GPOs and software distribution. They have no real
need to access MS resources at the main site. In some cases, there are
enough of these workstations to warrant a local DC. We don't want DCs for
the one and only existing domain in some of these locations, because we can't
always control physical access to them. An isolated forest (no
trusts) for these would protect the internal forest in the event the new forest
was compromised, compartmentalizing the damage.
OK, if he does implement a separate forest, he will still NEED Trusts in
order to have any relationship between these forests, so we know that the NO
TRUST aspect of this requirement can't be met. So, if there is TRUST, and the
UNPROTECTED (throw-away) forest is compromise, the malicious 0wn3r now has the
ability to compromise the PROTECTED forest as well. I know it is harder to do,
but it is a reality
[Guido] I do have to disagree here, as you're making it sound as if there's no real benefit for separate forests from a security perspective. That's not true. It's not neccessarily the trust between one forest or the other that allows a malicious user to attack the "PROTECTED" forest. It's the fact that this user has some kind of physical access or network connectivity to the "UNPROTECTED" network, which - with or without compromise of the "UNPROTECTED" forest - allows him to attack the other forest. The trust between the two forests (with SID-filtering enabled, which is the case by default) doesn't really make it easier for the attacker - especially if you've taken appropriate precautions in the "PROTECTED" forest to hinder enumeration of all accounts to all authenticated users (which would be even easier to restrict using Selective Auth. as available with 2003 DFL) etc.
[Guido] I do have to disagree here, as you're making it sound as if there's no real benefit for separate forests from a security perspective. That's not true. It's not neccessarily the trust between one forest or the other that allows a malicious user to attack the "PROTECTED" forest. It's the fact that this user has some kind of physical access or network connectivity to the "UNPROTECTED" network, which - with or without compromise of the "UNPROTECTED" forest - allows him to attack the other forest. The trust between the two forests (with SID-filtering enabled, which is the case by default) doesn't really make it easier for the attacker - especially if you've taken appropriate precautions in the "PROTECTED" forest to hinder enumeration of all accounts to all authenticated users (which would be even easier to restrict using Selective Auth. as available with 2003 DFL) etc.
In any case, this
attack won't be nearly as easy as an attack against the "PROTECTED" forest, if
Dave were to add another domain to this forest and locate it's DCs in the
"UNPROTECTED" locations. In general I advise, if a separate OU in your
main forest is not enough isolation for your security needs, then you'll have to
create a separate forest - don't even think about creating a new domain in the
same forest to gain any _security_
benefits.
2)
there's no need to replicate the thousands of internal user and computer
accounts to the locations mentioned above - a new domain, whether it's in a new
forest or not, would eliminate this unwanted replication.
Someone already answered this previously, pointing to the enchanced
compression and replication algorithm in 2K3. Even so, any replication "storm"
will be mostly a one-time incident for the initial synch. So, we can eliminate
this from the list of reasons to do a new Forest
[Guido] maybe I missed it, but I didn't see Dave mention any numbers or sizes of his environment. If e.g. his current main domain/forest has 100.000 users and the remote sites have a total of 1.000 users, then it's simply a different story compared to a main domain of 5.000 users with 500 remote users...
[Guido] maybe I missed it, but I didn't see Dave mention any numbers or sizes of his environment. If e.g. his current main domain/forest has 100.000 users and the remote sites have a total of 1.000 users, then it's simply a different story compared to a main domain of 5.000 users with 500 remote users...
Also, I
do not generally agree that there is less replication traffic in Win2k3 -
naturally the replication traffic caused from group membership changes has
decreased through LVR (which requires the forest to be at 2003 FFL), but for
other changes such as new or changed accounts, PW changes etc.
the amount of data that's replicated between sites has actually
increased slightly from 2000 to 2003. This is due to a change of the
compression algorithm which has been improved in performance/speed in
2003, but which doesn't reach the same compression ratio as the slower algorithm
of Win2000. This means, that although a 2003 DC will spend less CPU cycles on
compressing data to replicate to remote sites, it will actually transfer
more data to the remote site (if you have very slow links, you can
actually change the compression algorithm back to that of Win2000). Again, the
net impact really depends on the size of Dave's main forest and the ratio
between the amount of changes done to group memberships vs. other changes
etc.
3) some applications require access by vendors, suppliers,
etc. There is some desire to keep such accounts physically seperate from
the internal directory. Part of this was because many intranet resources
are granted to 'authenticated users', and people have a hard time realizing that
some clerk at one of our suppliers is just as much an 'authenticated user' as an
internal employee[1]. If such accounts were in a completely isolated
forest (no trusts), they would not be authenticated users in our internal
domain.
Again, the "no trust" assumption is really not borne out here, as there
has to be a trust in order to make any of the other proposals work. Also, wrt
applications and vendor accounts, I think the focus really needs to be on
putting up an efficient and effective
control/authentication/authorization/access mechanism if the applications use
Windows accounts. If the applications use their own user accounts, then the
"authenticated user" issue is irrelevant. The current permissioning practice
that David describes above is THE issue here. Going into a SEPARATE forest
will only shift the problem to another forest, rather than removing the
problem. Now, if the permissioning (mal-)practice still exists with
the applications in the new forest, the same knowledgeable person can
still elevate privileges and - by leveraging the TRUST
- still create problems for the PROTECTED forest.
[Guido] fully agree on the neccessity to focus on authorization settings to increase the overall security, regardless of trusts or same forest. Naturally, even if Dave would "only" setup a one-way trust so that the main forest trusts the remote forest (in order to allow remote users to access resources from the main forest), these remote users would (by default) still be an "authenticated user" in the main forest.
[Guido] fully agree on the neccessity to focus on authorization settings to increase the overall security, regardless of trusts or same forest. Naturally, even if Dave would "only" setup a one-way trust so that the main forest trusts the remote forest (in order to allow remote users to access resources from the main forest), these remote users would (by default) still be an "authenticated user" in the main forest.
However,
if Dave's main domain were running Win2003 (which I understand it's currently
not), then he would have the option to leverage Selective Authentication in a
way that would restrict any remote domain's user to only specific resources in
the main domain (e.g. a web-server). He could even restrict that only users from
the remote domain, who are members of a specific group (e.g. a global group in
the remote domain or even a local group in the main domain) would be allowed to
authenticate to these resources. In the end this would allow Dave to
differentiate his vendor users from his internal employees by only allowing the
latter to authenticate to the main forest at all and thus control access to
resources that are accessible by "authenticated users" in the main
forest... As Selective Authentication is not available within a
forest, this would not be achieveable with a separate domain (which I'd not
suggest anyways - see above) - if the vendor and supplier accounts are in the
same forest, they'll automatically become an authenticated user and thus he'd
have to change security on all websites to further restrict these as appropriate
(which would be a good idea
nonetheless).
At last, just
to repeat what Dean already confirmed: Selective Auth. requires the trusting
forest to be at Win2003 Domain Functional level (I'd say this would be Dave's
main forest which would thus require an upgrade - and if this forest only has
one domain, then there's obviously not much of a reason not to switch to Forest
Functional level...). The externally trusted domain can be of any type -
even NT4 or Win2000 mixed mode. To setup a true forest trust (allowing
kerberos authentication etc.), both forests have to run Win2003 forest
functional level. I've tested and implemented
both.
/Guido
Sincerely,
Dèjì Akómöláfé, MCSE+M MCSA+M MCP+I
Dèjì Akómöláfé, MCSE+M MCSA+M MCP+I
Microsoft MVP
- Directory Services
www.readymaids.com - we know
IT
www.akomolafe.com
Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon
www.akomolafe.com
Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon
From: Grillenmeier, Guido
Sent: Fri 1/7/2005 2:24 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Forest trusts vs trusts within forests
I'd say JFK jr. answered it between the lines ;-) Happy New Year John and all! A domain in a separate forest with a trust to another forest will be less risky than a domain within the same forest - esp. under the circumstances that Dave described (such as limited physical security in the remote offices). So without going in details, with the information given I'd say two forests + trusts is a valid choice. If you require Kerberos auth. between the two domains (in the two forests), then both would need to run 2003. Otherwise it'll be a "NT4 style" external trust using NTLM auth. Naturally you'll have a little more hassle with DNS, but the second domain/forest could certainly use a child zone of the existing forest (e.g. 1st-dommain = company.com, 2nd-domain = child.company.com) and will need to setup your zone transfers or forwarding appropriately (again something which is done more easily with Win2003's conditional forwarding...) /Guido -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Friday, January 07, 2005 11:09 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Forest trusts vs trusts within forests Out of curiosity, did you get your question answered? The original that I read was that you wanted to know if you had two separate forests with trusts, would that create the same risks as if they were in the same forest. I *think* I read that correctly. I think John had a lot of great information in there, but I got to the thread too late which makes it harder to read and tell what was said etc. Just curious mostly. Al -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fugleberg, David A Sent: Friday, January 07, 2005 3:50 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Forest trusts vs trusts within forests Thanks John. To answer your questions: 1) the topology is hub/spoke. I would put a couple DCs for the new forest in the hub location. 2) Regarding replication, most of these sites have few to no Exchange users - those that do use OWA. So, I'm not worried losing the common GC that a single forest provides. I'll need to work with the Exchange team to see if/how any future plans impact this assessment, of course. Bandwidth is not the issue for wanting to compartmentalize replication. It's more about having a r/w copy of the internal directory at all of these sites that have no use for it. 3) The applications would by and large be at the central location. Some could live in the second forest (see #1). I'm certain that the business will want some of these users to access some apps in the internal forest, though- hence the need to trust the new forest. I'm also sure that our support people will want the new forest to trust the internal forest to make it easier to support. There's no illusion on my part that any configuration gives me a 100% security guarantee - if there was, someone would have found it an all of us in info security would have to find real jobs! Thanks again for the insights. I truly appreciate getting a sanity check. Around my company I'm the one people go to for AD expertise, so when I need to bounce things off of people it's often on this list. Happy Friday! Dave -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Reijnders Sent: Friday, January 07, 2005 10:36 AM To: 'ActiveDir@mail.activedir.org' Subject: RE: [ActiveDir] Forest trusts vs trusts within forests Hi David, Take 2 ;-). See inline comments for my ideas. 1) we have some remote sites with workstations that authenticate to the domain so they can be managed with GPOs and software distribution. They have no real need to access MS resources at the main site. In some cases, there are enough of these workstations to warrant a local DC. We don't want DCs for the one and only existing domain in some of these locations, because we can't always control physical access to them. An isolated forest (no trusts) for these would protect the internal forest in the event the new forest was compromised, compartmentalizing the damage. I'm interested in the physical structure of your network. Are the 'evil' sites fully connected to all other sites (centrally and the other 'evil' sites), or is the network topology more like a hub-and-spoke model? Implementing a separate domain or forest for the 'evil' sites would require some sort of connectivity between them or the implementation of DC for this domain/forest in your centrally and trustworthy site. But you're right that an isolated forest would take care of this. 2) there's no need to replicate the thousands of internal user and computer accounts to the locations mentioned above - a new domain, whether it's in a new forest or not, would eliminate this unwanted replication. There's no need to replicate the usr and cptr accounts, but there might be a need to replicate things like GC info for an Exchange address book? Replication has become very efficient in W2003 and I wouldn't be surprised if replication traffic wouldn't pose a problem. It really depends on the bandwith you have, but I havn't seen many implementations in which replication traffic forced me to implements multiple forest/domains. 3) some applications require access by vendors, suppliers, etc. There is some desire to keep such accounts physically seperate from the internal directory. Part of this was because many intranet resources are granted to 'authenticated users', and people have a hard time realizing that some clerk at one of our suppliers is just as much an 'authenticated user' as an internal employee[1]. If such accounts were in a completely isolated forest (no trusts), they would not be authenticated users in our internal domain. Yep! This calls for a federated forest construction. But are these applications located at the 'evil' sites or is this a totally different geographical spreading that might require an additional forest in the centrally managed site? What I'm trying to figure out is whether a seperate forest with trusts in both directions (with SA and SID Filtering) gets me closer to the objective than a new domain in the existing forest. It seems to me that a new domain in the existing forest would take care of #2, but not the other issues, which brings up the new forest idea. I just don't want to introduce a new forest only to find that the required trusts put me right back in the same situation as if I had just added a child domain to the existing forest. Comments ? The most obvious way to ensure 1 and 3 (I don't consider 2 to be a 'real' issue, but just one of those arguments that comes in handy to add another one to the list of pro's to achieve your goal ;-), is a separate Forest. This does not put you right back in the same situation, because several extra steps are introduced that makes it tougher to do whatever you're not allowed to do on the other side. From a technical point of view, the FedFor construction with SA and Sidfiltering (be aware that this breaks SIDHistory!) is a very solid solution. This does not give you a 100% safety garanty. You will need to monitor your environment (non techical/social hacking can be far more dangerous!) for strange events. [1]Yeah, I know that I could put them in another OU, and the resources should really be ACLed so only intended groups have access instead of relying on 'authenticated users'. Maybe that's the path I should push for regarding #3 - your comments are welcome! Duh ... No further comments your honour! I rest my case ... Cheers! John Reijnders -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Reijnders Sent: Friday, January 07, 2005 1:42 AM To: 'ActiveDir@mail.activedir.org' Subject: RE: [ActiveDir] Forest trusts vs trusts within forests Happy New Year to you as well! In order to make a good decision for yourself whether or not you can and need to protect yourself against clever DomaAdmins, Service Admins and/or people with physical access to your DC's some extra info: Ways to bypass standard security: - Add the Enterprise Admin SID to your token (ex in you SidHistory). This can be done by using a 'improved' version of kerberos.dll, which will add the enterpr adm sid to every service ticket. - You can modify the system software or Directory db to bypass sec checks by: o Changing the default sec.descriptor for an objclass o Add a user to the enterprise adm Univ.Group on a GC o Execute a logon script in a site GPO - Or schedule an AT job which runs under local system credentials. (Partial) solutions to these problems are: * Delegation of control * Physical protection of ALL DCs * SID filtering (enabled by default) * Pro active Monitoring (!) * Multiple Forests (!!) Some benefits of W2K3 trusts: * Transitive (not really a sexy feature in you 2 single dom forest design) * You can use kerberos logon in stead of NTLM. * You can use both implicit and explicit UPN logon over the trust Selective Authentication (which is disabled by default and applies to external, realm and forest trusts): This option provides a method that you can use to achieve better granularity for authentication requests that come across a trust. When you enable it, all authentication is examined on the service DC. The service DC verifies that the user is explicitly allowed to authenticate to the resource before allowing the authentication request through. Because of this, you need to specify which users who come across the trust can authenticate to which resources in the domain when you enable the SA option across a trust. You can do this if you set up the "Allowed to Authenticate" control access right on an object for that particular user or group from the other forest or domain. When a user authenticates across a trust with the SA option enabled, a special "Other Organization" SID is added to the user's authorization data. The presence of this SID triggers a verification on the service domain to ensure that the user is allowed to authenticate to the particular service. After the user is authenticated, the server to which the user authenticates adds another SID, the "This Organization" SID. * You can disable the corresponding DomainInfo record for the domain or the TopLevelName record for the tree in the UI. This method is useful when only a small part (read domain) of the other forest is not trusted. Note that only authentication requests from users in that domain are disabled when you disable a DomainInfo record. When you disable a DomainInfo record, authentication requests are not disabled if those authentication requests are received from users who are in the local forest if those users want to gain access to resources that are in the disabled domain. This is not really applicable in your scenario. If you're going for the multiple forest scenario, consider the security benefits this will give you and compare them to the additional costs (extra hardware, no super GC is available by default unless you start using stuff like MIIS :-), extra management, etc.). Let us know what you end up with and ... why ;-) Cheers, John Reijnders -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fugleberg, David A Sent: donderdag 6 januari 2005 21:32 To: activedir@mail.activedir.org Subject: [ActiveDir] Forest trusts vs trusts within forests Happy New Year ! I'm having a design discussion with myself about adding a forest vs adding a domain to an existing forest. I understand about the automatic transitive trust between domains in a forest, and how it's possible for a clever domain admin in a subdomain to compromise the entire forest. What I'm shaky on is this: If you had two single-domain forests, and established trusts in both directions between them, do you have the same issues ? I would think not, because the configuration and schema NCs are not shared between them, but I'm looking for some confirmation on that. Also, since we're talking about two single-domain forests, I'm guessing that the 'forest trusts' available in W2K3 FFL don't really come into play here, correct ? In other words, getting the first domain to W2K3 FFL doesn't buy anything with respect to this trust ? Thanks, Dave List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
