| Author | Messages | |
TG
Posts:298
 | | 11/09/2009 8:06 PM |
| Exchange is not in the mix for this forest, so we should be OK there. Any
other gotchas?
Thank you, Tony.
Tony Gordon
Windows 2003 & 2000 MCSE, Windows 2003 MCSA, PMP
ITS Infrastructure Engineering
Tel 847.295.5000 x37892 | Fax 847.883.7892
tony dot gordon at hewitt dot tld | www.hewitt.com
P Please consider the environment before printing this e-mail.
From:
"Grillenmeier, Guido" <guido.grillenmeier@hp.com>
To:
"activedir@mail.activedir.org" <activedir@mail.activedir.org>
Date:
10/29/2009 05:22 PM
Subject:
RE: [ActiveDir] Hiding info in the domain for a subset users
(dsheuristics)
Sent by:
activedir-owner@mail.activedir.org
Tony ? this is basically not a problem. And yes, you?d typically combine
adjusting the default security with using List Object etc?
Nothing really ?relies? on any of the default ACLs set on the objects in
the Schema. What the apps, tools and command like net use etc. rely on is
simply the correct permissions set to the object that they are supposed to
process. If those permissions are applied in a controlled way by yourself
? for example by adjusting the default security descriptors from the
schema objects and then applying them directly either as inherited rights
via an OU or explicit rights directly on an object ? or by using the
default ACLs doesn?t matter.
Note that you?ll of course need to invest a bit in understanding the
permissions you change and the implications on the apps. You can?t just
strip out Authenticated users everywhere and then expect the default
Exchange GAL to still work? You?d how have to generate Custom address
lists to make things work!
/Guido
From: activedir-owner@mail.activedir.org [
mailto:activedir-owner@mail.activedir.org] On Behalf Of Tony Gordon
Sent: Mittwoch, 28. Oktober 2009 23:20
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Hiding info in the domain for a subset users
(dsheuristics)
from the default ACL for user, group and Organizational Unit objects that
is.
Thank you, Tony.
Tony Gordon
Windows 2003 & 2000 MCSE, Windows 2003 MCSA, PMP
ITS Infrastructure Engineering
Tel 847.295.5000 x37892 | Fax 847.883.7892
tony dot gordon at hewitt dot tld | www.hewitt.com
P Please consider the environment before printing this e-mail.
From:
Tony Gordon/National/Hewitt Associates@Hewitt Associates NA
To:
activedir@mail.activedir.org
Date:
10/28/2009 05:19 PM
Subject:
RE: [ActiveDir] Hiding info in the domain for a subset users
(dsheuristics)
Sent by:
activedir-owner@mail.activedir.org
Yes, please. Thank you 
All I want to do is to remove authenticated users from the default ACL.
Not that it is a big deal, but are you saying that net user and net group
will fail in that setup even if a user that is running them actually has
rights (let's say a DA) to enumerate all objects?
Thank you, Tony.
Tony Gordon
Windows 2003 & 2000 MCSE, Windows 2003 MCSA, PMP
ITS Infrastructure Engineering
Hewitt Associates | 100 Half Day Road | Lincolnshire, IL 60069 | USA
Tel 847.295.5000 x37892 | Fax 847.883.7892
tony dot gordon at hewitt dot tld | www.hewitt.com
P Please consider the environment before printing this e-mail.
From:
"Brian Arkills" <barkills@washington.edu>
To:
"activedir@mail.activedir.org" <activedir@mail.activedir.org>
Date:
10/28/2009 12:38 PM
Subject:
RE: [ActiveDir] Hiding info in the domain for a subset users
(dsheuristics)
Sent by:
activedir-owner@mail.activedir.org
The notable downside I've seen is that some tools depend on the default
ACL.. For example, net user and net group both assume that any domain user
can read all user and group objects. So you have to teach support staff to
adjust, and you may have to create new tools which work around this.
List object should be usable regardless of the default ACL.
If you'd like, I can put you in touch with someone at Stanford, where they
run their forest with the defaultSecurityDescriptor for the user object
class stripped off completely. I helped implement that when I worked there
9+ years ago.
From: activedir-owner@mail.activedir.org [
mailto:activedir-owner@mail.activedir.org] On Behalf Of Tony Gordon
Sent: Wednesday, October 28, 2009 9:49 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Hiding info in the domain for a subset users
(dsheuristics)
Guido
What is the downside to adjusting the default security on the objects? It
seems that it is a simpler solution and easier to maintain going forward.
It allows to deal with the allow perms versus deny perms. I am preparing
to test it for the 2008 R2 upgrade in DMZ (have to test the apps for the
upgrade purposes anyway).
It is understood that changing default security does not do anything for
the existing objects and the risk of changing security on them is also
accounted for.
Also, looks like enabling List Object Mode can be used along with
modifying default security, if needed. Correct?
Thank you, Tony.
Tony Gordon
Windows 2003 & 2000 MCSE, Windows 2003 MCSA, PMP
ITS Infrastructure Engineering
Tel 847.295.5000 x37892 | Fax 847.883.7892
tony dot gordon at hewitt dot tld | www.hewitt.com
P Please consider the environment before printing this e-mail.
From:
"Grillenmeier, Guido" <guido.grillenmeier@hp.com>
To:
"activedir@mail.activedir.org" <activedir@mail.activedir.org>
Date:
10/27/2009 03:38 PM
Subject:
RE: [ActiveDir] Hiding info in the domain for a subset users
(dsheuristics)
Sent by:
activedir-owner@mail.activedir.org
You?ll find a mix of what you?ve described being used in different
companies ? really depends on their security requirements, or more often
on their (lack of) awareness of the risks they are taking, when sharing
the same directory without special precautions.
The DSheuristics / List Object option in AD basically gives you an extra
level of control on the visibility of objects in AD ? usually used to hide
those ?normal? objects in AD (users, groups, computer) from all
Authenticated Users and control that they are only visible for the correct
group of people. This is typically used in multi-tenant environments or
other systems that demand a high level of isolation between different user
groups, where you need to hide information at the object level. Definitely
preferable to work with this over trying to deny access to different
groups for different areas of the directory, which can easily lead to a
mess. Note that you may well combine these permissions with other that
hide information at the attribute level.
For your ?trusted third parties? example you?d have to weigh the costs for
managing the added complexity of such an environment over adding a
separate AD forest, which may be hosted quite fine on two or three DCs,
potentially virtual ones. The separate AD forest makes the separation
more clear and will even reduce risks in elevation of privilege attacks.
But if you?d have to isolate 20 different companies (or departments) from
each other that need to collaborate tightly for some reason, but must not
be able to query each others data in AD, sharing the same directory and
hiding the objects via the dsheuristics/List Objects function could be
more attractive...
HTH,
Guido
From: activedir-owner@mail.activedir.org [
mailto:activedir-owner@mail.activedir.org] On Behalf Of Thomas Vuylsteke
Sent: Mittwoch, 21. Oktober 2009 23:50
To: activedir@mail.activedir.org
Subject: [ActiveDir] Hiding info in the domain for a subset users
(dsheuristics)
Hey list,
I have been struggling with the following:
We sometimes have customers with a setup like this: single forest, single
domain, A web application (with authentication based on AD users) and
published by ISA to get it available externally. They publish it
externally because they distribute some asp.net client application for
their ?partner? companies. These partner companies have nothing to do with
the company, but or just ?trusted third parties? with which they
colaborate. So for every partner, credentials (a user object) has to be
foreseen.
The question is: where do you store these users? Especially minding
security.
I think there are several scenario?s possible:
· Use ADFS -> this seems more likely in a 1 to 1 partner trust
scenario where you trust multiple users from 1 partner. Having an ADFS
setup with 200 partners seems overkill to me
· Use ADAM/AD LDS -> this could be possible, however this would
require the internal users also to be in ADAM (perhaps as ldap proxyuser
accounts. As I?ve heard (not sure if it?s correct) that when an IIS
application can only be configured to authenticate against one source: AD
OR ADAM not both at the same time
· Use a separate forest with a two-way trust: the two-way trust
would be required for their Kerberos Constrained Delegation to work
· Have them in a separate OU and play around with ?dsheuristics?
and ?object visibility? (
http://www.mail-archive.com/activedir@mail.activedir.org/msg37341.html
gives a nice table)
· Have them in a separate OU and leave all default
· ?
I?m not sure what the security risks would be if you leave them in a
separate ou and change nothing. But I suppose it would be way to easy to
query AD (as an authenticated user) and get a list of all email addresses.
That?s internal information that I would not want to be retrieved by
external companies. They would however have to be on the premises (LAN) or
compromise the IIS to achieve this. Or perhaps there are other risks which
are more likely to happen.
About the DSheuristics option: Am I correct that this is typically used in
hosting scenario?s where you want to hide the information of other
customers or your own administrative stuff? I suppose it?s not intended to
hide all ?configuration? stuff like the configuration partition or the
default containers like users, system or the ?domain controllers ou?. I
might be really mistaken about the goal of this option. I mean, I
understand that by given ?list object? permissions you make sure certain
ou?s are visible. I can see how that works downwards from a specific OU,
but what with all the ?default? stuff in the domain where authenticated
users have read permissions on. Next to that, if you simply set deny read
on certain ou?s for specific groups this would also work without having
the dsheuristic option. But I guess that would be harder to maintain if
you have a lot of different companies to protect from each other.
What?s your guys point of view on these kind of scenario?s?
Thomas Vuylsteke
System Engineer Server Technology
thomas.vuylsteke@realdolmen.com
The information contained in this e-mail and any accompanying documents
may contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if
this message has been addressed to you in error, please immediately alert
the sender by reply e-mail and then delete this message, including any
attachments. Any dissemination, distribution or other use of the contents
of this message by anyone other than the intended recipient is strictly
prohibited. All messages sent to and from this e-mail address may be
monitored as permitted by applicable law and regulations to ensure
compliance with our internal policies and to protect our business. E-mails
are not secure and cannot be guaranteed to be error free as they can be
intercepted, amended, lost or destroyed, or contain viruses. You are
deemed to have accepted these risks if you communicate with us by e-mail.
The information contained in this e-mail and any accompanying documents
may contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if
this message has been addressed to you in error, please immediately alert
the sender by reply e-mail and then delete this message, including any
attachments. Any dissemination, distribution or other use of the contents
of this message by anyone other than the intended recipient is strictly
prohibited. All messages sent to and from this e-mail address may be
monitored as permitted by applicable law and regulations to ensure
compliance with our internal policies and to protect our business. E-mails
are not secure and cannot be guaranteed to be error free as they can be
intercepted, amended, lost or destroyed, or contain viruses. You are
deemed to have accepted these risks if you communicate with us by e-mail.
The information contained in this e-mail and any accompanying documents
may contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if
this message has been addressed to you in error, please immediately alert
the sender by reply e-mail and then delete this message, including any
attachments. Any dissemination, distribution or other use of the contents
of this message by anyone other than the intended recipient is strictly
prohibited. All messages sent to and from this e-mail address may be
monitored as permitted by applicable law and regulations to ensure
compliance with our internal policies and to protect our business. E-mails
are not secure and cannot be guaranteed to be error free as they can be
intercepted, amended, lost or destroyed, or contain viruses. You are
deemed to have accepted these risks if you communicate with us by e-mail.
The information contained in this e-mail and any accompanying documents
may contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if
this message has been addressed to you in error, please immediately alert
the sender by reply e-mail and then delete this message, including any
attachments. Any dissemination, distribution or other use of the contents
of this message by anyone other than the intended recipient is strictly
prohibited. All messages sent to and from this e-mail address may be
monitored as permitted by applicable law and regulations to ensure
compliance with our internal policies and to protect our business. E-mails
are not secure and cannot be guaranteed to be error free as they can be
intercepted, amended, lost or destroyed, or contain viruses. You are
deemed to have accepted these risks if you communicate with us by e-mail.
The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
| | | |
|
|