XP Security Question

Hi,

I'm new here and could use some help. Here's the situation:

XP Pro Workgroup situation.
Share permissions set to "full control" for "everybody "
Want to use NTFS permissions to restrict access locally and over the network.

Locally, it allows access to the right users, denies to others. All good here.

Over the network, it allows access for folders that have "full control" for "everybody ". Everyone can get to the unsecured shares from other computers on the network. All good here.

Here's the problem. I can't get to the secured shares over the network. I have the NTFS permissions set to "full control" for several individual users, but that only seems to give them access on the local machine, not over the network. I have already created user accounts with the same names on each network machine.

The problem is, when I go to select users in the NTFS permissions dialog box, it doesn't pull up any computers on the network except the local machine.

So:

1: Is there a way to get it to pull up other computers in the "location" portion of the dialog box?

2: Or is it enough to have the same network user name set up on the local machine...which means I'm missing something else?

I hope I've articulated the problem well enough. Your help is much appreciated.

Thanks,

g.

 

Unless you are going to have problems with the NT workstation limitation of maximum 10 simultaneous users connected at any one time, try this.

ComputerA has each user's logon account/password set up as a local user.

UserB on ComputerB needs access to shareA on ComputerA but you need control.

- On ComputerA, set the UserB account to have the share access you want.

- On ComputerB, map a drive to shareA but set to "connect using a different user name" and in the block for user name,
\\ComputerA\UserB and the password.

This has the user on ComputerB connected to the share but using the copy of his/her account on ComputerA for permissions.

 

Thanks for the help. Don't know if this is a workaround or the normal way of doing things, but...

I tried it and it wouldn't let me connect as that user (UserB on Computer A). It said the problem was the drive was already "connected" and suggested disconnecting.

I disconnected the drive, then couldn't even find it in My Network Places. I then tried to map the drive using the suggested method above and it worked.

But I haven't checked to see if the permissions have taken yet.

Will do that now...

Thanks for the help.

 

Both a workaround and normal - at least for me.

In a peer network (as opposed to one with a domain controller to vaildate users) it is the most reliable way I've found to do the deed.

Even on a domain network, if your current logon doesn't have the needed permissions for a specific system, this works nicely.

You are supposed to be able to just load the user account information about userB onto computerA and then when userB is logged on to ComputerB, he can map/connect just fine. But it doesn't always seem to work right for me at home while the method I described does.

The error you got is normal. If you have a connection to ComputerA from ComputerB, you won't be allowed to make a new one using different credentials without first closing the existing one.

Example: at work I log on as user us\vailn (domain\username), a normal domain user. On my personal PC, that account is in the local administrators group so I have full access. Otherwise, I only have user access when connecting to another system.

Our main file server is CABFS1. Everyone has a personal share on it and has admin rights to that share. User rights or no rights to other folders.

However, I need admin rights to all our servers for doing various checks and fix-it stuff. I use an app called Hyena for this and in Hyena, I highlight all the servers except CABFS1 and connect as pmu_cab\nvadmin, a domain admin account. But if I tried to include CABFS1 I'd get that error because I already have a connection as us\vailn to my personal share. So I had to add us\vailn to the local admin group on CABFS1.

 

Makes sense. If I can't make a new connection (because it clashes with the other, low-security connections I'm making) then it appears that I should be consistent and use your method for both the low-security and the high-security connections. Then I'll map all shares to drives the way I do with the high-security connection.

I'll give it a try this weekend and report.

Once again, thanks for the help. Don't know where else I would've found it. (They don't teach you that in law school).