Re: Permissions Chart ?? or web site ??

:)

Everyone FULL CONTROL is still fine in anonymous conditions UNLESS you have explicitly enabled the share to allow null session access through the registry. You can set the share to allow anonymous explicitly in the ACL and in the NTFS perms and it still won't allow anonymous access until the registry is changed. In that way, everyone is effectively authenticated users.

There is a similar setting for AD in K3 AD and better, but instead of a registry tweak, it is a dshueristics value which is one of the "registry-type-tweak" locations of AD.

The environments I deal in tend to have tens of thousands of file shares and thousands of local site admins (or even tens of thousands), 99% of whom don't really understand in the slightest bit how Windows works so the most secure way of doing things is the most simple to understand easily automated way. If you take the file share aspect out of the question things get considerably simpler. In fact, in most environments I have to work on file share stuff for, I redirect them from ad hoc shares to three types of shares per server and the local site admins (which could actually be secretaries) don't even have to understand what a share is let alone properly configure it.

One single Project Share which gets mapped to a fixed drive letter for all local site people. If you have three project share servers in a site, it will be three drive letters for those project shares. If DFS is being used, this can be shut back to down to a single drive letter company wide. The directory structure is such that everyone can read the first level of the directory but the direct subdirectories are locked down by specific groups for each directory with a group format of something like prefix_directoryname_C (change access), prefix_directoryname (read access) (prefix can vary based on company, but places that use Local Groups will usually use something like shr for the prefix or proj to let you know it is proj group, if domain local groups are used then the prefix will also include servername or sitename). You then have scripts that can easily validate or reACL the folders programmatically. You can even have scripts quickly and easily rebuild the entire group structure if necessary if you lost everything but the raw data.

The first level directory of Proj will have local site info in it such as contact people on specific processes for the site that visitors to the site will need to know to get up and running. If someone can authenticate, and again, those are the only people who can get to the share with everyone:FC, then they should be able to read that info.

One single share per server for apps run from the servers (served apps, i.e. the executable lives on the server but is brought down locally to the workstation when run). This may sound odd but is a great way to run any apps that don't have registry and local install components aside from launch icons. If you need to update the app or lock people out of the app, it is very simple to do. This is normally done for LOB apps that are used by specific groups of people, not Office type apps that get deployed to everyone. However this same share is also used for software deployments and possibly even machine build processes and is actually set up as a null session share so that it can always be reached regardless of the machine platform (say like by the DOS boot disks used to build machines, etc).

These two shares are created as part of the server build process, the site admins never have to touch them. They simply populate the folders underneath and it is their responsibility to make sure the NTFS ACLs are correct. If someone can't access something, it is simply a matter of looking at the NTFS permissions.

The last set of shares are home drive shares for the individual users. Again, set up with everyone FC and the NTFS is locked down. Same reasons. So you don't have to have a conversation with thousands of admins who can't be bothered to read the manual or guidance given to them.


The permissioning system is pretty simple, but the number of people that grasp it fully seems to be a very small minority of people who are tasked to manage it. In large environments you can tilt at the windmills and try to train every single person (ignoring the fact that not everyone can be trained and not everyone wants to be trained) or you can accept reality and set up a simple mechanism that has greater chance of being secure (and followed) due to lack of confusion.

joe



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


Herb Martin wrote:
"steve" <stevesemple@xxxxxxxxx> wrote in message news:1180449929.510497.273030@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thanks again.

Im sure there are as many opinions on this as settings. However on the
set everyone to full, the Book Im reading "MCSE guide to managing a
microsoft windows server 2003 environment enhance" for the course IM
taking says to delete the everyone user all together as the "everyone
group includes all users who have access to the network, regardless of
whether they have been authenticated in the domain."

Yes, but don't hold Joe to that portion to tightly anyway (even though
we disagreed I wouldn't do that) as he probably would tell you to really
use "Authenticated Users" or otherwise "restrict anonymous".

Our difference was on the GENERAL recommendation for a STRATEGY,
where I insist that it is best to use the MINIMUM permissions in each
place for specific GROUPS.

Add the authenticated domain users users or groups that you watnt to
have access.

Yes, that part is important. Make these the minimum you can tolerate
at the share and at the NTFS permissions -- if the minimum is FC then
that is what you must use (as Joe said) but if the minimum is READ then
I claim you should set the share to read.


.

Relevant Pages

  • RE: How to Grant Power Users rights to administrative shares.
    ... This is on windows server 2003. ... right click shares and select new file share ... The "Create A Shared Folder Wizard" opens click next. ... Please check the permission settings of the shared folders. ...
    (microsoft.public.windows.server.sbs)
  • Re: FP 2003 message: An error occurred accessing Windows Sharepoint Services site files.
    ... Microsoft MVP - FrontPage ... local site from My Network Places, I got the attached error message. ... Scroll down to the Server Health section and click the link for Check ... Open your local site from there. ...
    (microsoft.public.frontpage.extensions.windowsnt)
  • Re: VPN access to network file shares
    ... "The file shares are on a server running Windows Small Business Server ...
    (microsoft.public.windows.server.sbs)
  • Re: D8: first impression and uneasy feeling... (long)
    ... pack server apps and gui apps. ... I think people that defends .net here is people doing mostly server ... Borland has an incredible potential here, but it has to realize there ... with a .NET server and a win32 client. ...
    (borland.public.delphi.non-technical)
  • Re: 64-bit - the desaster continues ...
    ... > Server operating systems. ... that hosts ten thousands of mailboxes, server apps using large ... I don't see any competitors rushing out to implement 64-bit ... shipped two 64-bit operating systems compiled with this compiler, ...
    (borland.public.delphi.non-technical)