Share and NTFS permissions - the right mix?!

  • Thread starter Thread starter Richard Price
  • Start date Start date
R

Richard Price

Guest
Hi,

After thinking I had it all nice and sorted, a user goes and does
something which completely invalidated my prior belief.

My setup is thus:

Windows 2003 R2 server hosting network share \\domain\Users\

Under \\domain\Users are a load of directories - richard, martin,
jenny, sam et al. They are users private folders, each mapped to
desktop drive U:\ for the various users when they log into their
desktops.

What I want to accomplish is thus:

Users can see all directories in \\domain\Users, but they cannot see
the contents of those directories, delete those directories or add new
directories.

Users have full control within their own directory under \\domain
\Users

Can anyone recommend the best mix of Share and NTFS permissions to do
this? The solution I have ended up with requires the following:

\\domain\Users Share permissions - Everyone: read, write
\\domain\Users NTFS permissions - Everyone: read, write explicitly
denied

\\domain\Users\richard - no inherited permissions, richard has Full
Control within this folder (as does Domain Admin et al)

This has given me basically the situation I want to end up with, with
one small niggle. It allows richard to access his files perfectly
fine, create new ones and delete old ones et al within his own
directory. It allows richard to see all folders in \\domain\Users
fine, but he cannot access their contents at all. This is exactly how
I want it to work, so so far so good on that front.

The niggle is that the write explicitly denied at the NTFS level has
the effect of denying Domain Admins write access also, which means one
of two things:

1. I create a Security Group containing everyone but Domain Admins
(sounds ugly).
2. I remove the deny each and every time I want to add a new directory
or remove an old one (sounds ugly, and also not only Domain Admins
will be doing this as I want to farm that task out to Account
Operators).

So, is there any way to accomplish my task without ending up with
either of the two 'solutions' needing to be implemented?

Is there a better way to do what I am doing?

Cheers
Richard
 
RE: Share and NTFS permissions - the right mix?!

Have you tried adding Domain Admins at the same level where you have denied
the Everyone group then granting it the required rights. Also I would stay
away from the Everyone Group and go with Authenticated users instead

"Richard Price" wrote:

> Hi,
>
> After thinking I had it all nice and sorted, a user goes and does
> something which completely invalidated my prior belief.
>
> My setup is thus:
>
> Windows 2003 R2 server hosting network share \\domain\Users\
>
> Under \\domain\Users are a load of directories - richard, martin,
> jenny, sam et al. They are users private folders, each mapped to
> desktop drive U:\ for the various users when they log into their
> desktops.
>
> What I want to accomplish is thus:
>
> Users can see all directories in \\domain\Users, but they cannot see
> the contents of those directories, delete those directories or add new
> directories.
>
> Users have full control within their own directory under \\domain
> \Users
>
> Can anyone recommend the best mix of Share and NTFS permissions to do
> this? The solution I have ended up with requires the following:
>
> \\domain\Users Share permissions - Everyone: read, write
> \\domain\Users NTFS permissions - Everyone: read, write explicitly
> denied
>
> \\domain\Users\richard - no inherited permissions, richard has Full
> Control within this folder (as does Domain Admin et al)
>
> This has given me basically the situation I want to end up with, with
> one small niggle. It allows richard to access his files perfectly
> fine, create new ones and delete old ones et al within his own
> directory. It allows richard to see all folders in \\domain\Users
> fine, but he cannot access their contents at all. This is exactly how
> I want it to work, so so far so good on that front.
>
> The niggle is that the write explicitly denied at the NTFS level has
> the effect of denying Domain Admins write access also, which means one
> of two things:
>
> 1. I create a Security Group containing everyone but Domain Admins
> (sounds ugly).
> 2. I remove the deny each and every time I want to add a new directory
> or remove an old one (sounds ugly, and also not only Domain Admins
> will be doing this as I want to farm that task out to Account
> Operators).
>
> So, is there any way to accomplish my task without ending up with
> either of the two 'solutions' needing to be implemented?
>
> Is there a better way to do what I am doing?
>
> Cheers
> Richard
>
 
Re: Share and NTFS permissions - the right mix?!

