View Single Post
  #4  
Old February 21st 08, 11:28 PM posted to microsoft.public.windowsxp.security_admin
Lanwench [MVP - Exchange]
external usenet poster
 
Posts: 1,547
Default xp pro, granting domain user access to local resources?

geek-y-guy wrote:
Thanks for the quick reply. This is an older Plustek scanner and I
don't expect the manufacturer will provide any updates for it.


OK - that's the hardware. Do you have to use that *software* for it?

And
yes, the default user account locally has Admin rights, so you
probably nailed it.


You can test this by adding the domain user to the local Administrators
group....

I don't have any issues granting the domain user admin rights on the
workstation, unless it opens up other vulnerabilities beyond them
breaking something g.


Ain't that enough for you? Malware infestation can take a long long time to
clean up, as well as cause problems on the network. :-)

Short of that, what would I need to manually edit to grant access? do
you mean granting the domain user appropriate access to specific
folders they'd normally not have access to?


Yep - and registry keys. Do check out the Sysinternals tool. It's a good
thing to know how to use. Log in as the non-admin user, then launch the
Sysinternals tool using RunAs & providing valid local admin credentials.
Play with it a bit.

Thanks again!


"Lanwench [MVP - Exchange]"
hoo.com wrote in
message ...
geek-y-guy wrote:
Hi All: I have an SBS2003 domain with a number of xppro sp2 clients.
All the computers are members of the domain, and I've set up domain
users for each computer.

I have a USB scanner installed on one computer, and when a user logs
on to the local machine, they can access the scanner, but if they
log on using the domain account, they get an error when the scanner
application tries to load the (presumably) USB drivers for the
scanner.
It seems like a local security policy issue, but I can't figure out
what privileges the domain user needs to have the same access the
local account has?


If the scanner is installed already, this is unlikely to be a driver
issue. More likely, the software you're using is expecting the user
to have administrative rights on the workstation in order to run the
app. First, I'd contact the software developer and ask for a workaround
which does *not* involve granting domain users admin rights - this
is sloppy code, and they need to fix it.

If you get nowhere with them, try downloading Process Monitor from
Microsoft (a cool Sysinternals tool) that will help you find out what
areas of the file system & registry the app expects to write to, so
you can manually edit/correct it.




Ads