I'm trying to script / psuedo-automate credential updates.
My goal is to be able to change a User Password without being logged in as the user and doing CTRL+ALT+DEL, without losing access to the Credential Manager Secrets that are wiped when a users password is changed any way except through the CTRL+ALT+DEL password change.
My idea is this :
On an admin account remotely trigger a Powershell/Command Prompt.
Utilize "RunAs" to Run the "net user USERNAME PASSWORD" command as that user.
See if this maintains the Credential Manager and Secrets that are associated with the user account.
However, when I am on the admin account and try to trigger something like
"Start-Process powershell -Credential USERNAME"
I always get "The service cannot be started, either because it is disabled or it has no enabled devices associated with it."
Google is failing me as most of the services I see that need to be enabled are.
Related
When logging on windows server to check uptime and services, I am being logged through gateway, both server and gateway are require different credentials.
I am working on powershell script that does this automatically, but I can not find way how to use multiple credentials when invoking command.
I am not sure if there is solution on this in powershell
When doing that manually, I am logging directly on server and gateway automatically pops up, asking for credentials, when I enter them, another prompt to server credentials pops up, then I logon on server.
Thanks for advice :-)
$Cred1 = [pscredential]::new($User1,$Password1) #service account to target server
$Cred2 = [pscredential]::new($User2,$Password2) #gateway credentials
Invoke-Command -ComputerName xxx-ScriptBlock { xxx } -credential $Cred1
...is not working with $Cred1, cause gateway requires $cred2.
Connecting remotely into a windows machine using the OpenSSH service provided by windows always starts an elevated session.
Is it possible to start a non elevated session and elevate after the fact? if so how?
Based on this github discussion: https://github.com/PowerShell/Win32-OpenSSH/issues/1652
bagajjal:
For admin users, ssh connection is an elevated session. Given you are
an admin and has elevated session, you can write to c:\windows.
This is by design.
jborean93:
The biggest issue when you were to use the limited token after an SSH
logon is that you cannot then get your elevated token. On an
interactive logon you can right click and say Run as administrator and
confirm through the UAC prompt but on a network logon like SSH there
is no way for UAC to prompt you. So if this was a functionality you
will never be able to swap from the limited to full token of your
admin account.
I have a network path named P:\ and when I run PowerShell in standard mode I can access it just fine. But when I run PowerShell with Administrative Rights it says it can't find a drive named P:
How to access the path?
When you run PowerShell in standard mode, you say: run PowerShell with the current already authenticated credentials and session and context. This includes all drive mappings inside your current session.
When you run PowerShell as Administrator, the first question is: how do you verify that the Credentials are valid? You can't just look at the username and assume that you can re-use the existing session e.g. you have to explicitly check, exactly at this moment, to see that you are a member of the Administrators group. To validate the credentials, PowerShell performs an authentication check, and in turn, gets a new authentication ticket. This new authentication ticket creates the basis of a new context that your new PowerShell session is running from.
Since it's a new session, running under a completely new context, with new authentication ticket, it inherits no mapped drives because the current administrative session hasn't authenticated with any of your mapped drives. Only your other "non-administrative" or "normal" session has authenticated with any of your mapped drives.
This means that your administrative session starts by default without any mapped drives from your previous session, and it doesn't matter about access or rights, you simply haven't authenticated with your new authentication ticket. This means that, after launching as Administrator, you will have to manually re-map all your drives, as you will have to re-authenticate all the mappings with your new authentication ticket.
Basically, if you need access to mapped drives inside an administrative session, you will need to remap them.
EDIT:
But, as per #ErykSun's comments, #ErykSun brings up the only workaround by setting: EnableLinkedConnections. This is a very specific workaround that only works on GPO mapped drives at logon with the right UAC settings.
This "new session" issue is caused because of the new "feature" Microsoft introduced: UAC elevation (aka. stop running everything as Administrator). In order for certain legacy applications to work, Microsoft had to add this registry Key to create a workaround for mapped drives, e.g. most notably if you need to run something off a mapped drive as administrator (it's a poor user experience to run something off a mapped drive and promptly have it crash because it can't find itself or other files it needs).
How it works is pretty clever. On logon, it will create two sessions at the same time. Your regular non-elevated session, but also an elevated administrative session. At logon, when drive mappings are created, the system creates symbolic link objects that associate the drive letters to the UNC paths.
Note: This is only at logon, and so the caveats are that it only applies to GPO mapped drives.
Drives mapped via login scripts won't work because you have already "started" your session, and there is no link. Same with drives manually mapped during your session. Also when the UAC policy is configured to Prompt for credentials this won't implicitly create the second administrative session (you assume that the user is not an admin) and so running as administrator will create a new session, with the same above issues.
On that note, you can enable it through GPO:
In Local Group Policy Editor, locate the following Group Policy path:
Local Computer Policy\Windows Settings\Security Settings\Local Policies\Security Options
Configure the following policy to Prompt for consent:
User Account Control: Behaviour of the elevation prompt for administrators in Admin Approval Mode
Or via setting the registry key:
Open regedit
Locate and then right-click the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Select 'New' and click DWORD (32-bit) Value
Name it: EnableLinkedConnections
Right-click EnableLinkedConnections, and then click 'Modify'
In the 'Value data' box, type 1, and then click OK.
Exit Registry Editor, and then restart the computer
I tried to deploy report from VS2012 to remote server, and when deploy I got error:
"The permissions granted to user 'SERVER\User2' are insufficient for performing this operation."
Deploy work excellent from other developer machine.
Problem is obviously that User2 doesn't have enough permission.
When deploy report from VS, I usually got popup window where I specified username and password. In this case, I don't have any popup to define user for deploy.
Instead of User2 there must be User but I don't know how to change them, it looks like user is preserved somewhere, I don't get popup for credentials.
User and User2 both exists on remote server as account, but User has administrator privilege, and this is first account
According to < Windows via C/C++ >:
With Windwos Vista, if a user logs on
to the system with an account that
grants high privileges such as Admin,
in addition to the security token
corresponding to this privileged
account, a filtered token is also
created but granted only with the
privileges of a Standard User.
I am wondering, if a user logs on to the system with an account that is even less privileged than Standard User, does the system still create some extra filter token for it? I don't think it is necessary and it doesn't make any sense for the system to do that.
Thanks.
The short answer is that unless the user is an administrator, only a single token is present to represent the user.
When a standard user logs on to a computer a new logon session is created and they are presented with a shell application such as Windows Explorer that was created by the system and associated with the user’s newly created logon session by means of a token. This effectively limits what the user can do since Windows Explorer can only run those applications and access those resources that the user’s logon session permits based on the permissions and privileges specified by the token.
When an administrator logs on to a computer things are a little different and this is where Windows Vista (and Windows 7) differs dramatically from previous versions. Although the system creates a new logon session, it creates not one but two different tokens representing the same logon session. The first token grants all the permissions and privileges afforded to the administrator while the second token is a restricted token, sometimes called a filtered token, offering far fewer permissions and privileges. This restricted token offers practically the same capabilities and constraints as would be granted to a standard user. The system then creates the shell application using the restricted token. This means that although the user is logged on as an administrator, applications are by default run with limited permissions and privileges.
When the administrator needs to perform some task that requires additional permissions or privileges not granted to the restricted token, he or she can elect to run an application using the full security context provided by the unrestricted token. What protects the administrator from malicious code is that this elevation to the unrestricted token is only allowed after the administrator has confirmed the desire to use the unrestricted token by means of a secure prompt provided by the system. Malicious code cannot suppress this prompt and thereby gain complete control over the computer without the user’s knowledge.
When the built-in Administrator account logs on to a computer it appears as if it is treated differently to other users that are part of the Administrators group because it doesn’t receive elevation prompts. This is controlled by a group policy setting entitled “User Account Control: Admin Approval Mode for the built-in Administrator account”. Admin approval mode refers to the elevation prompt that requires an administrator to approve the elevation to the unrestricted token. By default this group policy setting is disabled which means that when the built-in Administrator logs on to a computer it only receives a single unrestricted token. If you enable this group policy setting then the built-in Administrator account will receive a new logon session with two tokens just like the other users that are part of the Administrators group.