How do I solve this Windows File Share problem?
February 3, 2010 6:07 PM Subscribe
Why do I keep getting "Enter network password" when adding users to a remote share in a Workgroup in Windows XP Pro?
Here's the setup:
- All computers running XP PRO SP3, NTFS file system
- All computers part of a workgroup called "WORKGROUP" (No Domain)
- One machine (XP PRO SP3, NTFS) acting as file server
- ALL computers have simple file sharing turned OFF
- All users and passwords are EXACTLY the same on each machine
- All computers are on the same router and same subnet
- I have tried rebooting each machine in question and the router to no avail.
- Everything EXCEPT this problem works fine on my network
Here's what I try to do (I've changed account names to simplify):
1. I Log into a Computer named "computer" as "Admin" (where admin is an account in the Administrators group on each machine)
2. From "computer", I browse to a share on a remote computer named "server". The share is called "shared" and everyone in the Users group has Modify access (Administrators have Full Control)
3. I go to a subfolder within "shared" called "restricted" and go to Properties -> Security
4. I notice that I (user "admin") have, correctly, Full Control access to the folder. Now, I want to add a user named "Bob" to this shared folder named "restricted" so he can have access to it.
5. I click "Add"
6. The "Select Users or Groups" dialogue comes up. The "From this location" box correctly shows the location I'm trying to select from as "server".
7. I type "Bob" in the "Enter the object names to select" box (note, too, that Bob ALREADY exists on "server" as a user and has the same password on both machines and, yes, has logged in at least once on each machine)
8. When I click OK, I am prompted with "Enter Network Password" dialogue. This is bizarre: why am I being prompted for a password when my account (admin) already exists on the target "server"?
9. I type in my user name and password anyway ("admin").
10. I get the "Name not found" dialogue box. Why? The user "bob" exists on "server" so it should be found.
11. Trying a different approach, I go back to the "Select Users or Groups" dialogue box and click "Advanced" and then "Find Now" to hopefully list all of the accounts on the remote "server".
12. The list that is returned does not include a single user! Only built-in user groups are returned in the list.
13. If logged onto the server itself, even through Remote Desktop, this problem does not occur. It only happens when I try to add users to an existing share from another computer. Also, the file shares work otherwise perfectly: the permissions set on each share and folder work perfectly and deny or permit access as defined. Only adding users to a share is screwed up.
14. One final note: I created a share on a different computer called "test". I tried to perform the same functions and got the same problematic result! Is this just something with XP Pro where you are not allowed to search remote accounts? I could've sworn I was able to do this in the past...
What is going on? Why am I unable to view remote objects on the server? Is this a limitation of Windows XP Professional or is there some security setting somewhere that is messed up? I'm going nuts trying to figure this out and even though my Google-fu is powerful, I could find no one else complaining of this same problem.
Help me, please!
Here's the setup:
- All computers running XP PRO SP3, NTFS file system
- All computers part of a workgroup called "WORKGROUP" (No Domain)
- One machine (XP PRO SP3, NTFS) acting as file server
- ALL computers have simple file sharing turned OFF
- All users and passwords are EXACTLY the same on each machine
- All computers are on the same router and same subnet
- I have tried rebooting each machine in question and the router to no avail.
- Everything EXCEPT this problem works fine on my network
Here's what I try to do (I've changed account names to simplify):
1. I Log into a Computer named "computer" as "Admin" (where admin is an account in the Administrators group on each machine)
2. From "computer", I browse to a share on a remote computer named "server". The share is called "shared" and everyone in the Users group has Modify access (Administrators have Full Control)
3. I go to a subfolder within "shared" called "restricted" and go to Properties -> Security
4. I notice that I (user "admin") have, correctly, Full Control access to the folder. Now, I want to add a user named "Bob" to this shared folder named "restricted" so he can have access to it.
5. I click "Add"
6. The "Select Users or Groups" dialogue comes up. The "From this location" box correctly shows the location I'm trying to select from as "server".
7. I type "Bob" in the "Enter the object names to select" box (note, too, that Bob ALREADY exists on "server" as a user and has the same password on both machines and, yes, has logged in at least once on each machine)
8. When I click OK, I am prompted with "Enter Network Password" dialogue. This is bizarre: why am I being prompted for a password when my account (admin) already exists on the target "server"?
9. I type in my user name and password anyway ("admin").
10. I get the "Name not found" dialogue box. Why? The user "bob" exists on "server" so it should be found.
11. Trying a different approach, I go back to the "Select Users or Groups" dialogue box and click "Advanced" and then "Find Now" to hopefully list all of the accounts on the remote "server".
12. The list that is returned does not include a single user! Only built-in user groups are returned in the list.
13. If logged onto the server itself, even through Remote Desktop, this problem does not occur. It only happens when I try to add users to an existing share from another computer. Also, the file shares work otherwise perfectly: the permissions set on each share and folder work perfectly and deny or permit access as defined. Only adding users to a share is screwed up.
14. One final note: I created a share on a different computer called "test". I tried to perform the same functions and got the same problematic result! Is this just something with XP Pro where you are not allowed to search remote accounts? I could've sworn I was able to do this in the past...
What is going on? Why am I unable to view remote objects on the server? Is this a limitation of Windows XP Professional or is there some security setting somewhere that is messed up? I'm going nuts trying to figure this out and even though my Google-fu is powerful, I could find no one else complaining of this same problem.
Help me, please!
Or, you could try an ugly hack: use NewSID to give all your workstations the same machine SID as the server, then make sure you set up your server and workstation accounts in the same order so that they all get matching relative IDs (a Windows RID is pretty much the same as a Unix UID). That will mean that Admin on your workstation ends up with the same SID as Admin on the server, and will be able to do stuff like mess with permissions.
This is so the wrong way to do it, though.
posted by flabdablet at 6:39 PM on February 3, 2010 [1 favorite]
This is so the wrong way to do it, though.
posted by flabdablet at 6:39 PM on February 3, 2010 [1 favorite]
Best answer: the Bob on system X and the Bob on server Y aren't the same account. they have different SIDs. Windows actually uses this to identify the account (or object, etc. - computers, etc. have SIDs too), and it's really sending the SID of your local computer's Administrator account when you're asked to logged in (which doesn't work - your server really doesn't know about accounts on other computers). you need to log in (in step 8) as the account on the server: do it as SERVERNAME\Administrator instead. this will tell Windows to use the Administrator account on SERVERNAME.
technically, you may have been able to do this before - SIDs are a Windows NT/Active Directory sort of thing, so if you haven't done this since the Win98/ME days, this is a new thing. this also works fine on a domain, as your account names on an Active Directory domain have the domain's identifier in the SID rather than any local computer's.
posted by mrg at 6:46 PM on February 3, 2010
technically, you may have been able to do this before - SIDs are a Windows NT/Active Directory sort of thing, so if you haven't done this since the Win98/ME days, this is a new thing. this also works fine on a domain, as your account names on an Active Directory domain have the domain's identifier in the SID rather than any local computer's.
posted by mrg at 6:46 PM on February 3, 2010
...aaaand I've just found out that not only has NewSID now been retired, but that I have fundamentally misunderstood the security model for remote shares. Any time something I say about Windows contradicts something Russinovich says, believe Russinovich.
posted by flabdablet at 6:53 PM on February 3, 2010 [1 favorite]
posted by flabdablet at 6:53 PM on February 3, 2010 [1 favorite]
Nice to see that mrg had the same wrong idea about the shipping around of SIDs as I did; I feel like less of an idiot now. But both mrg and odinsdream have the SERVERNAME\USERNAME format for remote logons exactly right. Use that.
posted by flabdablet at 6:55 PM on February 3, 2010
posted by flabdablet at 6:55 PM on February 3, 2010
Further perusal of the comments on that SID-related blog entry show that the deeply unsound method I outlined above would probably actually work and, conveniently, would not require corresponding user accounts on all workstations to keep their passwords in sync. It would, however, require that the admin password be changed on all workstations every time it needed changing at all.
posted by flabdablet at 3:56 PM on February 4, 2010
posted by flabdablet at 3:56 PM on February 4, 2010
This thread is closed to new comments.
Your account doesn't exist on the target. Windows account IDs (security IDs or SIDs) are globally unique by design. The fact that your account has the same login name and password as another account on the server only helps sometimes. Looks like you've run into one of the cases where it doesn't.
Windows domains get around this by making the domain controller the ultimate arbiter for account authentication, then using SIDs created on the domain controller for everything.
If you're not willing to set up a Windows domain (either by paying Microsoft's licence fees, or using Linux and Samba) then I think your least-cost option is indeed going to involve using remote access to your file server to mess with permissions rather than attempting to do so on workstations via the shares.
posted by flabdablet at 6:35 PM on February 3, 2010 [1 favorite]