On May 15, 7:30 pm, Adrian <Adr...@discussions.microsoft.com> wrote:
> Have you tried adding Domain Admins at the same level where you have denied
> the Everyone group then granting it the required rights. Also I would stay
> away from the Everyone Group and go with Authenticated users instead
>

Yes, the deny permission is absolute and overrides any allow
permission a user is granted on the same object. Adding Domain Admins
at the same level and granting it permission has no effect.

regards
Richard
 
Re: Share and NTFS permissions - the right mix?!

mmmm , forgot about that . What's the reason for Denying ? Surely if you just
give them Read rights only that should be fine ?

"Richard Price" wrote:

> On May 15, 7:30 pm, Adrian <Adr...@discussions.microsoft.com> wrote:
> > Have you tried adding Domain Admins at the same level where you have denied
> > the Everyone group then granting it the required rights. Also I would stay
> > away from the Everyone Group and go with Authenticated users instead
> >
>
> Yes, the deny permission is absolute and overrides any allow
> permission a user is granted on the same object. Adding Domain Admins
> at the same level and granting it permission has no effect.
>
> regards
> Richard
>
 
Re: Share and NTFS permissions - the right mix?!

On May 15, 8:14 pm, Adrian <Adr...@discussions.microsoft.com> wrote:
> mmmm , forgot about that . What's the reason for Denying ? Surely if you just
> give them Read rights only that should be fine ?
>

If you do not give the deny, then users can (theoretically) map the \
\domain\users folder and write stuff to it. That is because the share
permissions override the lack of NTFS permissions, and you *need*
write permissions on the share because otherwise you cannot write to
the share at all. Removing the write permission from the share level
renders all remote writing impossible, even where its allowed by NTFS
as the share permissions are enacted *before* the file ever gets near
the NTFS level.

So to stop users defacing the root of the share (which they are
unlikely to ever see, but users can certainly be inquisitive things at
the best of times) you need to deny them write access to it, but only
at the filesystem level. The folders themselves are not affected by
the deny because they do not inherit the permissions from the parent,
and thus remain unaffected.

Its all about stopping users from writing stuff where they should not,
and keeping them inside well defined boundaries.

Hope that explains it.

Cheers
Richard
 
Re: Share and NTFS permissions - the right mix?!

Richard,

I think this is what you're looking for.
http://support.microsoft.com/kb/274443

Cleve

"Richard Price" <richardprice@gmail.com> wrote in message
news:bb0f4b36-a1b2-49e3-b857-c7543d047fe0@f36g2000hsa.googlegroups.com...
> Hi,
>
> After thinking I had it all nice and sorted, a user goes and does
> something which completely invalidated my prior belief.
>
> My setup is thus:
>
> Windows 2003 R2 server hosting network share \\domain\Users\
>
> Under \\domain\Users are a load of directories - richard, martin,
> jenny, sam et al. They are users private folders, each mapped to
> desktop drive U:\ for the various users when they log into their
> desktops.
>
> What I want to accomplish is thus:
>
> Users can see all directories in \\domain\Users, but they cannot see
> the contents of those directories, delete those directories or add new
> directories.
>
> Users have full control within their own directory under \\domain
> \Users
>
> Can anyone recommend the best mix of Share and NTFS permissions to do
> this? The solution I have ended up with requires the following:
>
> \\domain\Users Share permissions - Everyone: read, write
> \\domain\Users NTFS permissions - Everyone: read, write explicitly
> denied
>
> \\domain\Users\richard - no inherited permissions, richard has Full
> Control within this folder (as does Domain Admin et al)
>
> This has given me basically the situation I want to end up with, with
> one small niggle. It allows richard to access his files perfectly
> fine, create new ones and delete old ones et al within his own
> directory. It allows richard to see all folders in \\domain\Users
> fine, but he cannot access their contents at all. This is exactly how
> I want it to work, so so far so good on that front.
>
> The niggle is that the write explicitly denied at the NTFS level has
> the effect of denying Domain Admins write access also, which means one
> of two things:
>
> 1. I create a Security Group containing everyone but Domain Admins
> (sounds ugly).
> 2. I remove the deny each and every time I want to add a new directory
> or remove an old one (sounds ugly, and also not only Domain Admins
> will be doing this as I want to farm that task out to Account
> Operators).
>
> So, is there any way to accomplish my task without ending up with
> either of the two 'solutions' needing to be implemented?
>
> Is there a better way to do what I am doing?
>
> Cheers
> Richard
 
