Microsoft's KB article #244600 gives default file system permissions for
folders for member servers and domain controllers for Windows 2000. Has
anyone seen any article (or even third party web page or book) that expands
on that and actually talks about the reason for each of these settings,
which Microsoft programs will use those folders and how, etc.?

--
Will

That general type of documentation, what and where MSFT apps use
something is generally unavailable. Personally I believe it is because
no one really knows and it isn't all documented. I have asked for this
on multiple occasions and always get the cold shoulder. Even for things
as recent as Active Directory attributes, etc.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm


Will wrote:
> Microsoft's KB article #244600 gives default file system permissions for
> folders for member servers and domain controllers for Windows 2000. Has
> anyone seen any article (or even third party web page or book) that expands
> on that and actually talks about the reason for each of these settings,
> which Microsoft programs will use those folders and how, etc.?
>

"Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
news:O5fSLqhvGHA.1808@TK2MSFTNGP06.phx.gbl...
> That general type of documentation, what and where MSFT apps use something
> is generally unavailable. Personally I believe it is because no one really
> knows and it isn't all documented. I have asked for this on multiple
> occasions and always get the cold shoulder. Even for things as recent as
> Active Directory attributes, etc.
>

I have the same opinion. Why else would we see things like a
system32\LogFile directory with most all logfiles just dumped
into system32 ? One hand leading but the leash was not put on.

>
> Will wrote:
>> Microsoft's KB article #244600 gives default file system permissions for
>> folders for member servers and domain controllers for Windows 2000.
>> Has
>> anyone seen any article (or even third party web page or book) that
>> expands
>> on that and actually talks about the reason for each of these settings,
>> which Microsoft programs will use those folders and how, etc.?
>>

"Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
news:%23wQ7F5hvGHA.1512@TK2MSFTNGP04.phx.gbl...
>
> "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
> news:O5fSLqhvGHA.1808@TK2MSFTNGP06.phx.gbl...
>> That general type of documentation, what and where MSFT apps use
>> something is generally unavailable. Personally I believe it is because no
>> one really knows and it isn't all documented. I have asked for this on
>> multiple occasions and always get the cold shoulder. Even for things as
>> recent as Active Directory attributes, etc.
>>
>
> I have the same opinion. Why else would we see things like a
> system32\LogFile directory with most all logfiles just dumped
> into system32 ? One hand leading but the leash was not put on.

ummm actually most are dumped at %windir%, some at system32
We all get the point though, MS and software vendors for some
reason seem not to use %temp% or %tmp% for temp files (ex new
folders for windows update at the root of drives, etc.)


>>
>> Will wrote:
>>> Microsoft's KB article #244600 gives default file system permissions for
>>> folders for member servers and domain controllers for Windows 2000. Has
>>> anyone seen any article (or even third party web page or book) that
>>> expands
>>> on that and actually talks about the reason for each of these settings,
>>> which Microsoft programs will use those folders and how, etc.?
>>>
>
>

"Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
news:O5fSLqhvGHA.1808@TK2MSFTNGP06.phx.gbl...
> That general type of documentation, what and where MSFT apps use
> something is generally unavailable. Personally I believe it is because
> no one really knows and it isn't all documented. I have asked for this
> on multiple occasions and always get the cold shoulder. Even for things
> as recent as Active Directory attributes, etc.

Unfortunately, as I start to better understand the system, I get exactly the
same feeling. It really looks like they had large numbers of different
players all integrating together in rather random ways, and "security" was
simply something that got in their way, and the permissions they chose are
utterly random DACLs on folders and files that were the minimum needed to
get each team's code to run.

The infrastructure of DACL and SACL itself seems extremely well done, so how
frustrating it is that Microsoft's infrastructure teams produced a wonderful
security layer at the bottom, and there was apparently no coherent
application of that infrastructure on the higher levels of the OS. And
the only guidance if a customer sees that and wants to (partially) fix it is
to say that if you change default permissions in system32 Microsoft won't
support it.

--
Will

