User able to create folders on network drive he had no permission

[Greg]

Hi all,

We have had a strange case where a user who has just had a new PC setup for
him on the network was able to create files and folders on a network drive he
should only have had read access to.

The PC was setup using a domain admin account (I know, probably not the best
idea but thats not the point). The user called me to ask if it was ok for him
to create a folder on the network drive and for me to assign permissions to
specific groups. I watched as he created the folder and renamed it. Neither
of which he had permissions to do according to NTFS permissions. Checking the
effective permissions tab on the folder still said he didnt have access to
create it. Whats more, logging in as his account I could browse to other
users personal share and do whatever I liked on them. I tested his account on
another machine and he got access denied to the folders I was using to test,
so it was something specific to the new PC.

We removed all permissions to the folder we were testing with except domain
admins, and with his account on the effected PC he was still able to create
folders etc. Removing all permissions including domain admins and replacing
with another group gave access denied.

To fix the problem I copied his profile on the machine to another users
profile and deleted it, logged back in again as him then copied the profile
back. This gave him the proper permissions to the network drive, eg access
denied when trying to create files etc.

It seems as if one of the pieces of software (perhaps installed as the
domain admin user) was somehow impersonating the domain admin who first set
it up. Which piece of software I dont know, like I say the problem went away
as soon as I removed and replaced his profile.

Has anyone seen anything like this before?

Thanks,
Greg

 

[Lanwench [MVP - Exchange]]

Hi all,

We have had a strange case where a user who has just had a new PC
setup for him on the network was able to create files and folders on
a network drive he should only have had read access to.

The PC was setup using a domain admin account (I know, probably not
the best idea but thats not the point).

What does "set up" mean? If you joined the domain, installed software as an
admin (domain or otherwise), it wouldn't make any difference with the *user*
permissions on the network.

The user called me to ask if

it was ok for him to create a folder on the network drive and for me
to assign permissions to specific groups. I watched as he created the
folder and renamed it. Neither of which he had permissions to do
according to NTFS permissions. Checking the effective permissions tab
on the folder still said he didnt have access to create it. Whats
more, logging in as his account I could browse to other users
personal share and do whatever I liked on them. I tested his account
on another machine and he got access denied to the folders I was
using to test, so it was something specific to the new PC.

We removed all permissions to the folder we were testing with except
domain admins, and with his account on the effected PC he was still
able to create folders etc. Removing all permissions including domain
admins and replacing with another group gave access denied.

To fix the problem I copied his profile on the machine to another
users profile and deleted it, logged back in again as him then copied
the profile back. This gave him the proper permissions to the network
drive, eg access denied when trying to create files etc.

It seems as if one of the pieces of software (perhaps installed as the
domain admin user) was somehow impersonating the domain admin who
first set it up. Which piece of software I dont know, like I say the
problem went away as soon as I removed and replaced his profile.

Has anyone seen anything like this before?

Thanks,
Greg

There's no way your having installed software as User X would affect User
Y's network permissions. However, if you had perhaps connected to a network
share as an administrator *while* the user was logged in under his own
account, he would be
connected to that shared resource using the administrator's credentials and
could do whatever he liked. That's all I can think of.

In your login script, presuming you use a batch file, I'd do something like
this:

net use * /del
net use x: \\server\share /persistent:no
net use y: \\server\share /persistent: no

 

[Greg]

What does "set up" mean? If you joined the domain, installed software as an
admin (domain or otherwise), it wouldn't make any difference with the *user*
permissions on the network.

By setup I mean after OS install, most of the apps the user will use are
installed as an admin user.

The user called me to ask if

There's no way your having installed software as User X would affect User
Y's network permissions. However, if you had perhaps connected to a network
share as an administrator *while* the user was logged in under his own
account, he would be
connected to that shared resource using the administrator's credentials and
could do whatever he liked. That's all I can think of.

In your login script, presuming you use a batch file, I'd do something like
this:

net use * /del
net use x: \\server\share /persistent:no
net use y: \\server\share /persistent: no

Hmm, maybe but I didnt map the drive while he was logged in and the problem
persisted through multiple reboots, our login scripts are pretty similar to
your example so I cant see how, especially after rebooting, it could have
remapped the drive as the admin user without asking for the password again??

Greg

 

[Lanwench [MVP - Exchange]]

By setup I mean after OS install, most of the apps the user will use
are installed as an admin user.

OK - that's exactly as it should be.

Hmm, maybe but I didnt map the drive while he was logged in and the
problem persisted through multiple reboots,
Bizarre.

our login scripts are
pretty similar to your example so I cant see how, especially after
rebooting, it could have remapped the drive as the admin user without
asking for the password again??

It shouldn't have happened, I agree. However, there's nothing else to
explain it. You might want to double check your permissions - have someone
else bring a fresh pair of eyes over!