I have laptop users who are not allowed to install programs on their laptops but I need to allow them to add printers when they are at home. They have basic user rights, and log onto a DC when in the office. Have looked through local and group policy but can't find the right setting.(Not sure if group policy is applied when they not logged onto network?) Any ideas?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Need to restrict users but allow add printers?? 2
- Thread starter 999Dom999
- Start date
TechyMcSe2k
Technical User
I believe if you put the Domain User account into Power Users on the machines, they will be able to add printers and still not be able to install programs. Try this, if it does not work then you will need to play with the local group policy on the machine. run gpedit.msc
- Thread starter
- #4
Thanks guys, Power users offers too much rights and can install apps. I have looked through group policy and there is an option to disable addition of printers but not to permit addition. Have done various searches on the internet and seen people in same scenario but not found a solution yet.
-
2
- #5
SunnyByfleet
Technical User
Why not try scripting RUNAS to load the printer and faxes applet?
You could hardcode a suitable user id and password and encrypt it.
I found this on the web which may point you in the right direction...
Many programs cannot be run properly in any context other than the administrator account or an account with administrator privileges. Because of this, administrators often face this dilemma: Should they give their users admin privileges, in spite of the possible security hazards and headaches this may cause, or should they try to find another program that will work properly outside of the administrator context, a move which could cause lost productivity and possibly other problems?
It is possible to run a program from another user's context, but the way Windows 2000 and XP Professional implement this feature requires that the user know the password for the other account. This makes it difficult to run the program securely. If you create a new administrator-level account that has no local login permissions, then the program will not be able to run in the first place and that certainly defeats the purpose!
The solution involves the use of Windows Script Host to create a script that can run the program in the appropriate context and provide the password non-interactively. Here is a sample script:
set WshShell = CreateObject("WScript.Shell")
WshShell.Run "runas /user:Serdar ""e:test.bat"""
WScript.Sleep 100
WshShell.Sendkeys "password~"
In this example, the user is Serdar and the file to run is e:test.bat. (Note the use of double quotes in the WshShell.Run command to pass quotes on to the command interpreter.) The password, of course, is password, and the tilde at the end of the Sendkeys command is a carriage return. These can be customized as needed and the file should be saved with the extension .VBS.
To prevent users from reading the file directly and learning the password, the script can be encoded using Microsoft's Script Encoder tool. Be sure to rename the encoded script with a .VBE extension rather than .VBS. (Note that this will not prevent a very determined user from finding the password, but it will certainly stop someone from casually learning it.) Using permissions to prevent users from reading the file unfortunately also prevents it from being run by the VBScript interpreter.
You could hardcode a suitable user id and password and encrypt it.
I found this on the web which may point you in the right direction...
Many programs cannot be run properly in any context other than the administrator account or an account with administrator privileges. Because of this, administrators often face this dilemma: Should they give their users admin privileges, in spite of the possible security hazards and headaches this may cause, or should they try to find another program that will work properly outside of the administrator context, a move which could cause lost productivity and possibly other problems?
It is possible to run a program from another user's context, but the way Windows 2000 and XP Professional implement this feature requires that the user know the password for the other account. This makes it difficult to run the program securely. If you create a new administrator-level account that has no local login permissions, then the program will not be able to run in the first place and that certainly defeats the purpose!
The solution involves the use of Windows Script Host to create a script that can run the program in the appropriate context and provide the password non-interactively. Here is a sample script:
set WshShell = CreateObject("WScript.Shell")
WshShell.Run "runas /user:Serdar ""e:test.bat"""
WScript.Sleep 100
WshShell.Sendkeys "password~"
In this example, the user is Serdar and the file to run is e:test.bat. (Note the use of double quotes in the WshShell.Run command to pass quotes on to the command interpreter.) The password, of course, is password, and the tilde at the end of the Sendkeys command is a carriage return. These can be customized as needed and the file should be saved with the extension .VBS.
To prevent users from reading the file directly and learning the password, the script can be encoded using Microsoft's Script Encoder tool. Be sure to rename the encoded script with a .VBE extension rather than .VBS. (Note that this will not prevent a very determined user from finding the password, but it will certainly stop someone from casually learning it.) Using permissions to prevent users from reading the file unfortunately also prevents it from being run by the VBScript interpreter.
- Thread starter
- #6
Thats absolutly crackin!
set WshShell = CreateObject("WScript.Shell")
WshShell.Run "runas /user:administrator ""C:\WINDOWS\system32\rundll32 printui.dll,PrintUIEntry /il"""
WScript.Sleep 100
WshShell.Sendkeys "password~"
This is the final command and tested it, it works!
Will probably create a local Power user with an obscure user name and pass so it doesn't look obvious and won't give too much rights if found, which I doubt it will.
Thanks very much for that!
set WshShell = CreateObject("WScript.Shell")
WshShell.Run "runas /user:administrator ""C:\WINDOWS\system32\rundll32 printui.dll,PrintUIEntry /il"""
WScript.Sleep 100
WshShell.Sendkeys "password~"
This is the final command and tested it, it works!
Will probably create a local Power user with an obscure user name and pass so it doesn't look obvious and won't give too much rights if found, which I doubt it will.
Thanks very much for that!
klewis10367
MIS
SunnyByFleet, since I am inept at scripts would you be able to provide me one so I could use it for install purposes, not for printers? Thankyou.
- Thread starter
- #8
SunnyByfleet
Technical User
Actually The Byfleet is from Byfleet, right next to West Byfleet, so yes, you are just down the road from me. Small World.
Oh, and its not sunny at the mo, its foggy...
Oh, and its not sunny at the mo, its foggy...
An alternative to RUNAS is to give device driver rights to additional groups on that computer:
Go to Control Panel, Administrative Tools, Local Security Policy.
Security Settings, Local Policies, User Rights Assignment, Load and unload device drivers
Add User or Group, Advanced
Object types = Groups
Locations = [computer name]
Find now ... select Power Users (or other groups)
Go to Control Panel, Administrative Tools, Local Security Policy.
Security Settings, Local Policies, User Rights Assignment, Load and unload device drivers
Add User or Group, Advanced
Object types = Groups
Locations = [computer name]
Find now ... select Power Users (or other groups)
- Status
