RE: [ActiveDir] Forest trusts vs trusts within forests

[Gil Kirkpatrick]

Title: Message

David,   As with most things, its a cost/benefit question. Managing an additional forest adds non-trivial costs to the equation, but provides the security it seems you are looking for.    There's a interesting paper on risk analysis at http://www-2.cs.cmu.edu/~shawnb/SREIS.pdf. It describes a methodlogy for assessing IT risk. Basically, you identify possible threats and rank them according to level of concern, Then for the top N threats you classify the possible consequences of a successful attack, e.g. compromised data, lost productivity, regulatory fines, lost prestige, etc. Finally you assess attack frequencies and calculate a threat index for each threat. The threat index provides a relative evaluation of the importance of particular threat. Then you compare the TI ranking with the initial ranking and resolve the differences. The idea is to focus on the threats with the highest index.   The value of the process isn't the actual calculation of the TI; the value is in actually sitting down with your security people and managers and thinking about threats and consequences, and comparing the potential costs of attack to the costs of mitigation. Its a good process and very enlightening, and it forces you to get the right people involved.   -gil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fugleberg, David A Sent: Friday, January 07, 2005 8:51 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Forest trusts vs trusts within forests First, thanks to all of you for the many well-reasoned replies to my post.  You've confirmed some things for me and filled in some blanks.  I'll try to answer the questions that some of you asked and see what you think.   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.   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.   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.       Of course, you and I both know that sooner or later (most likely sooner) there will be an absolute requirement to grant access to resources in one domain for users from another.  I can easily see such needs in both directions here.  So, trusts will be required and the "complete" isolation is gone.   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 ?   One more question - one document I read indicated that Selective Authentication works as long as the domain holding the resources is 2000 Native or better.  Other things seem to indicate that both domains must be at W2K3 FFL.  Will SA and SID filtering work if the new domain is W2K3 FFL and the old one is at W2K Native ?   [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! -----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 J, 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.