Local Admin PW
-
@scottalanmiller said in Local Admin PW:
@jmoore said in Local Admin PW:
@dafyre My boss told me that microsoft took away the ability to change the passwords via gpo because of some issue where they were being sent in plain text. I have no way to verify but thats what he told me
But he also told you that it was still happening. Can't be both.
Are you sure it can't be? My guess is that whatever update removes this ability might not remove an existing GPO with it already setup (in which case there probably is a hacky way to change the password). Or maybe his boss just thinks it is still happening, I couldn't really tell you.
-
@flaxking said in Local Admin PW:
@scottalanmiller said in Local Admin PW:
@jmoore said in Local Admin PW:
@dafyre My boss told me that microsoft took away the ability to change the passwords via gpo because of some issue where they were being sent in plain text. I have no way to verify but thats what he told me
But he also told you that it was still happening. Can't be both.
Are you sure it can't be? My guess is that whatever update removes this ability might not remove an existing GPO with it already setup. Or maybe his boss just thinks it is still happening, I couldn't really tell you.
There would be an easy way to test.
Change the password locally, reboot, perform a gpupdate and see if the old password works again.
-
@flaxking said in Local Admin PW:
@scottalanmiller said in Local Admin PW:
@jmoore said in Local Admin PW:
@dafyre My boss told me that microsoft took away the ability to change the passwords via gpo because of some issue where they were being sent in plain text. I have no way to verify but thats what he told me
But he also told you that it was still happening. Can't be both.
Are you sure it can't be? My guess is that whatever update removes this ability might not remove an existing GPO with it already setup (in which case there probably is a hacky way to change the password). Or maybe his boss just thinks it is still happening, I couldn't really tell you.
There is no reason to think that. Implementing one system would not imply any removal of another. Just as how GPO doesn't remove any other system.
-
@jmoore said in Local Admin PW:
@dafyre My boss told me that microsoft took away the ability to change the passwords via gpo because of some issue where they were being sent in plain text. I have no way to verify but thats what he told me
I don't think it was plain text but it was such a weak cipher it might as well have been.
-
@coliver said in Local Admin PW:
@jmoore said in Local Admin PW:
@dafyre My boss told me that microsoft took away the ability to change the passwords via gpo because of some issue where they were being sent in plain text. I have no way to verify but thats what he told me
I don't think it was plain text but it was such a weak cipher it might as well have been.
got it. one and the same to him I am guessing
-
@flaxking said in Local Admin PW:
@scottalanmiller said in Local Admin PW:
@jmoore said in Local Admin PW:
@dafyre My boss told me that microsoft took away the ability to change the passwords via gpo because of some issue where they were being sent in plain text. I have no way to verify but thats what he told me
But he also told you that it was still happening. Can't be both.
Are you sure it can't be? My guess is that whatever update removes this ability might not remove an existing GPO with it already setup (in which case there probably is a hacky way to change the password). Or maybe his boss just thinks it is still happening, I couldn't really tell you.
Well he definitely said both. So maybe Microsoft took away his ability to change passwords but the gpo itself still remembers the last one and so will change it back if I go and change it ?
-
@dustinb3403 said in Local Admin PW:
@flaxking said in Local Admin PW:
@scottalanmiller said in Local Admin PW:
@jmoore said in Local Admin PW:
@dafyre My boss told me that microsoft took away the ability to change the passwords via gpo because of some issue where they were being sent in plain text. I have no way to verify but thats what he told me
But he also told you that it was still happening. Can't be both.
Are you sure it can't be? My guess is that whatever update removes this ability might not remove an existing GPO with it already setup. Or maybe his boss just thinks it is still happening, I couldn't really tell you.
There would be an easy way to test.
Change the password locally, reboot, perform a gpupdate and see if the old password works again.
testing that now that i have a few min free time
-
This is the simple Net Use I came up with. Granted I was running it through the ScreenConnect COMMAND line tool,.. but it worked every time.
net user USERNAME "Pa$$w0rd149" /add /passwordreq:yes /fullname:"User Name" && net localgroup administrators USERNAME /addYou can do this via Powershell - but I don't have that yet.
-
@jmoore said in Local Admin PW:
@dafyre My boss told me that microsoft took away the ability to change the passwords via gpo because of some issue where they were being sent in plain text. I have no way to verify but thats what he told me
This is true. An automatic update now disables the ability to change the password if you were setting it that way. If you try to edit an existing policy, you get this warning:
And if you click OK, you get this where the password field is disabled:
-
Oddly enough, the password seems to be encrypted when you view the Groups.xml file that creates that policy, but maybe it doesn't take much to reverse it. The code looks like this:
<?xml version="1.0" encoding="UTF-8"?> -<Groups clsid="{3125E937-EB16-4b4c-9934-54123DEA4D26}"> -<User clsid="{DF5F1855-51E5-4d24-8B1A-D9AD348BA1D1}" removePolicy="0" userContext="0" uid="{E2123A2D-7D20-4C9A-A2C9-474CFAF1E5FE}" changed="2017-01-25 14:28:38" image="2" name="user"> <Properties userName="user" subAuthority="" acctDisabled="0" neverExpires="1" noChange="1" changeLogon="0" cpassword="TAF+vMr9+ieePdksvnsN/2i0T+u3P5E+PQ08jnVEgHs" description="" fullName="" newName="" action="U"/> </User> -<Group clsid="{6D4A79E4-529C-4481-ABD0-F5BD7EA93BA7}" uid="{617359A3-9040-4F00-BFED-0FE86588FAF1}" changed="2017-01-25 14:31:18" image="2" name="Administrators (built-in)"> -<Properties description="" newName="" action="U" groupName="Administrators (built-in)" groupSid="S-1-5-32-544" removeAccounts="0" deleteAllGroups="0" deleteAllUsers="0"> -<Members> <Member name=".\user" action="ADD" sid=""/> </Members> </Properties> </Group> </Groups> -
I keep hearing people mention Salt. Is anyone using this in their environment to manage Windows machines? I was trying to get an idea of how much work it would be to deploy it to just do the local user password change task, and came across this in regards to installing the client on the minion:
CREATE THE UNPRIVILEGED USER THAT THE SALT MINION WILL RUN AS Click Start > Control Panel > User Accounts. Click Add or remove user accounts. Click Create new account. Enter salt-user (or a name of your preference) in the New account name field. Select the Standard user radio button. Click the Create Account button. Click on the newly created user account. Click the Create a password link. In the New password and Confirm new password fields, provide a password (e.g "SuperSecretMinionPassword4Me!"). In the Type a password hint field, provide appropriate text (e.g. "My Salt Password"). Click the Create password button. Close the Change an Account window. ADD THE NEW USER TO THE ACCESS CONTROL LIST FOR THE SALT FOLDER In a File Explorer window, browse to the path where Salt is installed (the default path is C:\Salt). Right-click on the Salt folder and select Properties. Click on the Security tab. Click the Edit button. Click the Add button. Type the name of your designated Salt user and click the OK button. Check the box to Allow the Modify permission. Click the OK button. Click the OK button to close the Salt Properties window. UPDATE THE WINDOWS SERVICE USER FOR THE SALT-MINION SERVICE Click Start > Administrative Tools > Services. In the Services list, right-click on salt-minion and select Properties. Click the Log On tab. Click the This account radio button. Provide the account credentials created in section A. Click the OK button. Click the OK button to the prompt confirming that the user has been granted the Log On As A Service right. Click the OK button to the prompt confirming that The new logon name will not take effect until you stop and restart the service. Right-Click on salt-minion and select Stop. Right-Click on salt-minion and select Start.That's a whole lot of manual stuff on each machine just to get the client installed. Am I reading that right or is there an easier way?
-
@jmoore said in Local Admin PW:
@flaxking said in Local Admin PW:
@scottalanmiller said in Local Admin PW:
@jmoore said in Local Admin PW:
@dafyre My boss told me that microsoft took away the ability to change the passwords via gpo because of some issue where they were being sent in plain text. I have no way to verify but thats what he told me
But he also told you that it was still happening. Can't be both.
Are you sure it can't be? My guess is that whatever update removes this ability might not remove an existing GPO with it already setup (in which case there probably is a hacky way to change the password). Or maybe his boss just thinks it is still happening, I couldn't really tell you.
Well he definitely said both. So maybe Microsoft took away his ability to change passwords but the gpo itself still remembers the last one and so will change it back if I go and change it ?
It was removed in server 2012 I believe. The old settings were grandfathered in but you couldn't implement it in a new policy.
-
@mike-davis said in Local Admin PW:
I keep hearing people mention Salt. Is anyone using this in their environment to manage Windows machines? I was trying to get an idea of how much work it would be to deploy it to just do the local user password change task, and came across this in regards to installing the client on the minion:
CREATE THE UNPRIVILEGED USER THAT THE SALT MINION WILL RUN AS Click Start > Control Panel > User Accounts. Click Add or remove user accounts. Click Create new account. Enter salt-user (or a name of your preference) in the New account name field. Select the Standard user radio button. Click the Create Account button. Click on the newly created user account. Click the Create a password link. In the New password and Confirm new password fields, provide a password (e.g "SuperSecretMinionPassword4Me!"). In the Type a password hint field, provide appropriate text (e.g. "My Salt Password"). Click the Create password button. Close the Change an Account window. ADD THE NEW USER TO THE ACCESS CONTROL LIST FOR THE SALT FOLDER In a File Explorer window, browse to the path where Salt is installed (the default path is C:\Salt). Right-click on the Salt folder and select Properties. Click on the Security tab. Click the Edit button. Click the Add button. Type the name of your designated Salt user and click the OK button. Check the box to Allow the Modify permission. Click the OK button. Click the OK button to close the Salt Properties window. UPDATE THE WINDOWS SERVICE USER FOR THE SALT-MINION SERVICE Click Start > Administrative Tools > Services. In the Services list, right-click on salt-minion and select Properties. Click the Log On tab. Click the This account radio button. Provide the account credentials created in section A. Click the OK button. Click the OK button to the prompt confirming that the user has been granted the Log On As A Service right. Click the OK button to the prompt confirming that The new logon name will not take effect until you stop and restart the service. Right-Click on salt-minion and select Stop. Right-Click on salt-minion and select Start.That's a whole lot of manual stuff on each machine just to get the client installed. Am I reading that right or is there an easier way?
All of that can be accomplished with a script. Not really out of the question. The big thing is that you put the salt-minion service in the base/golden image and don't worry about it in the future.
-
@mike-davis said in Local Admin PW:
I keep hearing people mention Salt. Is anyone using this in their environment to manage Windows machines? I was trying to get an idea of how much work it would be to deploy it to just do the local user password change task, and came across this in regards to installing the client on the minion:
CREATE THE UNPRIVILEGED USER THAT THE SALT MINION WILL RUN AS Click Start > Control Panel > User Accounts. Click Add or remove user accounts. Click Create new account. Enter salt-user (or a name of your preference) in the New account name field. Select the Standard user radio button. Click the Create Account button. Click on the newly created user account. Click the Create a password link. In the New password and Confirm new password fields, provide a password (e.g "SuperSecretMinionPassword4Me!"). In the Type a password hint field, provide appropriate text (e.g. "My Salt Password"). Click the Create password button. Close the Change an Account window. ADD THE NEW USER TO THE ACCESS CONTROL LIST FOR THE SALT FOLDER In a File Explorer window, browse to the path where Salt is installed (the default path is C:\Salt). Right-click on the Salt folder and select Properties. Click on the Security tab. Click the Edit button. Click the Add button. Type the name of your designated Salt user and click the OK button. Check the box to Allow the Modify permission. Click the OK button. Click the OK button to close the Salt Properties window. UPDATE THE WINDOWS SERVICE USER FOR THE SALT-MINION SERVICE Click Start > Administrative Tools > Services. In the Services list, right-click on salt-minion and select Properties. Click the Log On tab. Click the This account radio button. Provide the account credentials created in section A. Click the OK button. Click the OK button to the prompt confirming that the user has been granted the Log On As A Service right. Click the OK button to the prompt confirming that The new logon name will not take effect until you stop and restart the service. Right-Click on salt-minion and select Stop. Right-Click on salt-minion and select Start.That's a whole lot of manual stuff on each machine just to get the client installed. Am I reading that right or is there an easier way?
I use Salt to manage Windows workstations.
That's just if you don't want it to run as the 'root' user, which I've never had an any incentive to change.Run the bootstrap script on your Salt master. point 'salt' in your DNS to the Salt master and install it on your workstations via the Windows installer, and then you have Salt operational. However, I would suggest alternatively specifying a public DNS name that you can control in order to future proof for when you're ready to move outside your LAN. However, you could just use Salt to change that too!
Of course you have to go deeper down the rabbit hole to get a 'nice' setup.
-
@mike-davis said in Local Admin PW:
I keep hearing people mention Salt. Is anyone using this in their environment to manage Windows machines? I was trying to get an idea of how much work it would be to deploy it to just do the local user password change task, and came across this in regards to installing the client on the minion:
CREATE THE UNPRIVILEGED USER THAT THE SALT MINION WILL RUN AS Click Start > Control Panel > User Accounts. Click Add or remove user accounts. Click Create new account. Enter salt-user (or a name of your preference) in the New account name field. Select the Standard user radio button. Click the Create Account button. Click on the newly created user account. Click the Create a password link. In the New password and Confirm new password fields, provide a password (e.g "SuperSecretMinionPassword4Me!"). In the Type a password hint field, provide appropriate text (e.g. "My Salt Password"). Click the Create password button. Close the Change an Account window. ADD THE NEW USER TO THE ACCESS CONTROL LIST FOR THE SALT FOLDER In a File Explorer window, browse to the path where Salt is installed (the default path is C:\Salt). Right-click on the Salt folder and select Properties. Click on the Security tab. Click the Edit button. Click the Add button. Type the name of your designated Salt user and click the OK button. Check the box to Allow the Modify permission. Click the OK button. Click the OK button to close the Salt Properties window. UPDATE THE WINDOWS SERVICE USER FOR THE SALT-MINION SERVICE Click Start > Administrative Tools > Services. In the Services list, right-click on salt-minion and select Properties. Click the Log On tab. Click the This account radio button. Provide the account credentials created in section A. Click the OK button. Click the OK button to the prompt confirming that the user has been granted the Log On As A Service right. Click the OK button to the prompt confirming that The new logon name will not take effect until you stop and restart the service. Right-Click on salt-minion and select Stop. Right-Click on salt-minion and select Start.That's a whole lot of manual stuff on each machine just to get the client installed. Am I reading that right or is there an easier way?
You should be using Chocolatey. It's...
choco install saltminionThat's it. That's the entire install system. SodiumSuite uses Salt under the hood and we don't have any complexity doing installs of it.
-
@flaxking said in Local Admin PW:
That's just if you don't want it to run as the 'root' user, which I've never had an any incentive to change.
Which pretty much defeats the purpose, anyway.
