Net User $userName /domain - windows

I am trying to create a module for our support team which will contain some tools we use on daily basis but we used CMD until now.
One of the commands we use is net user $username /domain in order to check if the user's password has expired and all the other useful details the command output.
I tried to put that command in a function like this:
function Get-UserDetails {
[CmdletBinding()]
Param(
[Parameter(Mandatory=$true)]
[string]$UserName
)
net user $UserName /domain
}
The function works fine but I want to filter the output for a few details only.
The problem is that net user is not a PowerShell cmdlet and it has no properties so I cant select any of it.
So my questions is:
Do you know a better way to get all that data in one command? because the Get-ADUser outputs less data then net user.

You can use Get-ADUser and pick the msDS-UserPasswordExpiryTimeComputed property from it. Problem is - this property may not enumerate even when using -Properties *, so it might not be apparent when trying to inspect the returned object. To make matters even better, the timestamp is not in a human-readable format.
Nonetheless, you can get the password expiration date fromthe AD cmdlets and also make it human-readable as follows:
# Get ADUser
$user = Get-ADUser username -Properties msDS-UserPasswordExpiryTimeComputed
# Get expiry timestamp and convert it from file time format
$userCredExpiryDate = [DateTime]::FromFileTime( $user.'msDS-UserPasswordExpiryTimeComputed' )
Here is the MSDN documentation for that AD DS attribute.
For other field values that show up in net user /domain but not in Get-ADUser - there should be other AD DS attributes you can search on if they don't show up with -Properties *. For these you will need to look for the appropriate property in the AD DS documentation.
UPDATE: Someone linked me to this page on another question (related to this behavior) and this seems to list additional properties that are available for processing, but are not returned when trying to look at "all" AD DS properties on an object. I don't know how complete this list is but it is a good starting point for understanding what additional AD attributes you have to work with.

Related

Writing User ObjectID to variable #Powershell

I am looking to find a way to write the Object ID of a user to a variable automatically via AzureAD.
Get-AzureAdUser -ObjectId "Contose#contoso.com"
will give the output of the ObjectId, DisplayName, UPN, UserType
I am looking to the write the ObjectId of the user (e.g qwert_1232_trwwqe) to variable such as $UserId for use further in the script.
Lee Dailey provides a good pointer:
the usual way is to keep things in the $Var and simply address the properties when needed. So, assign the call to a $Var and get the value with $Var.ObjectID.
That said, if you do want to store the object ID alone in a dedicated variable, simply access the .ObjectId property on the object returned by Get-AzureAdUser:
$userId = (Get-AzureAdUser -ObjectId 'Contose#contoso.com').ObjectId
In a follow-up comment you mention arriving at:
$Var = Get-AzureAdUser -ObjectId "Contose#contoso.com" | Select ObjectId
However, this use of the Select-Object cmdlet (whose built-in alias is select) is virtually pointless, as this still returns a (new, custom) object that requires you to access its .ObjectId property in order to retrieve the object ID value - and for that you could have just assigned the object returned by Get-AzureAdUser directly to $Var, as Lee suggests.
It is possible to use Select-Object to extract a single property value, namely via the -ExpandProperty <propertyName> parameter:
$Var = Get-AzureAdUser -ObjectId 'Contose#contoso.com' | Select -ExpandProperty ObjectId
However, the (...).ObjectId syntax (dot notation) is not only more convenient, but also faster - and it even works on multiple objects (in PSv3+), in which case an array of values is returned (a feature called member-access enumeration).
In short, Select-Object -ExpandProperty is only needed if you're processing very large collections that must be processed one by one in the pipeline.

Powershell - Couldn't add 2nd and 3rd date modify parameter

I could manage to retrieve user accounts from DC with their time related parameters like lastlogon, whencreated etc and I could manage to change lastLogon parameter to my prefer (dd.MM.yyyy). But I couldn't make the same conversion to "whenCreated" and "PasswordLastSet" dates.
Get-Aduser -Filter * -Properties *|Select name,SamAccountName,PasswordExpired,description,whenCreated,PasswordLastSet,Enabled,DistinguishedName,DisplayName,GivenName,SurName, #{N='LastLogon'; E={[DateTime]::FromFileTime($_.LastLogon).ToString('dd.MM.yyyy')}} |export-csv C:\result.csv
I need your help on this issue. How can I modify the 3 dates format into my preferrings at the same time.
Thanks..
#{N='whenCreated'; E={$_.whenCreated.ToString('dd.MM.yyyy')}}, #{N='PasswordLastSet'; E={$_.PasswordLastSet.ToString('dd.MM.yyyy')}}
Without 'FromFileTime'.

How to change the Created By field on a Work Item in TFS?

