dr_binks
asked on
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: https://www.experts-exchange.com/questions/21355815/Domain-Users-cannot-view-shares-computers.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
~dr_binks
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: https://www.experts-exchange.com/questions/21355815/Domain-Users-cannot-view-shares-computers.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
~dr_binks
Have you checked advanced security permissions for any "deny" statements?
ASKER
> 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.
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.
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,
Barry
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,
Barry
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
all of the users and computers have been rejoined, the domain name is totally diferent to the last one, so I started fresh.
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?
ASKER
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.
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.
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.
ASKER
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).
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).
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 :)
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?