How to view user privileges using windows cmd?

[Origin]: http://stackoverflow.com/questions/11607389/how-to-view-user-privileges-using-windows-cmd

I’d start with secedit /export /areas USER_RIGHTS /cfg OUTFILE.CFG. Then examine the line for the relevant privilege. However, the problem now is that the accounts are listed as SIDs, not usernames.

shareedit

answered Jul 27 ’12 at 22:48 Simon Catlin 1,520711

This is pretty horrible to use but it works well. After exporting the template using Simon’s command above, you can import it again using: Secedit /configure /db secedit.sdb /cfg outfile.cfg /quiet /areas USER_RIGHTS– NikG Mar 20 ’15 at 17:51

How To Resolve Active Directory Account Lockouts With PowerShell

[Originally posted by]: http://www.tomsitpro.com/articles/powershell-active-directory-lockouts,2-848.html

Active Directory (AD) is a wonderful service. You can log on from anywhere on the network using the same username and password. It couldn’t be easier — that is, until you forget to close a remote desktop session, or a worm spreads across the network, or you forget you’re running a scheduled task as your user account, or… Well, you get the point.AD is an extremely useful product; this is why its adoption rate is so high. The problem is when an account begins to lock out for no reason whatsoever.Or so you think.

MORE: Essential PowerShell Cmdlets for Active Directory

AD Account Lockout Policies

Many organizations have (or should have) account lockout policies. This policy is a securitymeasure to prevent unauthorized parties from trying to guess the password continuously or brute force a password.Account lockout policies are commonplace in Active Directory and consist of a simple approach to combating a major security issue.Attempt the wrong password a certain number of times, and the account is unusable until an administrator manually re-enables it again. The intention is true, but in some instances, the implementation is not.

In some situations, especially when a password is changed, an account can suddenly start getting locked out consistently for no apparent reason. A user calls the help desk, the help desk re-enables the account, and a little bit later, the account is locked out again. It’s a frustrating experience for both the user and the help desk. Sometimes the problem is exacerbated by the unknown origin of the lockouts. Somewhere, somehow there’s a person, a script, or a process continually trying the same wrong password over and over again, but no one knows where.

So how do you track down these annoying lockouts? One way is by using a PowerShell script. But first, let’s go over what happens when an account is locked out.
Resolving A Locked AD Account

In a Windows Server 2008 or later environment, there is a short back and forth between the client system, the client system’s domain controller, and the domain controller holding the Primary Domain Controller (PDC) emulator role. This occurs as follows:

Whenever a user account authentication is attempted, the credentials are sent up to the appropriate domain controller for the client system’s subnet.
If the password is wrong, the client system’s domain controller forwards the request to the domain controller holding the PDC emulator role. This is because the client system’s domain controller might not have the most current password, and as a design feature of Active Directory, the domain controller holding the PDC emulator role always will.
The PDC emulator tries the password again, and if it is still found to be wrong, the PDC emulator increments the badPwdCount attribute on the user account.
An event ID 4740 is generated on the PDC emulator with the client system IP address that initiated the original request and with the user account.
The PDC emulator then informs the client system’s domain controller that the password is, in fact, wrong.
The client system’s domain controller then notifies the client system that the password was wrong.
Where would be the best place to find the source? The answer is at the PDC emulator. The reason for that is because every account lockout is recorded there in the security event log. The PDC emulator is a central place that can be queried for all account lockout events.

Using PowerShell To Track Down The Source Of AD Account Lockouts

To query the PDC emulator, we’ll use PowerShell’s Get-WinEvent cmdlet. This is an extremely useful cmdlet for quickly parsing through one or more event logs on a server. We’re looking for an event ID of 4740. First, we need to find the domain controller that holds the PDC emulator role. One way to do this is by using the Get-AdDomain cmdlet.

Once we know the PDC emulator, then it’s just a matter of querying its security event log for event ID 4740.

I have an account called abertram that is locked out. Let’s see how to track down the culprit.

We’ve got the PDC emulator now, so let’s query its security log with a PowerShell script.

## Define the username that’s locked out
$Username = ‘abertram’
## Find the domain controller PDCe role
$Pdce = (Get-AdDomain).PDCEmulator
## Build the parameters to pass to Get-WinEvent
$GweParams = @{
‘Computername’ = $Pdce
‘LogName’ = ‘Security’
‘FilterXPath’ = "*[System[EventID=4740] and EventData[Data[@Name='TargetUserName']='$Username']]"
}
## Query the security event log
$Events = Get-WinEvent @GweParams

This gives us the lockout event.

But we don’t have the originating client system yet. To get that, we’ll have to dig a little deeper. The actual username is buried in each event’s Properties value. To find the username in each event, we can simply use this line.

$Events[0].Properties[0].Value

This finds the username in the first event and in the first instance of the Properties value. Luckily, the client system is just in the second instance of Properties.

$Events[0].Properties[1].Value

Once you know where the client system name is located, it’s just a matter of inserting it into a loop, and we’ve found the culprit.
Now you’re armed and ready to go the next time the help desk rings you with that incessant AD user account that keeps getting locked out.

Powershell ps1 file “is not recognized as a cmdlet, function, operable program, or script file.”

http://stackoverflow.com/questions/762927/powershell-ps1-file-is-not-recognized-as-a-cmdlet-function-operable-program

This is a typical error across many platforms where your environment path does not include your current directory. so when you execute your script (or command or program etc), your runtime environment looks everywhere except your current/working directory.

Try

PS> .\listAllPaths.ps1 c:\ *.pdf testingPDF.txt

EDIT: After reading your comments, I’m going to suggest you try this. I haven’t actually verified the logic of your PS script. I’m merely trying to get your script to execute first.

Try editing your script as below, and execute as above.

Function listAllPaths([string]$fromFolder, [string]$filter, [string]$printfile){
Get-ChildItem -Path $fromFolder -Include $filter -Recurse -Force -Name > $printfile
}

listAllPaths

shareedit

edited Apr 18 ’09 at 5:14

answered Apr 18 ’09 at 5:00 Chaitan 11316

PowerShell says “execution of scripts is disabled on this system.”

[From:] http://stackoverflow.com/questions/4037939/powershell-says-execution-of-scripts-is-disabled-on-this-system

773down voteaccepted

If you’re using Windows 2008 R2 then there is an x64 and x86 version of PowerShell both of which have to have their execution policies set. Did you set the execution policy in both hosts? You can set the execution policy by typing this into your powershell window: Set-ExecutionPolicy RemoteSigned For more information see here. shareedit edited Apr 14 ’15 at 23:55 Jason Pyeron 734819 answered Oct 28 ’10 at 1:16 Chad Miller 11.7k21624