|
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----- 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. |
Title:
- RE: [ActiveDir] Forest trusts vs trusts within forests John Reijnders
- RE: [ActiveDir] Forest trusts vs trusts within fo... Fugleberg, David A
- RE: [ActiveDir] Forest trusts vs trusts within fo... John Reijnders
- RE: [ActiveDir] Forest trusts vs trusts within fo... John Reijnders
- RE: [ActiveDir] Forest trusts vs trusts within fo... Gil Kirkpatrick
- RE: [ActiveDir] Forest trusts vs trusts within fo... Fugleberg, David A
- RE: [ActiveDir] Forest trusts vs trusts within fo... Mulnick, Al
- RE: [ActiveDir] Forest trusts vs trusts within fo... Grillenmeier, Guido
- RE: [ActiveDir] Forest trusts vs trusts withi... Dean Wells
- RE: [ActiveDir] Forest trusts vs trusts w... Deji Akomolafe
- RE: [ActiveDir] Forest trusts vs trusts w... David Adner