"Will" <westes-usc@noemail.nospam> wrote in message
news:%2364m4zjvGHA.560@TK2MSFTNGP05.phx.gbl...
> "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
> news:O5fSLqhvGHA.1808@TK2MSFTNGP06.phx.gbl...
>> That general type of documentation, what and where MSFT apps use
>> something is generally unavailable. Personally I believe it is because
>> no one really knows and it isn't all documented. I have asked for this
>> on multiple occasions and always get the cold shoulder. Even for things
>> as recent as Active Directory attributes, etc.
>
> Unfortunately, as I start to better understand the system, I get exactly
> the
> same feeling. It really looks like they had large numbers of different
> players all integrating together in rather random ways, and "security" was
> simply something that got in their way, and the permissions they chose are
> utterly random DACLs on folders and files that were the minimum needed to
> get each team's code to run.
>
> The infrastructure of DACL and SACL itself seems extremely well done, so
> how
> frustrating it is that Microsoft's infrastructure teams produced a
> wonderful
> security layer at the bottom, and there was apparently no coherent
> application of that infrastructure on the higher levels of the OS. And
> the only guidance if a customer sees that and wants to (partially) fix it
> is
> to say that if you change default permissions in system32 Microsoft won't
> support it.
>

It should not be considered as a feeling that you have Will. It is a view
of the history from its artifacts. The Cutler group was a new hire team
that worked to design/build NT (NT = new technology). Meanwhile
MS has existing workforce still churning out Windows (on DOS) and
apps for it. For the first few released builds of NT, Windows 3.11 was
still the mainstream, still living in a world with only limited concept of
networking. Around NT 3.5 use began in measurable amounts and
teams shifted focus, to Windows 95 etc, with the apps portable onto
NT, and with MS not quite yet having discovered the internet revolution.
What you see is from the history of use, by MS, and now still by some
of MS and by a fair part of third parties. Leading by example.

OK it's an old post but couldn't resist having my say:

Thinking back to those days, the majority of Win3.1/95 networks used
Netware. This was a very different beast from either Windows Servers or
Linux; for a start it was designed from the outset as a server and not a
server-come-workstation. Since there was never any intention of Tom, Dick or
Harry fooling-around at its keyboard, there was no great need for OS
security. On user-accessible volumes the permissions were designed around the
tasks that typical office-users perform, instead of being primarily there for
the use of programmers. That meant they worked in a way that users could
understand.

Netware was a hideously expensive product for what it did, but the fact
that it did that job so well kept it selling right into the NT era.

Looking at the current state of computing, what's desperately needed is a
slimming-down and rationalisation of software into manageable units.