Re: Share and NTFS permissions - the right mix?!

On May 15, 8:47 pm, "Cleve S." <cle...@SPAMLESStropicalchevrolet.net>
wrote:
> Richard,
>
> I think this is what you're looking for.http://support.microsoft.com/kb/274443
>
> Cleve

Thanks, that looks almost spot on to what I am trying to do (other
than I am creating them all manually etc).

Will try it tomorrow.

Cheers!
Richard
 
Re: Share and NTFS permissions - the right mix?!

Richard Price <richardprice@gmail.com> wrote:
> Hi,
>
> After thinking I had it all nice and sorted, a user goes and does
> something which completely invalidated my prior belief.
>
> My setup is thus:
>
> Windows 2003 R2 server hosting network share \\domain\Users\
>
> Under \\domain\Users are a load of directories - richard, martin,
> jenny, sam et al. They are users private folders, each mapped to
> desktop drive U:\ for the various users when they log into their
> desktops.
>
> What I want to accomplish is thus:
>
> Users can see all directories in \\domain\Users, but they cannot see
> the contents of those directories, delete those directories or add new
> directories.
>
> Users have full control within their own directory under \\domain
> \Users
>
> Can anyone recommend the best mix of Share and NTFS permissions to do
> this? The solution I have ended up with requires the following:
>
> \\domain\Users Share permissions - Everyone: read, write
> \\domain\Users NTFS permissions - Everyone: read, write explicitly
> denied
>
> \\domain\Users\richard - no inherited permissions, richard has Full
> Control within this folder (as does Domain Admin et al)
>
> This has given me basically the situation I want to end up with, with
> one small niggle. It allows richard to access his files perfectly
> fine, create new ones and delete old ones et al within his own
> directory. It allows richard to see all folders in \\domain\Users
> fine, but he cannot access their contents at all. This is exactly how
> I want it to work, so so far so good on that front.
>
> The niggle is that the write explicitly denied at the NTFS level has
> the effect of denying Domain Admins write access also, which means one
> of two things:
>
> 1. I create a Security Group containing everyone but Domain Admins
> (sounds ugly).
> 2. I remove the deny each and every time I want to add a new directory
> or remove an old one (sounds ugly, and also not only Domain Admins
> will be doing this as I want to farm that task out to Account
> Operators).
>
> So, is there any way to accomplish my task without ending up with
> either of the two 'solutions' needing to be implemented?
>
> Is there a better way to do what I am doing?
>
> Cheers
> Richard

For the parent share, everyone=full control is fine.
For the NTFS permissions on the parent folder, check out the following KB
article - it will explain how to make sure your *new* stuff is correct, at
any rate. It won't necessarily help you if the permissions on your existing
folders are squashed.

Note - home directories are a pretty archaic thing at this point - you don't
need them. If you use folder redirection via group policy, you can still map
U: to "\\server\share$\%username%\My Documents" in your login script - but
the KB article should apply to home directories as well. You can use folder
redirection to the home directory, but I don't see the point. If you do use
folder redirection at all, my advice would be to untick the option for
"Grant user exclusive access" and make sure the permissions are correct as
per the following.

(and I like to make the parent share hidden from browsing, e.g., users$)

How to dynamically create security-enhanced redirected folders by using
folder redirection in Windows 2000 and in Windows Server 2003
http://support.microsoft.com/kb/274443

---
SUMMARY
In Microsoft Windows 2000 and in Microsoft Windows Server 2003, as an
administrator, you can customize desktops by using Folder Redirection. You
can redirect the following folders by using Active Directory and Group
Policy:
.. Application Data
.. Desktop
.. My Documents
.. My Documents/My Pictures
.. Start Menu
You can find more information about Folder Redirection by searching Windows
Help for Folder Redirection.

