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?
- 14,647
- 4
- 34
- 51
- 1,378
- 4
- 19
- 37
-
Depending upon your end goal, you might want to look into SpiceWorks. It harvests much of this information automagically without tweaking AD. – hurfdurf Jan 17 '11 at 18:44
4 Answers
You can use devxexec: http://blog.developex.com/?p=1053
For example:
devxexec.exe /user:NETWORK_SERVICE cmd
- 76
- 1
- 2
-
Sadly, this doesn't seem to work on windows 2008r2 or newer, it throws error 0x000142 – aseques Apr 11 '19 at 13:15
-
@aseques: Read the [(archived) manual](https://web.archive.org/web/20151030045935/http://developex.com/custom-software/devx-exec.html), it explicitly explains why this error occurs, and how to solve it. – AntoineL Oct 22 '20 at 09: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.
- 764
- 2
- 5
- 16
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.
- 37,618
- 10
- 90
- 145
- 41
- 1
-
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. – bshacklett Jan 17 '11 at 22:22
-
And then the ridiculousness of installing a service just to push make/model info to AD hits me. – bshacklett Jan 17 '11 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. – boyonwheels Jan 18 '11 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. – boyonwheels Jan 18 '11 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. – bshacklett Jan 20 '11 at 12:57