Computer name is being added to Local User Groups with batch file.

[mortega]

I have a strange issue… I created a batch file to add the current user as an admin (they already have admin rights under a group membership that I’m trying to remove). Here is the command.

net localgroup administrators %username% /add

Using either the Deploy/software/patch/etc… and execute remote process/command will add the computer (Domain/Computername) name in the local Administrators group. Running this command locally on the system (outside of batchpatch) will work as expected. What the heck is going on?

[doug]

OK, so here are your options:

1. Create a deployment to deploy a batch file with your command specified as the content of that batch file. I was able to do this without issue, but you need to make sure that under ‘Tools > Settings > Remote execution’ that the ‘Deployment’ section is set to ‘Elevated token’ and not ‘SYSTEM.’

Note, however, that this still might not give you the desired result. It will put the current user into the administrators group, but the current user is not the end user who is logged on to the target computer. The current user is the account that you used to launch BatchPatch, or it will be the account that you entered into the alternate credentials field for the given row in BatchPatch, if you entered alternate credentials.

2. You can use a remote process/command, but then you cannot use %username%. In that case you must use the actual username.

---

I’m not certain right now why the issue occurs with remote process/command, but I am able to reproduce it. It’s something to do with Windows, not BP. It’s described here too. There is something unexpected happening with environment variables, but I don’t know exactly why. A third option, it seems, would be to use powershell with the method described in the link above. Let me know how it goes and which option you end up using with success.

Thanks,

Doug

[mortega]

Thanks for the quick response Doug… I’ll give that a try.

P.S. I was initially getting an Error Code 1 and somehow it fixed itself when working with executing a remote batch file.

[doug]

The error code 1 with the batch file would have been when the remote execution context was set to ‘SYSTEM’ instead of ‘Elevated token’ for the deployment. Glad you got it working now.

-Doug

[mortega]

Haven’t tried what you mentioned yet but what solved the initial error code 1 was using a a network path as X:folderbatch.bat instead of \serverfolderbatch.bat

[mortega]

Just to confirm, the other three should stay at System?

[doug]

OK so let me correct myself… I realize now that I made a mistake.

You can actually use either the remote process/command OR the deployment feature in BatchPatch to successfully accomplish what you are trying to accomplish. However, for either option to work properly you need to change the remote execution context under ‘Tools > Settings > Remote Execution’ to ‘Elevated token’ instead of ‘SYSTEM.’ And so if you are trying to use ‘remote process/command’ to accomplish the task, then you would need to change the execution context for ‘remote process/command’ to be ‘Elevated token.’ If you are trying to use the ‘deployment’ feature of BatchPatch to accomplish this task, then you need to change the execution context for ‘deployment’ to be ‘Elevated token’ instead of ‘SYSTEM.’

NOTE: In many cases there will be no discernible difference in the behavior of remote commands run under different execution contexts. However, in some cases commands might only run successfully under a particular context. We find that using the SYSTEM account works best for most users in most situations, but in the case that we are discussing, SYSTEM will not work as desired, which is why you need to use ‘Elevated token’ instead.

I hope this helps.

-Doug

[mortega]

That didn’t work, now it’s added my account to every workstation instead of the currently logged in user.

Edit: Haven’t read your recent response… reading now.

Edit 2: Just read your response… don’t think it helps with what my issue is now.

Edit 3: Had to manually backdoor into each machine to fix the admin rights.

[doug]

Well I did say that you would end up with your account (the account used to launch BatchPatch) as the account that would be added. See my original post.

-Doug

[mortega]

Thanks for the response. I must have missed that…

How would you suggest I try to accomplish this task? What I was trying to accomplish was somehow add/remove admin rights as needed for software update/installs only. I had initially tried to create a “workstation admin” group where I would manually add/remove users whenever there’s an update. But then how would I stop other users from having rights to other workstations. I had to revert to each user on each workstation along with removing admin rights from my users who just love to click on everything.

[doug]

mortega – I’m not sure I fully understand your goal. If you are using BP to install updates, you do not need to have end users in the local admins group. As long as the account that you are using to run BP (or the account that you input in the alternate credentials field in a BP row) is in the local admin group on target computers you’ll be all set to install updates on those computers.

