|
hi Mack. You may want to try adding the username/password of the user in question to the machine that hosts the workgroup printer. That will probabl solve the issue of having to use the admin account. But you may still need to use a login script create a mapping to let the two machines 'authenticate'. I *think* a printer mapping will fail even if the username and pass are correct when dealing with a domain member trying to access a workgroup machine. Honestly can't remember since I deal with 100% domain members and servers.
What I've done to force authentication between domain members and workgroup machines in the past, is make sure the workgroup machine has the same U/P of the user logged into the domain member, then create a dummy share on the workgroup machine. It can be whatever. On the domain member, do a NET USE * \\WORKGROUPMACHINE\SHARE. THen try to print. Should work. If that works, you can make that drive mapping persistent by adding /PERSISTENT:YES to the end. Added benefit of using persistent is that upon reboot, if it runs into a credentials problem, but the usernames match, it'll ask you for the password. [edit: the other option is to use a GPO login script or regular login script with the same NET USE command but without the persistent switch...but i can't remember if it'll fail if it can't match up the credentials]
Ideally however, I would suggest you get away from using a workgroup in a corporate environment. I would create a new domain within the forest for the members of your 'sensitive' group. Domains are fairly good security boundaries and while keeping your data secure, will also give those members access to other forest resources. If you're *really* paranoid, you can set up another forest and trust the two. Integrating the workgroup into the/a forest will give you thea bility to provide central management to the workstations, implement Exchange, etc.
|