I found this post helpful. PowerShell - User Must Change Password at Next Logon
Is it possible to force a user to set a password on next sign in by using something like this?
Set-LocalUser -ChangePasswordAtLogon:$true
I get a NamedParameter error when trying the script above.
What's the best way to force a local user account to reset a password upon login?
The Set-LocalUser cmdlet does not have a parameter ChangePasswordAtLogon
Try
Set-LocalUser -Name "TheUser" -PasswordNeverExpires $false
or use
$user = [ADSI]"WinNT://$env:ComputerName/TheUserName,user"
$user.PasswordExpired = 1
$user.SetInfo()
From how it looks, the Set-LocalUser doesn't have a force password change, the post you referenced is for ActiveDirectory users. Looking at this SuperUser post, there is a workaround using net user and wmic that you could code in PowerShell to emulate it:
Here's what I found worked for me on Windows 10 Home.
wmic UserAccount where name='John Doe' set Passwordexpires=true
Followed by
net user "John Doe" /logonpasswordchg:yes
Related
I am attempting to make a new local user account working on my actual host machine through the administrator powershell terminal page. I ran the code below successfully and saw the account populate the computer management>User page but I was not able to select my new account through the lock screen nor through the start>account page neither. I tried restarting the host machine, but there was still no option to sign in as this new user through start menu account options, ctrl alt delete nor switch user.
#Community, Do you have any modifications you would make to these commands listed below to make the new user account populate to the front end to be selectable to log in through the user sign in page?
'''
PS>$Password = Read-Host -AsSecureString
PS>New-LocalUser -AccountNeverExpires -Description "Test" -FullName "John Smith" -Name john.smith -
Password $Password -Confirm
'''
Any help will be appreciated - thanks.
John.Smith must be member of at least one local group.
Put him in "Users" group, it will appear at the logon screen.
#Christophe, Success!! Yes thank you! Awesome! I can now see the user john.smith as a selectable user to login at the windows start up screen and all other account screens.
Much appreciated! Here is the commands to create a new user using powershell as a whole with #Christophe's answer included. Thanks again! FYI there are no odd spaces in solutions below I just can't get them all on one line in a comment.
'''
PS>$Password = Read-Host -AsSecureString
PS>New-LocalUser -AccountNeverExpires -Description "Test"
-FullName "John Smith" -Name john.smith
-Password $Password -Confirm
PS>Add-LocalGroupMember -Group "Users" -Member "John.Smith"
'''
Afternoon folks,
I've got a quick question. I'm making a script to make local user accounts based off a csv file. I have it all working no problem using the New-LocalUser command. What I am curious about is there a parameter string I can add or anything to have it so the user Has to change the password upon first login?
I've looked through https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.localaccounts/new-localuser?view=powershell-5.1 I just was wondering if there was something I've missed.
You haven't. Most of the time, when cmdlets are released, they don't include all functionality for a particular technology (e.g. Get-Service versus Win32_Service). In this case, New-LocalUser, Get-LocalUser, Set-LocalUser are in this boat.
However, in order to achieve what you're after, the WinNT provider has exposed this functionality for a long time:
$u = New-LocalUser -Name test -Password ('123456789' | ConvertTo-SecureString -AsPlainText -Force)
$WinNt = [adsi]"WinNT://localhost/$($u.Name)"
$WinNt.PasswordExpired = 1
$WinNt.SetInfo()
I'm interested in a PowerShell script working example that ONLY asks for an Active Directory UserName and Domain and new Password as input parameters:
...and, forces this change as (fast as possible) to replicate with the entire forest.
The purpose of this script is to let Exchange, SkypeforBusiness (and other systems) to recognize this password change across the forest; so, these systems don't keep prompting the logged in user for the new password immediately after the password change sent to a single DC (even, after the user logs off and logs back in again successfully to their workstation using their new password). Maybe, forcing replication to the just the bridgehead servers in the user's site / domain is good enough?
I know how to change a user's password with the below 3 lines in an AD Domain. However, I'm not sure how to replicate that change across the entire forest ASAP.
$Domain = "DomainName"
$UserID = "BillKP"
$newpwd = "pass123"
$DC = Get-ADDomain $Domain | select -ExpandProperty InfrastructureMaster
Set-ADAccountPassword $UserID -NewPassword $newpwd -Reset -Server $DC
I found the below example for Sync-ADObject. However, I'm not sure how to use it with the above script (presuming my intentions mentioned above).
PS: I don't want to lock up the PowerShell console when forcing replication of this user's new password to the forest.
Get-ADDomainController -filter * | ForEach {Sync-ADObject -object "CN=James, OU=BusinessUsers, DC=Test, DC=Local" -source NKAD1 -destination $_.hostname}
Thanks in advance!
I have a simple .ps1 file:
$Server="remotepc.company.net"
$User=".\login"
$Password="password"
cmdkey /generic:TERMSRV/$Server /user:$User /pass:$Password
mstsc /v:$Server /h:1080 /w:1920
And anyway it asks for a password.
In RDP, go to the option checked to always ask for credentials:
Launch RDP → Show options → *un-check Always ask for credentials.
It seems, even though you gave credentials correctly, this was still making RDP ask.
The issue was in $User=".\login".
login is a local user name (not domain).
So to force it to work:
$User="localhost\login"
You could try:
$Server="remotepc.company.net"
$User="localhost\login"
$Password="password"
$SecurePassword = $Password | ConvertTo-SecureString -AsPlainText -Force
cmdkey /generic:$Server /user:$User /pass:$SecurePassword
mstsc /v:$Server /h:1080 /w:1920
I have the below PowerShell script (myscript.ps1) in which I ask for username and password. Depending on the username and password it copies a file to a certain destination.
$credentials = Get-Credential
if ($credentials.Username -eq "user1" -And $credentials.GetNetworkCredential().password -eq "pass1")
{ Copy-Item "test1.pdf" "\test\test1.pdf"; }
else
{ Copy-Item "test2.pdf" "\test\test2.pdf"; }
Requirement: I want to make this file protected so no one can edit it and see the username and password.
PS2EXE
I found a solution found here which converts the PowerShell script to an .exe file. When I originally run the script using PowerShell a dialog box appears allowing me to enter the username and password:
After the .exe is generated and when I run it the credentials dialog box no longer appears. Instead, the console appears saying "Credential:"
I don't know why? I want the credentials form to still appear when running the exe. Any thoughts please?
Q: Why does the EXE prompt with "Credential"?
This isn't an answer to the real question, and is based on guessing/supposition about PS2EXE, but I hope it is useful to clear up some confusion.
Having looked briefly at the PS2EXE page linked above, it seems that this utility encodes the script in Base64 and bundles it with a lightweight (?) custom PowerShell host. When run, I suppose the EXE starts the host, decodes the script and runs it.
The problem is that the Get-Credential cmdlet is running within a PS host that probably can't interact with the desktop. That is, it can't put up the GUI prompt for credentials. It therefore needs to prompt for the Credential property on the command line, explaining why you see that behaviour.
Workaround with Read-Host?
Instead of trying to use Get-Credential to prompt for username and password, you could embrace what PS2EXE seems to be doing and just use Read-Host:
$UserName = Read-Host "Enter username"
$Password = Read-Host "Enter password" -AsSecureString
$Credentials = New-Object System.Management.Automation.PSCredential $UserName,$Password
if ($credentials.Username -eq "user1" -And $credentials.GetNetworkCredential().password -eq "pass1")
{ ... }
Using -AsSecureString will hide the password on the screen. The $Password variable will be of type System.Security.SecureString, which can be used to create a PSCredential object as shown.
You'd need to test this, but it seems that you're able to read from the shell but not from a GUI prompt.
And just to be clear: none of this is anywhere near best-practice security. If you need authentication/authorization for these activities, step back and look at the problem again.
Workaround with two scripts?
It seems that PS2EXE doesn't support -AsSecureString in the same way that normal PowerShell does, i.e. it doesn't hide the characters. A possible workaround for this would be to collect the username and password from the user in one script and then pass them to a PS2EXE-converted script for processing.
Launch-MyScript.ps1:
$Credentials = Get-Credential
& MyScript.exe $Credentials.Username $Credentials.Password
MyScript.exe (coverted with PS2EXE):
param($Username,$Password)
$Credentials = New-Object System.Management.Automation.PSCredential $Username,$Password
if ($Credentials.Username -eq "user1" -and
$Credentials.GetNetworkCredential().password -eq "pass1")
{
...
}
The user runs Launch-MyScript.ps1 and completes the password prompt. Then the EXE is run automatically with the username and password passed in as arguments. Note that, as shown above, the password is a Secure String. Test this; I'm not using PS2EXE so it's a theoretical solution at the moment.
If you can't pass $Password along the pipeline as a Secure String object, you can convert it to text with ConvertFrom-SecureString in the first script, then conver it back with ConvertTo-SecureString in the second one.
According to this article http://windowsitpro.com/powershell/protect-your-powershell-scripts you should first set ur execution policy to AllSigned by Set-ExecutionPolicy AllSigned, then create a certificate using makecert cmdlet.
Then u can sign single script using Set-AuthenticodeSignature cmdlet or use .pfx File to Sign a Script which appears even safer.
Hope it helps a bit.