Expanding on KB 244600?

[Will]

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]]

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

 

[Roger Abell [MVP]]

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.

 

[Roger Abell [MVP]]

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]

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.

 

[Roger Abell [MVP]]

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.

 

[Guest]

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.

 

[Roger Abell [MVP]]

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.

 

[Will]

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.

 

[Roger Abell [MVP]]

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

 

[Will]

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.

 

[Roger Abell [MVP]]

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.