Sadly, Vista (which we might've hoped would be a more streamlined OS) seems
to be a departure in the exact opposite direction, with massive bloat and
huge levels of complexity. Complexity that makes the overall security of the
system hard to gauge, because few people even understand it.. Considering
that most ordinary users still barely use - or even understand- 10% of what
Windows 95 offered, is this the right way to go to achieve secure computing?
I don't think so.

"Ian" <Ian@discussions.microsoft.com> wrote in message
news:EF268353-38B0-4663-A6B5-E35DECB9700F@microsoft.com...
> OK it's an old post but couldn't resist having my say:
>
> Thinking back to those days, the majority of Win3.1/95 networks used
> Netware. This was a very different beast from either Windows Servers or
> Linux; for a start it was designed from the outset as a server and not a
> server-come-workstation. Since there was never any intention of Tom, Dick
> or
> Harry fooling-around at its keyboard, there was no great need for OS
> security. On user-accessible volumes the permissions were designed around
> the
> tasks that typical office-users perform, instead of being primarily there
> for
> the use of programmers. That meant they worked in a way that users could
> understand.
>
> Netware was a hideously expensive product for what it did, but the fact
> that it did that job so well kept it selling right into the NT era.
>
> Looking at the current state of computing, what's desperately needed is a
> slimming-down and rationalisation of software into manageable units.
>
> Sadly, Vista (which we might've hoped would be a more streamlined OS)
> seems
> to be a departure in the exact opposite direction, with massive bloat and
> huge levels of complexity. Complexity that makes the overall security of
> the
> system hard to gauge, because few people even understand it.. Considering
> that most ordinary users still barely use - or even understand- 10% of
> what
> Windows 95 offered, is this the right way to go to achieve secure
> computing?
> I don't think so.
>
>
Interesting history trip. I would agree that the all, everything, plus
kitchen sink,
approach has well-known problems, and a lesson that appears not learned, in
fact not learned pretty much anywhere. With so many of the problems in
systems
(not just Windows) stemming from the need to carry legacy forward, one would
think it might occur to someone that the kitchen sink approach will have a
very
large footprint into the future ("but we cannot drop that - someone might be
using it").
I hope the approach being taken with factoring and with Longhorn will show
that there is an alternative. IIS 7 is a great example where full
minimization to
task has been taken to heart. The redesign of the network stack's hooks for
firewall/IPsec if good. At this point, I am hoping more will follow the
model.

--
ra

"Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
news:eVYy0T7yGHA.3656@TK2MSFTNGP04.phx.gbl...
> Interesting history trip. I would agree that the all, everything, plus
> kitchen sink,
> approach has well-known problems, and a lesson that appears not learned,
in
> fact not learned pretty much anywhere. With so many of the problems in
> systems
> (not just Windows) stemming from the need to carry legacy forward, one
would
> think it might occur to someone that the kitchen sink approach will have a
> very
> large footprint into the future ("but we cannot drop that - someone might
be
> using it").

Some of the open systems UNIX platforms such as OpenBSD have a minimalist
approach where you only include the absolute minimum into the installed OS
required to do a single specific job. It works extremely well and exposes
absolute minimum footprints to exploit. Too bad they just don't matter
commercially.

--
Will

"Will" <westes-usc@noemail.nospam> wrote in message
news:Pp-dnbSPDb8Te2nZnZ2dnUVZ_sadnZ2d@giganews.com...
> "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
> news:eVYy0T7yGHA.3656@TK2MSFTNGP04.phx.gbl...
>> Interesting history trip. I would agree that the all, everything, plus
>> kitchen sink,
>> approach has well-known problems, and a lesson that appears not learned,
> in
>> fact not learned pretty much anywhere. With so many of the problems in
>> systems
>> (not just Windows) stemming from the need to carry legacy forward, one
> would
>> think it might occur to someone that the kitchen sink approach will have
>> a
>> very
>> large footprint into the future ("but we cannot drop that - someone might
> be
>> using it").
>
> Some of the open systems UNIX platforms such as OpenBSD have a minimalist
> approach where you only include the absolute minimum into the installed OS
> required to do a single specific job. It works extremely well and
> exposes
> absolute minimum footprints to exploit. Too bad they just don't matter
> commercially.
>

As I said to you before, I am waiting to see how much one does get to vary
the Longhorn core server install with later selected/added features. You
will
like changes in Longhorn for all server installs however in this regard.

Roger

"Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
news:OLXcubEzGHA.4232@TK2MSFTNGP04.phx.gbl...
> As I said to you before, I am waiting to see how much one does get to vary
> the Longhorn core server install with later selected/added features. You
> will
> like changes in Longhorn for all server installs however in this regard.

I would even settle for a "fat" system where we could explicitly shut things
off, and where there was *DOCUMENTATION* about *all* of the potential side
effects of turning off various subsystems.

--
Will

"Will" <westes-usc@noemail.nospam> wrote in message
news:rdidnQQ94sqrvGvZnZ2dnUVZ_sydnZ2d@giganews.com...
> "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
> news:OLXcubEzGHA.4232@TK2MSFTNGP04.phx.gbl...
>> As I said to you before, I am waiting to see how much one does get to
>> vary
>> the Longhorn core server install with later selected/added features. You
>> will
>> like changes in Longhorn for all server installs however in this regard.
>
> I would even settle for a "fat" system where we could explicitly shut
> things
> off, and where there was *DOCUMENTATION* about *all* of the potential side
> effects of turning off various subsystems.
>
Let's hope the docs are further improved, as seems to happen
with each major release. However, the new server install does
pretty much what you want, except in reverse, i.e. if you do not
state the role is to be used those are left out from the "flattened"
base system. You are right, that clear doc of all then (doc release
time) known exposures / side-effects due to adding a role would
be most welcome. Believe it or not, things are vastly improved
over NT 4 days when the best source of info came from reading
the SDKs and dev docs.