2K3 User question

[hons]

I'm a Domain Admin in the network, I want to add the "Domain\Users" into the "Power Users" group in the local computers. Is there any way I can add in on the server instead of going to each loacl machine???

Thanks.

[neo]

right click on My Computer goto Manage

in Computer Management->Local Users and Groups

U can create User and by clicking on user's a/c add to domain by navigating to Member of tab

[jondercik]

You can do this with group policy. Look up resticted groups.

[hons]

Thanks guys,

The reason that I need to add the users onto the local computer is because I want the users be able to run the update of the program by themselves. Right now the domain users don't have the right to install programs.

I want to do it at the simplest way, I don't want to go to each computer to add the user.

Could anybody help on this?? If we can do it through GP, what are the steps???

Thanks again.

[allen2]

Jondercik told you the solution. You can do it with a domain group policy using the restricted groups.

[nmX.Memnoch]

The reason that I need to add the users onto the local computer is because I want the users be able to run the update of the program by themselves. Right now the domain users don't have the right to install programs.

I want to do it at the simplest way, I don't want to go to each computer to add the user.

Just so you know, you're sacrificing A LOT of security just to make things a bit easier. If you have a lot of users and want to do it correctly you should look into SMS.

Could anybody help on this?? If we can do it through GP, what are the steps???

First of all, I recommend downloading the Group Policy Management Console w/ SP1. It'll make managing Group Policy Objects (GPOs) much easier. Once you've downloaded it install it on the DC(s) (you can also install it on a workstation if you choose to manage your GPOs remotely).

Now open the console (Admin Tools > Group Policy Management) and navigate to Group Policy Management > Forest: [your.forest.name] > Domains > [your.domain.name] > Group Policy Objects. This will show you all of the currently available GPOs. By default you should have Default Domain Controllers Policy and Default Domain Policy. I recommend leaving these alone and creating new GPOs for each item that you want to force settings for. This way if you create a GPO that cause problems you can disable just that GPO without disabling all policies.

Right click on Group Policy Objects and select New. Name it something recognizeable like Workstations Restricted Groups. Once you've done that right click on the new GPO and select Edit. For this particular GPO you want to go to [GPO Name] > Computer Configuration > Windows Settings > Security Settings > Restricted Groups.

Right click on Restricted Groups and select Add Group. Type the name of the group (Power Users). On the next screen it'll give you the option of which users should be members of this group and which groups this group should be a member of. Under Members of this group click on Add and enter Domain Users, then click OK. You can now close the Group Policy edit window so that you're back at the Group Policy Management window.

Since you're only using machine settings in this particular GPO you should disable the user settings. This can be done by right clicking on the GPO, selecting GPO Status and then selecting User Configuration Settings Disabled.

After you've done this you need to link the GPO to the OUs that you want to apply it to. You want this to apply to your workstations so in the Group Policy Management console right click on the OU that contains your workstation computer accounts and select Link an Existing GPO. Select the GPO you just created. Once it's linked I always select to Enforce the GPO. To do that right click on the GPO link under the OU and select Enforced.

GPOs can be very powerful. You should do some research before applying anymore settings though. Even though you're giving all of your users Power User access, you can still restrict certain areas of the workstation using GPOs. The NSA website has some good documentation on securing workstations using Group Policies. If you use this just keep in mind that it's a guideline. Some of the settings can cause problems if improperly configured or used with older applications.

http://www.nsa.gov/snac/downloads_winxp.cf...uID=scg10.3.1.1

[hons]

Thanks to nmX.Memnoch and other members' help.

nmX.Memnoch,

I understand that there is a high security risk to add the users to the power users group. Is there any other way that I can do the simlier work??

What I want to do is -

we have a application that need to be updated to a newer version and the update file needed to be downloaded from another company and run with admin right. I can logon to the local machine as admin and run the update but we have several hundred PCs!!! SMS is a good option but we don't update applications so often (maybe once a year) so we don't have plan to purchase it.

Thanks for your help again and awaiting for your reply.

[cluberti]

You could always try running the update in a machine logon script, as those run as the local SYSTEM account (you wouldn't necessarily have network access, so the install file would need to be local, but the script would definitely have rights as the SYSTEM account). It's worth a try in a test environment .

[nmX.Memnoch]

What about putting the update file in the same directory as the script? Would the script have access to copy it to the local workstation that way?

[fizban2]

if you can script the installation to run with elevated access (ie runas with admin account or an account that had admin rights on the box) would that complete the update correctly? test it once. setup a machine and run the update by right clicking on it and doing a runas, use credentials that would have admin rights on the machine and see if the update would run successfully

[nmX.Memnoch]

The only downside to that is that you would then have a script containing a clear text password of a user with admin privs on the workstations.

[hons]

Sorry for the late reply and thanks for the suggestions, I will try and post the result.

Thanks again.

[fizban2]

The only downside to that is that you would then have a script containing a clear text password of a user with admin privs on the workstations.

true true, just don't let anyone at the scripts or use a account that is locked down.

[cluberti]

Well, you can solve it somewhat by running your vbscripts through a script obfuscator, or use COM automation to hide the password.