When you redirect folders to a shared location on a network, users need both
read and write access to this location so that the users can read the
contents these folders. However, in some scenarios, you may not want to
grant read access.


= Create security-enhanced redirected folders =

To make sure that only the user and the domain administrators have
permissions to open a particular redirected folder, do the following:

1. Select a central location in your environment where you would like to
store Folder Redirection, and then share this folder. In this example,
FLDREDIR is used.

2. Set Share Permissions for the Everyone group to Full Control.

3. Use the following settings for NTFS Permissions:
. CREATOR OWNER - Full Control (Apply onto: Subfolders and Files Only)
. System - Full Control (Apply onto: This Folder, Subfolders and Files)
. Domain Admins - Full Control (Apply onto: This Folder, Subfolders
and Files)
. Everyone - Create Folder/Append Data (Apply onto: This Folder Only)
. Everyone - List Folder/Read Data (Apply onto: This Folder Only)
. Everyone - Read Attributes (Apply onto: This Folder Only)
. Everyone - Traverse Folder/Execute File (Apply onto: This Folder
Only)

4. Configure Folder Redirection Policy as outlined in Windows Help. Use a
path similar to \\server\FLDREDIR\username to create a folder under the
shared folder, FLDREDIR.

Because the Everyone group has the Create Folder/Append Data right, the
group members have the proper permissions to create the folder; however, the
members are not able to read the data afterwards.

The Username group is the name of the user that was logged on when you
created the folder. Because the folder is a child of the parent folder, it
inherits the permissions that you assigned to FLDREDIR. Also, because the
user is creating the folder, the user gains full control of the folder
because of the Creator Owner Permission setting.


