I've seen lots of customers running them, so it's not just you. :) > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells > Sent: Friday, January 07, 2005 17:22 > To: Send - AD mailing list > Subject: RE: [ActiveDir] Forest trusts vs trusts within forests > > Does nobody but me like or even prefer stub zones? ;-) > > -- > Dean Wells > MSEtechnology > * Email: [EMAIL PROTECTED] > http://msetechnology.com > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Grillenmeier, Guido > Sent: Friday, January 07, 2005 5: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/ > > > 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/
