Local Users vs. AD Groups

We have a WS2003 AD domain. Our client computers are running XP.
We have configured AD accounts for domain users (set to the Domain users group). We also have an administrator account (for local computer and for AD).

We installed a piece of software using the local computer administrator account, but the software will not be available when the AD domain users log on into the computer.

Can anybody help?

 

Maybe.

An easy 'fix' that may work is to add Everyone to the application folders security with read/write/modify rights. This will do the job for you unless there are critical files located elsewhere.

If it doesn't work, there are a few other things to try.

Most newer apps that are written for NT systems offer an option at install time to allow just the installing user or to make it available to all users. However, I don't know any good way to open it to all users once the app is installed other than by removing it and reloading.

 

I'd suggest using the "Domain Users" group rather than the "Everyone" group as a more secure option. That will ensure that users are logged on properly before they can use the application.

However, I agree with Newt's second point, this sounds like a restriction of the program rather than the system. It appears that the software is set to run only for the user account that installed it, or perhaps only accounts that have local admin rights. I'd suggest going to the tech support for the application developers for help with this.

 

Good point Reggie.

 

Hi there.

Perhaps a better solution would be to add the Domain Users group to the local Administrators group on the XP machines. Then install the software while being logged in as the person who will be using the software.

Once the installation and configuration is complete, you can remove Domain Users from the local Administrators group and see if you program is going to work for you.

As you may already know, a lot of software out there only runs for users with local Admin or Power User rights. By default, Domain Users only have User access to local machines...this may not be enough to run your program....if it is not then generally granting read/write access to Domain Users on c:\program files\<program name> and/or c:\windows\temp and/or part of the registry will usually work.

There are ways to audit what a program is trying to access so you can pinpoint the kind of access you need to give Domain Users. Filemon is execellent in that regard: http://www.sysinternals.com/Utilities/Filemon.html

Good Luck

 

Am I tempted to set "Domain Users" as members of the local "Administrators" group? Absolutely tempted.

Do I do it? No. I think it is bad practice. It would make my life a lot easier (especially if you set it in the logon script), but would make it even easier for trojans etc.

I would suggest that the best thing is to try to sort out the problem with this app first and only use the sledge hammer approach if stuck or you need to be expedient.

I wish Windows acted like Linux for this sort of thing. In Linux, if you need admin rights to do something you are prompted to enter admin credentials before being allowed to carry on the task. You don't have to log off and back on as an administrator or elevate the user's rights.

Of course this leads to the option of using the runas windows system in the same way as you would use su in Linux. Enter "runas" in windows help to get information on how to use it. Personally, I'd create a service account with necessary admin rights. Then log on with those account credentials. Install the software and then log back on as the user. Then use runas to run the application as the service account user.

 

And by the way - you can use runas in a shortcut. So as long as the user uses the shortcut they probably won't realise they are using it as another user; perhaps just find it odd that the are prompted for a password when they run the app.