REFERENCES
For additional information, click the article number below to view the
article in the Microsoft Knowledge Base:
232692 (http://support.microsoft.com/kb/232692/EN-US/) Folder Redirection
Feature in Windows
 
Re: Share and NTFS permissions - the right mix?!

Ok, there does not seem to be a clean way to do what I want to do -
the above article (http://support.microsoft.com/kb/274443 ) is
identical to how I originally had the share and folder permissions set
- what I want to do is explicitly deny people write access to the root
of the share, but allow write access to their own subfolders. That
article is based around users being able to create stuff in the root,
which is totally the opposite what I want.

The only way I can see to do it is to set explicit deny on the
container folder, but this also denies Domain Admins - so the only two
solutions I can see is either maintain a security group for 'almost
everyone' and deny those, or have sys admins remove the deny when they
want to change something (which in itself is not a bad thing, as it
limits screw ups).

Hmmm

Richard
 
Re: Share and NTFS permissions - the right mix?!

Richard Price <richardprice@gmail.com> wrote:
> Ok, there does not seem to be a clean way to do what I want to do -
> the above article (http://support.microsoft.com/kb/274443 ) is
> identical to how I originally had the share and folder permissions set
> - what I want to do is explicitly deny people write access to the root
> of the share, but allow write access to their own subfolders. That
> article is based around users being able to create stuff in the root,
> which is totally the opposite what I want.

Have you actually experienced problems with this?
>
> The only way I can see to do it is to set explicit deny on the
> container folder, but this also denies Domain Admins - so the only two
> solutions I can see is either maintain a security group for 'almost
> everyone' and deny those, or have sys admins remove the deny when they
> want to change something (which in itself is not a bad thing, as it
> limits screw ups).
>
> Hmmm
>
> Richard
 
Re: Share and NTFS permissions - the right mix?!


>
> Have you actually experienced problems with this?
>

I am about to migrate from Novell to this solution so the users have
not been exposed to the solution yet, but I know for a fact that I
will experience these issues if I do not solve them now.

Richard
 
Re: Share and NTFS permissions - the right mix?!

Bingo,

I have discovered the right mix of permissions that seem to result in
the exact situation I want:

Locations:
F:\Test (shared as \\domain\Test)
F:\Test\Mike
F:\Test\Richard

Permissions:
\\domain\Test Share Permissions
Everyone: Full Control


F:\Test NTFS Permissions
Advanced -> 'Allow Inherited' unticked, permissions removed
Local Admins: Full Control (This Folder Only)
Domain Admins: Full Control (This Folder, Subfolders and Files)
System: Full Control (This Folder, Subfolders and Files)
Everyone: Special (This Folder Only)
+ Traverse Folder/Execute File
+ List Folder/Read Data
+ Read Attributes
+ Read Extended Attributes
+ Read Permissions


F:\Test\Mike NTFS Permissions
Advanced -> 'Allow Inherited' unticked, permissions removed
Local Admins: Full Control (This Folder Only)
Domain Admins: Full Control (This Folder, Subfolders and Files)
System: Full Control (This Folder, Subfolders and Files)
User 'Mike': Full Control (This Folder, Subfolders and Files)

The above allows users full access to their own folders, read access
to the root folder, no access to anyone elses folder, and still allows
admins to add/remove folders in the root folder.

Sorted.

Cheers all
Richard
 
Re: Share and NTFS permissions - the right mix?!

Richard Price <richardprice@gmail.com> wrote:
>> Have you actually experienced problems with this?
>>
>
> I am about to migrate from Novell to this solution so the users have
> not been exposed to the solution yet, but I know for a fact that I
> will experience these issues if I do not solve them now.
>
> Richard

Except that if you use a hidden share, how will the users ever know it's
there? You don't need to give them a drive letter. All they need to know
about is "My Documents".
 
Re: Share and NTFS permissions - the right mix?!


>
> Except that if you use a hidden share, how will the users ever know it's
> there? You don't need to give them a drive letter. All they need to know
> about is "My Documents".

Because that is a massive change to what they currently have, and
massive changes do not go down well when all done at once.

First I have to ween them off Novell and Zenworks, and that involves
medium disruption in the manner than all their nicely maintained
document shortcuts that they have on their desktop and most recently
used lists break.

Secondly, the users home directories are not the only thing I will be
using this for, and infact they are not the best example of what I am
doing now that I come to think about it. Each business entity has a
'group drive' which acts as a sharing point for everyone in that
business entity. Currently, each department gets their own group
drive on G:\, however this leads to issues when we have the special
case of an individual needing access to another departments group
drive which results in people having special drives mounted on
'nonstandard' (for us) drive letters.

If every departments group drive was infact a folder under a common G:
\ mapping, with access controlled by permissions, then this would
solve the problem of custom logon scripts, meaning we can use a single
standard logon script for everyone and only control access via NTFS
permissions on the file server. A *much* cleaner solution.

I hope that gives a clearer example of the situation I am facing.

I eventually will be going to folder redirection on the desktop and My
Documents, but this has to be a gradual thing, as will the eventual
migration of users filesharing to SharePoint over the next 6 months.
In the end I forsee no need at all for network shares, but I have a
small window of opportunity to get rid of Novell and so the migration
to Windows file sharing must happen first.

And no, in my opinion hidden shares are not a method of implementing
security, its merely security by obscurity - the worst type of
security you can have. Implementing the correct permissions is the
only way to go, otherwise you are just inviting the potential for
breaches.

Hope that helps.

Regards
Richard
 
Re: Share and NTFS permissions - the right mix?!

Richard Price <richardprice@gmail.com> wrote:
>> Except that if you use a hidden share, how will the users ever know
>> it's there? You don't need to give them a drive letter. All they
>> need to know about is "My Documents".
>
> Because that is a massive change to what they currently have, and
> massive changes do not go down well when all done at once.

That depends on your environment, I guess. It may actually be less
disruptive in the long term to get them used to one massive change than to
keep changing things piecemeal. I don't know your user base.
>
> First I have to ween them off Novell and Zenworks, and that involves
> medium disruption in the manner than all their nicely maintained
> document shortcuts that they have on their desktop and most recently
> used lists break.

Yep.
>
> Secondly, the users home directories are not the only thing I will be
> using this for, and infact they are not the best example of what I am
> doing now that I come to think about it. Each business entity has a
> 'group drive' which acts as a sharing point for everyone in that
> business entity. Currently, each department gets their own group
> drive on G:\, however this leads to issues when we have the special
> case of an individual needing access to another departments group
> drive which results in people having special drives mounted on
> 'nonstandard' (for us) drive letters.

Yes, I can see that. I suppose they could use UNC paths . Or depending on
the size of your environment, you might consider not giving every department
the same drive letter/mapping for their own folders -
>
> If every departments group drive was infact a folder under a common G:
> \ mapping, with access controlled by permissions, then this would
> solve the problem of custom logon scripts, meaning we can use a single
> standard logon script for everyone and only control access via NTFS
> permissions on the file server. A *much* cleaner solution.
>
> I hope that gives a clearer example of the situation I am facing.

Yes, and you could definitely implement that - but it's less elegant in that
users would see the folders of the other departments.
>
> I eventually will be going to folder redirection on the desktop and My
> Documents, but this has to be a gradual thing, as will the eventual
> migration of users filesharing to SharePoint over the next 6 months.
> In the end I forsee no need at all for network shares, but I have a
> small window of opportunity to get rid of Novell and so the migration
> to Windows file sharing must happen first.

Sure.

(but I'm not yet putting all my money on Sharepoint as a good document
management system & file server replacement, myself)
>
> And no, in my opinion hidden shares are not a method of implementing
> security, its merely security by obscurity - the worst type of
> security you can have. Implementing the correct permissions is the
> only way to go, otherwise you are just inviting the potential for
> breaches.

I definitely agree that security by obscurity is not a security solution.
It's part of one, though. Users having the (extremely limited) access
granted to the parent folder which they will with this setup, honestly
doesn't worry me overmuch. Have you actually implemented this to see what
your users would end up with?

They would have to go very far out of their way to even find it, let alone
do anything with it,and they couldn't do much of
interest. Your mileage may vary, of course - that's just my view.

As you're no doubt aware, NetWare and Windows are entirely different
animals. I've found that a lot of people migrating from Netware sweat the
small stuff more than I would - it's definitely true there are some things
Windows doesn't do as well, but does well enough. I haven't used Novell
stuff since 4x and don't really find I miss it all that much.

>
> Hope that helps.
>
> Regards
> Richard
 
Re: Share and NTFS permissions - the right mix?!

On May 17, 7:29 pm, "Lanwench [MVP - Exchange]"
<lanwe...@heybuddy.donotsendme.unsolicitedmailatyahoo.com> wrote:

> That depends on your environment, I guess. It may actually be less
> disruptive in the long term to get them used to one massive change than to
> keep changing things piecemeal. I don't know your user base.
>
>

It can be managed better than a full blown huge transition, as you can
later on map their user folders to their My Documents folder with
little issue - get them used to using that and then just remove the U:
mapping.

Baby steps.

> Yes, I can see that. I suppose they could use UNC paths . Or depending on
> the size of your environment, you might consider not giving every department
> the same drive letter/mapping for their own folders -
>
>

Neither of those are very elegant and could be a pain ongoing - you
end up with the requirement for more than one logon script.


>
> Yes, and you could definitely implement that - but it's less elegant in that
> users would see the folders of the other departments.
>
>

You can hide those in Win2k3 R2 using ABE - Access Based Enumeration.
Users only get to see what they have permissions to see.


>
> (but I'm not yet putting all my money on Sharepoint as a good document
> management system & file server replacement, myself)
>

Neither are we, yet - its an ongoing thing.


>
> I definitely agree that security by obscurity is not a security solution.
> It's part of one, though. Users having the (extremely limited) access
> granted to the parent folder which they will with this setup, honestly
> doesn't worry me overmuch. Have you actually implemented this to see what
> your users would end up with?
>

Yes, the implementation I had led me to making the initial post in
this thread. I have since solved my initial problem, and have arrived
at a set of permissions which do precisely what I wished to
accomplish.

> They would have to go very far out of their way  to even find it, let alone
> do anything with it,and they couldn't do  much of
> interest. Your mileage may vary, of course - that's just my view.
>

We have a few 'technical' users in our customer base, and I can
guarantee that they will poke.

> As you're no doubt aware, NetWare and Windows are entirely different
> animals. I've found that a lot of people migrating from Netware sweat the
> small stuff more than I would - it's definitely true there are some things
> Windows doesn't do as well, but does well enough. I haven't used Novell
> stuff since 4x and don't really find I miss it all that much.
>
>

Luckily I am not a Novell person, but its caused us so many problems
its insane - especially since we are still on Novell 5 (I think, might
not even be that), its a setup that definitely needs retiring.

Cheers
Richard
 
Re: Share and NTFS permissions - the right mix?!

Richard Price <richardprice@gmail.com> wrote:
> On May 17, 7:29 pm, "Lanwench [MVP - Exchange]"
> <lanwe...@heybuddy.donotsendme.unsolicitedmailatyahoo.com> wrote:
>
>> That depends on your environment, I guess. It may actually be less
>> disruptive in the long term to get them used to one massive change
>> than to keep changing things piecemeal. I don't know your user base.
>>
>>
>
> It can be managed better than a full blown huge transition, as you can
> later on map their user folders to their My Documents folder with
> little issue - get them used to using that and then just remove the U:
> mapping.
>
> Baby steps.

Sure, that's one option. Again, I don't know your user base.
>
>> Yes, I can see that. I suppose they could use UNC paths . Or
>> depending on the size of your environment, you might consider not
>> giving every department the same drive letter/mapping for their own
>> folders -
>>
>>
>
> Neither of those are very elegant and could be a pain ongoing - you
> end up with the requirement for more than one logon script.

No, you can use a single login script. Even a simple batch file with
ifmember will do it - or there's VBS stuff galore.
>
>
>>
>> Yes, and you could definitely implement that - but it's less elegant
>> in that users would see the folders of the other departments.
>>
>>
>
> You can hide those in Win2k3 R2 using ABE - Access Based Enumeration.
> Users only get to see what they have permissions to see.

Kewl. There's a lot of new stuff in R2 with which I'm still unfamiliar -
good to know.
>
>
>>
>> (but I'm not yet putting all my money on Sharepoint as a good
>> document management system & file server replacement, myself)
>>
>
> Neither are we, yet - its an ongoing thing.
>
>
>>
>> I definitely agree that security by obscurity is not a security
>> solution. It's part of one, though. Users having the (extremely
>> limited) access granted to the parent folder which they will with
>> this setup, honestly doesn't worry me overmuch. Have you actually
>> implemented this to see what your users would end up with?
>>
>
> Yes, the implementation I had led me to making the initial post in
> this thread. I have since solved my initial problem, and have arrived
> at a set of permissions which do precisely what I wished to
> accomplish.
>
>> They would have to go very far out of their way to even find it, let
>> alone do anything with it,and they couldn't do much of
>> interest. Your mileage may vary, of course - that's just my view.
>>
>
> We have a few 'technical' users in our customer base, and I can
> guarantee that they will poke.

;-)
>
>> As you're no doubt aware, NetWare and Windows are entirely different
>> animals. I've found that a lot of people migrating from Netware
>> sweat the small stuff more than I would - it's definitely true there
>> are some things Windows doesn't do as well, but does well enough. I
>> haven't used Novell stuff since 4x and don't really find I miss it
>> all that much.
>>
>>
>
> Luckily I am not a Novell person, but its caused us so many problems
> its insane - especially since we are still on Novell 5 (I think, might
> not even be that), its a setup that definitely needs retiring.

I wish you the best of luck - and am glad you figured out the permissions
you needed to make this work as you wish.
>
> Cheers
> Richard
 
Re: Share and NTFS permissions - the right mix?!


>
> No, you can use a single login script. Even a simple batch file with
> ifmember will do it - or there's VBS stuff galore.
>

The downside to that is you have to maintain a *lot* of groups -
something we again really do not want to do. I have written a
Powershell script which lists users file share permissions, and can
also remove them en masse if told to do so. This way, AD is kept nice
and clean.


> I wish you the best of luck - and am glad you figured out the permissions
> you needed to make this work as you wish.
>

Thanks for the input, its been thought provoking!

Cheers
Richard
 
Back
Top