I'm toying with an idea for a script that would update a computer's details in Active directory with its make and model information. Ideally, I'd like this script to access AD via its computer account, which means I'd need to have the script run as "NT Authority\NetworkService". Is this something that's possible? Alternatively, could I impersonate NetworkService in the script/executable?
4 Answers
You can use devxexec: http://blog.developex.com/?p=1053
For example:
devxexec.exe /user:NETWORK_SERVICE cmd
-
Sadly, this doesn't seem to work on windows 2008r2 or newer, it throws error 0x000142– asequesApr 11, 2019 at 13:15
-
@aseques: Read the (archived) manual, it explicitly explains why this error occurs, and how to solve it.– AntoineLOct 22, 2020 at 9:12
"The scripting guy" has already answered this question here: http://www.microsoft.com/technet/scriptcenter/resources/qanda/apr05/hey0429.mspx
You'll just need to include the WMI call to grab the machine model number...
My implementation went like this:
Set objSysInfo = CreateObject("ADSystemInfo")
Set objUser = GetObject("LDAP://" & objSysInfo.UserName)
Set objComputer = GetObject("LDAP://" & objSysInfo.ComputerName)
If objComputer.operatingSystem = "Windows*Server*" Then
Quit
Else
strMessage = objUser.CN & " logged on to " & objComputer.CN & " " & Day(Date) & "/" & Month(Date) & "/" & Year(Date) & " " & Time & "."
objComputer.Description = strMessage
objComputer.SetInfo
End If
Call the above script from a GPO, using: User Config -> Windows Settings -> Scripts -> Logon
Then just update the permissions on the OU, so that users can modify the computer object descriptions, like this:
I'm not sure how feasible it is to do what you want. Escalating permissions might be better asked over in StackOverflow. However, what not run the script as the local admin. With the exception of DC's, the account exists. On the \DC's you can run it as a domain admin or some other account that would have limited permissions for this task.
If the computers already exist in AD I would approach this problem from the other direction -- on the server side iriterate through the computer objects and use PsExec to find the information you require on the remote system and return it.
http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx
I'd then run the script under the account with the permissions required using Task Scheduler.
-
1The problem with running psexec to query remote machines is that it's more complicated to deal with machines that are unavailable. If I configure a login script or an agent via GPO, I can sit back and wait for the computers to check in on their own rather than running query after query to catch every machine. As I think about it, though, it may be better to write this as an agent with a service that can easily run as NetworkService anyway. Jan 17, 2011 at 22:22
-
And then the ridiculousness of installing a service just to push make/model info to AD hits me. Jan 17, 2011 at 22:31
-
That's a fair criticism/annoyance. Sticking with the same theme you could push out the scheduled task to all of the client machines using a GPO. Jan 18, 2011 at 13:41
-
That way you get the benefit of both: schedule tasks permission escalation and the "one time check-in" by running it on the client side. Jan 18, 2011 at 13:50
-
1After trying it and doing some research, it appears that the Network Service account does not have rights to run as a batch job. Jan 20, 2011 at 12:57