• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 471
  • Last Modified:

Domain users cannot access remote computers

Hi, I have a slight problem with my active directory network.

When a Domain Admin logs in they can do: \\<computer name>  and view any shares.
however when a Domain User does the same, the error message 'access to the resource: <computer name> has been denied'
the admins can do: \\compname   \\IPofcomp  \\compname\share  and  \\IPofcomp\share
but users cannot do any of those.
the default admin share (C$) is accessable to admins, but again users cannot connect to it.

we have a fileserver called 'fileserver'
the logon scripts work fine for all users (the shares appear and are accessable), now while the users cannot type: \\fileserver\share in explorer, they can make more shares and view shares in computers using the comand prompt (ie. net use \\fileserver\share  and net view /NETWORK: \\filserver).

I have checked the 'security' and 'share' permissions to make sure everyone has read permissions under both  

there isnt a security group that I can find (DaGo21's answer to my previous question (link below)).

some of the solutions I have tried are:

> Changing permissions in the group policies (which badly screwed up the network so I had to create a new PDC).
> Creating shared folder with 'everyone' having permission to read and then trying to get a user to view.
> my previous question: http://www.experts-exchange.com/Networking/Q_21355815.html
> I have tried adding users to 'access this computer from network' as suggested by this link: http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B823659

NOTE: the PDC is running windows 2003 standard edition

and these have not worked.

Thanks for your help


  • 5
  • 4
  • 2
  • +1
1 Solution
Chris DentPowerShell DeveloperCommented:

Are your clients Windows XP? If so can you run the Resultant Set of Policy tool (Start, Run, rsop.msc).

Because you are having problems with typed in paths you might want to check for the policy "Remove Run from Start Menu" as this blocks access to the ability to type UNC Paths on the client.

Policy Location: User Configuration / Administrative Templates / Start Menu and Taskbar

The error message you get doesn't quite fit for this situation (would expect something along the lines of "The Local Policy of this system... ") but it's certainly worth a try.

Beyond that, are you seeing any errors appearing in any of the event logs (server or client) when you try and browse?

Have you checked advanced security permissions for any "deny" statements?
dr_binksAuthor Commented:
> Are your clients Windows XP? If so can you run the Resultant Set of Policy tool (Start, Run, rsop.msc).

thanks I didnt know how to view what policy optins had been set, but now I can :D
I noticed the 'access this computer from network' policy settign is beign applied.

> Because you are having problems with typed in paths you might want to check for the policy "Remove Run from Start Menu" as this blocks access to the ability to type UNC Paths on the client.

Domain users automatically have their 'run' removed (I think... unless I set somthing several months agowhich stopped them). None of the users have run in the start menu anyway.

> Beyond that, are you seeing any errors appearing in any of the event logs (server or client) when you try and browse?

I havent seen any errors.
Evaluating UTMs? Here's what you need to know!

Evaluating a UTM appliance and vendor can prove to be an overwhelming exercise.  How can you make sure that you're getting the security that your organization needs without breaking the bank? Check out our UTM Buyer's Guide for more information on what you should be looking for!

Firstly, the default admin share (C$) is only accessible to admins anyway, so normal users would not be able to view this. Secondly check the share tab on the share and ensure everyone has necessary permissions on this. Then go to the security tab and add the group Domain Users to the list and make sure it has necessary permissions. Then check that the machines are correctly joined to the domain. Your last question post says that you replaced the domain controller. When you did this did you REJOIN all the users to the domain? Even if you called the domain the same as it was the last time, and the server the same as the last time as well, the users would still not have access as changing the domain controller would mean that they would all need to be reissued new SIDs (Security Identifiers). Without these you would receive many security errors due to the fact that access to the domain controller/file server is controlled by SIDs.

To rejoin the machines to the domain you would first have to have removed them from the previous domain by changing them back to a workgroup and then rejoining them to the domain in the same way as you normally would.

Hope this helps,

Chris DentPowerShell DeveloperCommented:

The Run command cannot be removed if you still want UNC paths available. This is the Explain text for the policy concerned:

Allows you to remove the Run command from the Start menu, Internet Explorer, and Task Manager.

If you enable this setting, the following changes occur:
(1) The Run command is removed from the Start menu.
(2) The New Task (Run) command is removed from Task Manager.
** (3) The user will be blocked from entering the following into the Internet Explorer Address Bar: **
** --- A UNC path: \\<server>\<share> **
---Accessing local drives:  e.g., C:
--- Accessing local folders: e.g., \temp>
dr_binksAuthor Commented:
all of the users and computers have been rejoined, the domain name is totally diferent to the last one, so I started fresh.
Chris DentPowerShell DeveloperCommented:

As a note, Internet Explorer Address Bar includes the Windows Explorer address bar - although it isn't quite so clear on that one.
Have you checked the security settings for Domain Users as I suggested?
dr_binksAuthor Commented:
OMFG, Chris-Dent .. I would send you flowers if I could. ;)  that solved my problem 100%.

originally I thought that domain users could view remote computers.. and thats life.
but I noticed that my university let users view remote computers.. so I thought id try and find out how to do it on the network at work.
I never once thought that i'd have to enable the run command.

thanks so much.

one last question, isnt that kindda bad.. security wise.. letting users have access to 'run'?

thanks again.
Chris DentPowerShell DeveloperCommented:

It is to an extent, it depends slightly on the permissions the user has on the system and if there's anything you don't want them to do or see - most things can be tied down with (relatively) simple NTFS permissions.

Unfortunately the Run box itself is one of the harder ones to get rid of. Allowing UNC paths to be typed into the address bar is pretty much the same as having the run box enabled, so that functionality disapears alongside it. Fine if you can statically assign all network access required via network drives, but...

Still, if you really want to lock a machine down though it is a useful policy. Of course it requires others set in conjunction to really work. Things like Remove / Prevent access to local drives, and removal of any network browsing capability in the end you can turn a PC into an expensive dumb terminal with a network drive or two for them to see what you want them to.

Of course it's not really so simple, you need to shut the other smaller doors to the system too. You have to remove Right Click so they can't get the Find Target option on a shortcut or access to the Windows Explorer menu item. Right Click context menus also have to go so that yet another method to open explorer disapears. The list goes on and on.
dr_binksAuthor Commented:
well no one has access to the local drives so thats ok.

because the company I work for is very small I onyl have 2 security groups: 'employees' and 'volunteers'
naturally I have onyl allowed the 'run' to be enabled for employees as they are bound to be more trust worthy (they have complete access to all the shares on the fileserver anyway).
Chris DentPowerShell DeveloperCommented:

Understandable. It's certainly a nice one to get rid of, but it depends so much on the environment as to whether you can or not.

Well at least it's all working how it should :)

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 5
  • 4
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now