1
votes

It sounds ridiculous, but I have a batch file that kicks off a PowerShell file (it's easier to just right click a batch file and "Run As Administrator"), which depending on some parameters inside the PowerShell file, can run a different batch file that does some stuff.

.bat -> .ps1 -> .bat

This is necessary because someone other than me writes and manages this other batch file. I can't incorporate what it's doing into my own scripts.

As is, running my batch files DOES run my PowerShell script as Administrator. Will it keep carrying on and run the nested batch file as Administrator as well? How deep does it go? Do you ever "lose" Administrator?

1
1. When you "run as" and elevate a process, that process remains elevated until it terminates. 2. Why do you need the first two scripts? Just run the third one elevated.Bill_Stewart
The third script one doesn't always run. The PowerShell script looks at things (on a SQL server) and determines if the final batch file is necessary.jdope
Seems a bit convoluted, but ok...Bill_Stewart
@Bill_Stewart Yeah, it's definitely weird. The other department needs to be able to keep their batch file separate from my PowerShell script though. They sometimes run it independently, so having to update their stand alone copy, and mess with my PowerShell script would be too much of a hassle.jdope

1 Answers

2
votes

Yes it will keep going on, and in most cases, it depends on what your process is doing but the answer is typically, no--it won't lose Administrator privileges. The key distinction here is whether or not your scripts stay local or not.

If local, then yes, Administrator context will remain for your processes spawned from the initial elevated process.

If your scrips reach out across the network, then it depends. Is the account that has been elevated also an administrator on the remote machine? Then yes, it will keep running as administrator. If the local user does not have administrative rights on the remote machine, then it might be possible to interact with the remote host but not perform administrative tasks (depending on whether or not the local administrator has "user" rights on the remote box).

If you have local host (A) and remote hosts (B and C) and a script from host A (with admin elevation) attempts to perform a series of commands on host B. If any of those commands reach out from host B to any other remote host (e.g. host C), then this will fail for another reason. This problem occurs because of how Windows performs NTLM/Kerberos authentication and stores those credentials for Single-Sign On.

Assuming successful initial local authentication on host A, a security token is created in memory that is stored and maintained so that anything requiring authentication can re-use that token without re-prompting the user for credentials. Going into too much depth of the process is beyond the scope of this question but just understand that while host A has that token and can present it to remote resources for authentication, the remote host does not get a copy of it. Meaning, host A can get host B to trust it (assuming rights were conferred) but host B has no mechanism to provide this same authentication token to any other host (e.g. host C) -- for a much more detailed explanation, this is called the "double hop" problem. https://blogs.technet.microsoft.com/askds/2008/06/13/understanding-kerberos-double-hop/