If your goal is to allow users to install their own windows updates, I believe there is a group policy that allows non-admin users to install windows updates, so you can use that.

If your goal is to allow users to install their own software, then you’re asking an IT policy question, not a BatchPatch question. There are a lot of different ways that organizations handle this situation. Some possible options include:

1. Allow users to be admins of their own computers at all times.

2. Do not ever allow users to be admins of their own computers. All software is installed by an IT admin.

3. Provide users with 2 accounts. They have a primary account that they log on to their computers with for every day use. This account is not in the admins group. Then they have a secondary local admin account on their own computer. If they want to install software then they would use run-as to install the software using the local admin credentials.

4. You could use BatchPatch to put the end user of a computer into the local admins group, similarly to how you were trying it. But instead of using %username% you would use the actual username. I’m not sure why you aren’t already doing this, but I assume you have a reason.

5. Create one security group for each target computer. Add that group to the target computer’s local admin group. Then use Active Directory to add/remove the desired user at the desired time. This way since every computer has its own unique security group, you don’t end up giving one user access to another user’s computer.

6. Some other method.

[mortega]

Thank you for the response Doug,

1. This is what I am currently doing and what I’m ultimately trying to accomplish… nothing having to do with Windows Updates. We have software that our folks use on a daily basis to complete their tasks that have periodic updates. These updates require admin rights to complete, most of these applications are legacy based and do not have msi’s associated with them so they have to physically click on the setup executable and then manually run the update. I’m trying to come up with a strategy that will allow me to remove their admin rights until the day they are needed only to their specific workstation to complete this task. Then next time they login, they will have these rights revoked. I was hoping that batchpatch could allow me to push this out via an batch file (with admin credentials -still haven’t looked into this) to add the currently logged on user to the local administrators group.

2. I’m a one man shop, this would take up way too much time for all the legacy apps that we have to install/update periodically. The other caveat would be that some folks start work at 5am while I don’t come in until 8am… never mind the folks that work late at night.

3. If I gave my users two accounts, they would login with the admin login at all times.

4. This would mean separate batch files for each user with their username in the batch file. It would probably be quicker to add/remove the accounts the way I did yesterday (took about 15 minutes). Unless you can think of a better way.

5. If I’m understanding this correctly, if we had 100 users, then I would have to add each user to 100 security groups each time I needed to give them admin rights?

6. That’s what I’m hoping to find! hahaha

Thanks for your response, this gives me the ability to ‘talk’ out my issues with someone. Thanks again!

[doug]

I see. This makes sense. I have a few thoughts.

First, I think your goal here is commendable, but this is not a new problem. IT admins have been wresting with the issue of how to handle admin rights for end users for years. You can find many places on the web where this is discussed. I’m sure I have seen the topic posted in Reddit sysadmin subreddit more than one time. To grant and remove admin access on an as-needed basis seems to me not a great solution, but I don’t work at your office, and only you can decide what is best for your environment. You might consider reading through reddit and/or posting there to see what people suggest. There are other IT forums where this topic has been addressed as well, so some googling might get you a better solution.

3. If you gave your users one domain account and one local account, they would use the domain account as their main logon. Their email would be tied to this account as would all of their network privileges. The local account would only be useful for updating applications. It would not be useful for daily logon, so they wouldn’t do that (most likely). I have seen this option work effectively in more than one organization. In most Windows domain environments, giving users a local admin account will not entice them to be logged on all the time with that account because there are too many things that they need to be logged on to their domain account for, with email and network privileges being the two most important usually.

4. You would not need separate batch files. You could use the remote/process command action in BP (just make sure to modify the remote execution context, as previously discussed. This would allow you to spend a little while just one time to create your BP grid to include the proper remote/process command for each row, customized for each username. Then you would save this grid to a .bps file for future use. Then in the future you could just load that .bps file into a grid, select all rows and execute the remote process/command.

7. You could write a vbs or powershell script that finds the currently logged on user and then in that same script then adds the user to the required group (or removes). You would then deploy the .ps1 or .vbs file with BP. It would be the same script for all targets since the script would dynamically handle figuring out the currently logged on user. A couple methods for getting the currently logged on user are described here: https://serverfault.com/questions/32633/how-to-check-who-is-currently-logged-on-to-windows-workstation-from-command-line

I hope this helps.

[Author]

Posts