GPO and Printers

pts.
Tags:
Desktops
Management
Microsoft Windows
OS
Security
Servers
SQL Server
ok folks, here's a tricky one. i have a win2003 AD and need to modify GP so that users of my "printers" group are allowed to install a local printer. how is this done? thanks

Answer Wiki

Thanks. We'll let you know when a new response is added.

I don’t know that one, and never realised i did need to know, but now i’ve seen your question i have, so i’ll be checking back!

Discuss This Question: 1  Reply

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Dcaine
    This has really been bugging me so I opened a case with MS support via email. they gave me two options: the first was to add the local users to the local administrators group via GP. NO WAY. Here's the second suggestion that may work, but I have not had time to deploy it in my test environment. It's reporduced here direct from the MS Tech: Method 2: This solution is more complex than the first one. However, it ONLY allows the normal user accounts to work as Administrator when they are trying to add the printer. You can refer the steps listed in the "Method 2" to achieve that. SUGGESTION: ===================================== Method 1: On one of your Windows 2003-based Domain Controllers: (1) In the console of the Group Policy, which will be applied on the desired client computers (Not Users.): (2) Locate the path below in the left pane: Computer Configuration Windows Settings Security Settings Restricted Groups (3) Right Click "Restricted Groups" -> Add Groups? -> Type: Administrator -> Click OK. (4) In the top box "Members of this group" -> Click Add -> You can add the groups, whose members are wanted to add the local printer. For example, we add the Group "Domain Users" here. (5) Click Start -> Run -> Type: cmd (6) At the command prompt -> Type: gpupdate /force (7) Now, if you logon into the client computers, which applied the Group Policy you edited above, you will find the group "Domain Users" is the member of local security group "Administrator". After that, you can use user accounts, which are the member of "Domain Users", to install the local printer. As I mentioned before, if we use this solution, the members of the group, which you added into the "Administrator", will have all of local administrators' permissions on the client computer. Method 2: Even though the ability to install local printers was limited to members of local administrators or power users group, we could use the utility EPAL for the specific task to add printers in our environment. EPAL will allow a specific executable to run in an elevated privileges mode. EPAL creates a domain user account and a domain group account based on that executable name in the OU specified. If the executable is named "APP.EXE", then the user created is named APP and the group created is named APP Application Users. Only domain users in this same OU can use this executable. Therefore if you have users in multiple OUs, you must create a new domain user and domain group for each specific OU. However, since all user and group accounts in Active Directory must have unique names, then a different executable must be created for each OU. The download and documentation for EPAL can be accessed at http://www.microsoft.com/technet/prodtechnol/windows2000serv/downloads/epal.mspx In our case we used the command line ?rundll32 printui.dll,PrintUIEntry /il? to create the batch file ?Addprn.bat?. You could also create a custom application on similar lines. Here?s the general process we used to implement EPAL: 1. In Active Directory Users and Computers creat an OU called ?GroupA? i.e. ?OU=GroupA, DC=kirindc, DC=domain, DC=local?. 2. On the domain client (vpc-kirinxp) and a domain controller (vpc-kirin2003), create ?c:epal? directory and copy files epal.exe (application downloaded from Microsoft.com), Addprn.bat (custom command to be delegated using EPAL) to c:epal. 3. In order to create the EPAL domain user and domain group accounts in Active Directory, log on to the domain controller as a domain administrator and run the command. c:epal>epal /C:OU=GroupA /R Addprn.bat This creates two accounts - Service account name ?Addprn? and a Domain Local group called ?Addprn Application Users?. 4. On the client machine, add the domain user account Pwizard to local Power Users group (or local Administrators depending on required permissions and rights). For you other custom applications, you may also need to add any other permissions or user rights that may be required to run the application. 5. Create/move the end user(s) to the proper OU - Addprn in this case and add them to the appropriate application users group - ?Addprn Application Users? 6. The end user must run a command on the workstation to execute the application in privileged mode with EPAL. The end-user can type the command or you can create a batch file with the following command. C:epalepal.exe /C:OU=GroupA c:epalAddprn.bat --------------------- I provide you with the detail test below, which is described step-by-step. You can refer it to achieve your goal. To implement EPAL: EPAL requires at least two machines, a workstation and a server. The following steps were taken on a Windows 2000 domain controller and a Windows XP client. Domain - domain.local DC - DC1.domain.local XP - XP1.domain.local In the following example we use two OUs with Child nested under Parent: OU=Parent,DC=domain,DC=local OU=Child,OU=Parent,DC=domain,DC=local The Parent OU will use the executable APP.exe and the Child will use the executable APP2.exe. The executable must have a unique name because the user and group accounts created are base on the executable name. Each object in Active Directory must have a unique name, so duplicate names are not allowed even in different OUs. The corresponding executable must be installed locally to the computer the end user will use. If your account is in the Parent OU, then you need the corresponding executable on your computer, for example c:epalAPP.exe. If your account is in the Child OU, then you need the file c:epalAPP2.exe. If you have users in 100 OUs, then you need 100 versions of the same executable, each with unique names. The EPAL user and group accounts must be created in each OU that you have users who need elevated rights. For end users to be able to use the EPAL process, they must be members of the corresponding ?Application Users? group. Normally permissions propagate based on group membership. That does not appear to be true with EPAL. The ?Application Users? group is a Domain Local group. Normally Domain Global groups can be a member of a Domain Local group and permissions propagate to the individual members of the Domain Global group. While you can add a Domain Global group as a member of the ?Application Users? Domain Local group, permissions are not propagated. Each Domain user must be added individually to each ?Application Users? group to have permission to run EPAL. Step by Step Process: 1. In Active Directory users and computers create an OU and a child OU: OU=Parent,DC=domain,DC=local OU=Child,OU=Parent,DC=domain,DC=local 2. On XP1 created c:epal directory, copied files epal.exe, APP.exe and APP2.exe to c:epal. 3. The end user must run a command on the workstation to execute the application in privileged mode with EPAL. The user can type the command or you can create a batch file. When you type the command use the full path, or you will receive an ?invalid directory? error. On XP1 created batch files c:epalappuser.bat and c:epalappuser2.bat: epal.exe /C:OU=Parent c:epalAPP.exe epal.exe /C:OU=Child,OU=Parent c:epal.APP2.exe 4. To create the EPAL domain user and domain group accounts in Active Directory. Log on simonxp1 as a domain administrator and run: c:epal>epal /C:OU=Parent /R APP.exe c:epal>epal /C:OU=Child,OU=Parent /R APP2.exe Child is nested under Parent. For nested OUs you must use the nested OU path in the command as in the preceding example. These commands create the following domain user and group accounts: CN=APP,OU=Parent,DC=domain,DC=local CN=APP Application Users,OU=Parent,DC=domain,DC=local CN=APP2,OU=Child,OU=Parent,DC=domain,DC=local CN=APP2 Application Users,OU=Child,OU=Parent,DC=domain,DC=local 5. On XP1 add the domain user accounts APP and APP2 to local Power Users group (or local Administrators depending on required permissions and rights). Add any other permissions or user rights that may be required to run the application. 6. Add the end users to the proper OU and add them to the appropriate ?Application Users? group: Create domain end user CN=appuser,OU=Parent,DC=domain,DC=local Add appuser to "APP Application Users" group. Create domain end user CN=appuser2,OU=Child,OU=Parent,DC=domain,DC=local Add appuser2 to "APP2 Application Users" group. 7. Log in as APPUSER or APPUSER2 to workstation XP1, run APPUSER.BAT or APPUSER2.BAT and you can run the application in privileged mode. NOTE - Design limitation of EPAL ---------------------------------------------------------- When EPAL is executed, it looks in Active Directory to find the user credentials and so on. This poses a problem for our laptop home users that are not connected to the network, since Active Directory will not be available for them. 2) The EPAL utility has several limitations. They following are some customer desired changes in the EPAL utility that wouldo make it easier to deploy, specifically. - Allow EPAL to cover all OUs in Active Directory. Use one Domain User account and one Domain Group account across the domain, not just on an OU basis. - Allow EPAL to use one executable, instead of a unique executable for each OU. - Allow Domain Global groups to be nested and propagate permissions to users that are members of the Global group. - If the application finds that there is no access to Active Directory, it should then look in the cached credentials. If you have any questions about the information above, please let me know. We shall be working to resolve this specific issue through the course of the case. In order to follow up with you closely, I will contact you again in two business days via e-mail if I do not receive your response. Want to know how your case is handled? Here is the definition of a support incident: http://support.microsoft.com/Directory/directory/policies.asp Best regards, Jacky Ye Windows Professional Support Microsoft Email Support
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following