Is there a way to change the Created By field on a work item in TFS? Maybe by altering the database?
I want to be able to create a bug/feature/PBI, then change it to be created by the member of staff who reported it to me.
This way, I can track who is submitted change requests, and they would also then receive bug update notifications.
You can only overwrite the CreatedBy field when create the workitem via API with bypass rule enabled. Refer to this link for details: Make an update bypassing rules.
A quick solution for this would be create a powershell script to create the workitem via Rest API. Sample for your reference:
#Input basic information
$collectionuri = "http://tfsserver:8080/tfs/DefaultCollection/"
$project = "ProjectName"
$workitemtype = 'Task'
$createdby = 'Display Name'
$title = 'Title'
#Create the workitem
$workitem = #(#{op="add";path="/fields/System.Title";value=$title},#{op="add";path="/fields/System.CreatedBy";value=$createdby})
$json = $workitem | ConvertTo-Json -Depth 100
$headers= #{"Content-Type"="application/json-patch+json"}
$url= $collectionuri + $project + '/_apis/wit/workitems/$' + $workitemtype +'?bypassRules=true&api-version=1.0'
$mycredentials = Get-Credential
$wi = Invoke-RestMethod -Uri $url -Method Patch -Credential $mycredentials -Body $json -ContentType 'application/json-patch+json'
Write-Host $wi
Seems you want to set a faker creator for a work item.
Created By
The name of the team member who created the work item.
Reference name=Microsoft.VSTS.Common.CreatedBy
There is no build-in way to change this filed. Take a look at this:
IsEditable
No
Indicates if users can modify this field (True) or not (False).
Examples of non-editable fields are ones that are set by the system, such as the ID, Revision, Created By, and Changed By
fields.
More details please refer Work Item Field Attributes – What You Can and Can’t Change
Change the value directly in the Database may do the trick, but it's not a recommend way. It's also go against the concept of source control.
If you just want to notify others when work item update. As a workaround, suggest you use the follow function in work item.
When you want to track the progress of a single work item, click the Follow icon icon. This signals the system to notify you when changes are made to the work item.
Note: This feature is available from TFS 2017 and above.
Why do you want to update the system field? You may add a new field "Initiator"(Add or modify a field to track work). Set value from Created By on creation. Then update it when you want.

Power shell | Extract user name out of computer name in Domain Controller

How can I extract the user name in my active directory when I only have the computer name.
Obviously, no relation whats or ever between the computer name and the user name in terms of naming.
ArcSet's answer is great (it's what I'd do) but for basic PowerShellers, I'd have pushed them towards the AD-cmdlets like (Mitchell did):
Get-ADUser -Property samaccountname
or even:
Get-ADObject -ldapfilter '(objectcategory=user)' -Property samaccountname
This will get you all users from the domain the current computer is joined to:
(([adsisearcher]“objectcategory=user”).FindAll()).Properties.samaccountname
I recommend utilizing this cmdlet: Get-ADComputer. After getting the AD information associated with this you can pipe the data out and utilize filters to get the information you require. The filter code is also specified within the documentation.
Documentation can be found here: https://technet.microsoft.com/en-us/library/ee617192.aspx
Hope this helps (I'm not 100% sure if this is what you are looking for... The more details in your question the better)!

How to map HKEY_USERS subkeys and Windows usernames?

I thought the key names immediately below HKEY_USERS were supposed to be the usernames of whoever logged in at this machine at some time. But in my machine what appears is:
S-1-5-18
S-1-5-19
S-1-5-20
S-1-5-21-NNNNNNNNN-NNNNNNNNN-NNNNNNNNNN-NNNNN
S-1-5-21-NNNNNNNNN-NNNNNNNNN-NNNNNNNNNN-NNNNN_Classes
I'd like to be able to determine which subtree corresponds to which user. How can I do that?
Edit: WHat I need is to get the usernames from the SIDs. I want to inspect the configurations of each user that has ever logged on, and I need to know their names. For example, in the registry above, I need to be able to, based on the string "S-1-5-21-NNNNNNNNN-NNNNNNNNN-NNNNNNNNNN-NNNNN", find out that it correspond to DOMAIN\somebody, or LOCALMACHINENAME\somebodyelse.
It is possible to query this information from WMI. The following command will output a table with a row for every user along with the SID for each user.
wmic useraccount get name,sid
You can also export this information to CSV:
wmic useraccount get name,sid /format:csv > output.csv
I have used this on Vista and 7 (according to the comments it works on 2008 R2 as well). For more information see WMIC - Take Command-line Control over WMI.
For PowerShell this is quick:
gwmi win32_userprofile | ft localpath, sid
Ashley McGlone
Microsoft PFE
http://aka.ms/GoateePFE
I believe those numbers are the user's security ID (SID). You can use SysInternals to get the SIDs of users:
http://technet.microsoft.com/en-us/sysinternals/bb897417.aspx
HKLM\System\CurrentControlSet\Control\hivelist will show you where the hives are mounted from. While not a direct mapping, usually the mount point has the user name in the path.
I'm sure there is a better answer than this though...
When doing it manually (without extra tools), the easiest way is to open permissions for that key. The only user who has full permissions is the owner of the key.
When from a program, you will need a way to convert SIDs to account names. In C# (or PowerShell), have a look at the SecurityIdentifier and NtAccount class for that.
in C# there is appears to be an answer to translating username to SID here http://community.bartdesmet.net/blogs/bart/archive/2006/09/08/4394.aspx but its only for local PCs.
For AD I converted it to:
using System;
using System.DirectoryServices;
using System.Security.Principal;
class Program {
static void Main(string[] args) {
string path = "LDAP://" + args[0];
DirectoryEntry root = new DirectoryEntry(path, args[1], null, AuthenticationTypes.Secure);
string sid = new SecurityIdentifier((byte[])root.Properties["objectSID"][0], 0).Value;
Console.WriteLine(sid);
}
}
The usage is : programname.exe DOMAIN username
e.g. programname.exe somecompany.com preet_sangha
Please use powershell:
$mydocuments = [Environment]::GetFolderPath("mydocuments")
gwmi win32_userprofile | ft localpath, sid, status -AutoSize | Out-File $mydocuments\userprofiles.txt

Resources