Board index » Visual Studio » need a script to impersonate

Visual Studio169
I am working on a StartUp script that checks for OU=Computers and if found

moves the computer to another OU based on OScaption.



I did have the foresite to create a user id and assign it to "Managed By"

for the OU.



My problem is that during start-up there is no user logged so my MoveHere

method(?) fails.



How can I have my script impersonate my OU manager?


-

"Sheepdog" <ng.20.shep@spamgourmet.com>wrote in message

A good question, but here is one for you: why would you prefer to do this

kind of administrative task in a startup script rather than centrally from a

management console?



/Al





-

Sheepdog wrote:



Hi



Try to connect with explicit user credentials using

SWbemLocator.ConnectServer.



Subject: Login with explicit username and password

Newsgroups: microsoft.public.win32.programmer.wmi

http://groups.google.com/groups?th" rel="nofollow" target="_blank">groups.google.com/groups=2b5bcad76f5debaa



Subject: ImpersoantionLevel other than impersonate

Newsgroups: microsoft.public.scripting.wsh

http://groups.google.com/groups?th" rel="nofollow" target="_blank">groups.google.com/groups=89ff50603f12dcfb





--

torgeir

Microsoft MVP Scripting and WMI, Porsgrunn Norway

Administration scripting examples and an ONLINE version of the 1328 page

Scripting Guide: www.microsoft.com/technet/scriptcenter">www.microsoft.com/technet/scriptcenter





-

"Al Dunbar [MS-MVP]" <alan-no-drub-spam@hotmail.com>wrote in message



Granted I could write a one time script to move all the current computers

but what happens the next time the helpdesk adds a new PC to the network.



I really want a fire and forget solution that works in real time.





-

"Sheepdog" <ng.20.shep@spamgourmet.com>wrote in message

Well, if some of them are linux and MAC systems, I am really not sure what

can be done with vbscript...



You might write it one time, but you could run it periodically.



Get the helpdesk to either add it correctly, or to run the script whenever

they add a new PC.



Good luck, but I am wondering what the consequences are when someone logs on

to a workstation that has not yet been moved to its proper OU. Will certain

things not work for the user?



Why not modify the procedures used by the help desk to create the

workstation account?



Getting back to your original question, though, I have no idea how a script

can impersonate an account with domain admin privileges without actually

logging on, and am not sure if logging on could be done in the context of a

startup script. But, even if it was, would you not be exposing the keys to

the kingdom in this script? Considering the potential security risks and the

difficulty in doing it this way, are you sure you are really going after the

easiest solution?



And what happens when this workstation is started up at a time when it lacks

network connectivity? Suppose the local LAN is down, or the user unplugged

it from the wall for some reason, or, more likely, plugged it in to an

outlet that has not yet been enabled in your wiring closet? Even if you have

coded the startup script to logon, it is not going to be able to.



I'd still suggest modifying the helpdesk procedures, and implementing an OU

check in the logon script if correctness is essential.



/Al





-

administrators don't allow the Help Desk to access all

OU's. I would rather automate moving workstations into

the proper OU than to trust that my Help Desk will always

know where to put workstations - Let alone give them the

access to add/remove workstations in every OU.



Another issue with allowing the help desk to do this is

the fact that in a large environment, you may not have

central control over all OU's. Decentralized Help Desks

normally do not have rights in other departmental OU's so

I agree that automating this feature makes good sense.



Sheepdog, You could possibly write the script and launch

it via the RunOnce registry key. Of course, you would

have to implement this into your workstation image since

you want this to run at first power on. You could also

encrypt the script (using the script signer) and delete

it after execution so it's eyes off. A possible better

way is to add this to your login script. Al is correct

in the fact that if someone forgot to plug the Cat5 cable

in or terminate it nothings going to happen. Something

else to think about is that if you do it in a login

script, you don't have to worry about impersonating

someone else as the SysVol built in account will have

enough rights.



I know it can be done as I've worked for a company that

wrote an ASP page to add users to AD without having

domain admin rights. I thought it had something to do

with the Impersonation Level but the MS Scripting Guide

states that you cannot impersonate another user. If you

find out, let me know as I also have a use for this type

of functionality.



Thanks, JT



-

"JT" <John@JTJohnson.net>wrote in message

<snip>



Oops, my bad. Where I am the same team fills all shoes, whether admin,

helpdesk, or what have you.



Agreed. But I still find it perhaps a bit unusual that you would allow them

to add a workstation, but not give enough privs that they can complete the

task. Oops, there I go again thinking that all shops are like mine...



Sure. If it can be done reliably, and without creating any security issues.



A little bit iffy, not robustly secure, and potentially difficult to

debug...



But while the user is logging in, it is their credentials that are in

effect. How would you go about running script in that context under the

credentials of a built-in account without coding in the password somewhere?



Could do the same to create workstations. The script would determine the

destination OU, and then the service account would carry out the request (or

however you managed it in your case).



You can only "impersonate another user" if you have the password, and then

you can do it using RUNAS or one of the many third-party tools available to

fill that need (i.e. RunAS Pro). I found the term "impersonate" a little

confusing too in the context of WMI, as it conveys a somehow different

impression of what it is doing.





/Al





-