Why would $env:username and [environment]::username return different users? - powershell

What is the difference between PowerShell's $env:username and [environment]::username and why would they potentially return different users? (I understand there are other ways to get the current user as well)
Some background:
I have an Azure Pipeline that runs a PowerShell script on a release target. The pipeline agent is configured to run under a specific service account. Part of that PowerShell script uses $env:username to assign permissions. However, permissions are assigned to the local admin account instead. If I change the script to use [environment]::username the correct service account user is given permissions.

$env:USERNAME, while predefined to reflect the current user's username, is a read-write environment variable, just like any other.
Even though it's obviously inadvisable to do so, a statement such as $env:USERNAME = 'foo' changes the value of environment variable USERNAME for the current process as well as its child processes.
This means that if environment variable USERNAME was modified earlier in the same session or in PowerShell's parent process, possibly via an explicitly specified startup environment, it no longer reflects the true username.
While I don't know why the USERNAME environment variable would differ from the real account in the case of Azure Pipelines, an example of - inadvertently - setting the wrong value is PowerShell's Start-Process cmdlet when given the -UseNewEnvironment switch: due to a bug as of PowerShell Core 7.0.0-preview.5 / Windows PowerShell v5.1, $env:USERNAME unexpectedly always reflects SYSTEM, irrespective of the actual user account - see this GitHub issue.
By contrast, [Environment]::UserName uses a different method for obtaining the current user's username, which does not rely on the value of $env:USERNAME and always reflects the true username[1].
In short: Only [Environment]::UserName reliably reflects the current user account's username.
[1] From the linked docs: "On Windows the UserName property wraps a call to the Windows GetUserName function. The domain account credentials for a user are formatted as the user's domain name, the \ character, and user name. Use the UserDomainName property to obtain the user's domain name and the UserName property to obtain the user name.
On Unix platforms the UserName property wraps a call to the getpwuid_r function.

$env: is looking at your environmental variables. The variable that you're looking at- username- happens to be set to the local username by default. But it doesn't have to be.
[Environment] is a call to the System.Environment class in .NET Framework. This class has a property called UserName that contains the username that is logged into the computer.
Similiar names, but very different things. You could get the path statement by $env:Path, for example, or call [Environment]::Version to get the version of .NET Framework.
Note in this example I deliberately messed with the local environmental variable prior to launching PowerShell to give the wrong username.
C:\WINDOWS\system32>echo %username%
mspow
C:\WINDOWS\system32>set username=bob
C:\WINDOWS\system32>echo %username%
bob
C:\WINDOWS\system32>powershell
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
PS C:\WINDOWS\system32> echo $env:username
bob
PS C:\WINDOWS\system32> [Environment]::Username
mspow
PS C:\WINDOWS\system32> echo $env:ProgramFiles
C:\Program Files
PS C:\WINDOWS\system32> echo $env:path
C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\dotnet\;C:\Users\mspow\AppData\Local\Microsoft\WindowsApps
PS C:\WINDOWS\system32> [Environment]::Version
Major Minor Build Revision
----- ----- ----- --------
4 0 30319 42000
You can see all of the available environment variables by using
Get-Item -Path Env:
The only way I know of to see all of the Methods and Properties for [Environment] is the link to the MSDN site. Get-Member doesn't work on it.

Related

Get the permissions of an Active Directory schema object

PS Version: PowerShell 7+
OS Version: Windows Server 2016
Objective: I would like to use PowerShell to get the permissions of an AD schema object without the need of the Active Directory PsDrive / PsProvider.
The Active Directory PsProvider that comes with the AD Module does not work with PowerShell 7+ on Windows Server 2016 from my testing. This MS documentation also touches on that. Because that PsProvider is needed to create/use an Active Directory PsDrive, you can't access AD objects like this AD:\. Using this method is typically what I prefer. Below is an example of exactly what I need except I'm using Windows PowerShell and not PowerShell 7+.
This gets the configuration schema permissions:
(Get-Acl "AD:$((Get-ADRootDSE).schemaNamingContext)").Access
An example of the distinguished name for that object:
CN=Schema,CN=Configuration,DC=my,DC=domain,DC=com
With the limitations outlined, what other options within PowerShell 7+ can I use to access those permissions?
• According to the command that you have run on powershell in Windows Server 2016, it displays the active directory schema permissions of the concerned domain. But when running this command in my environment with Powershell 7.0+ installed as you can see in the image below, I got the same appropriate output as in normal powershell.
• Though you can change the permissions relating to schema objects by using the query as given below: -
Add ACL rule for the right "Read-write all properties/this object and all descendants" –
$rootdse = Get-ADRootDSE
$extendedrightsmap = #{}
Get-ADObject -SearchBase ($rootdse.ConfigurationNamingContext) -LDAPFilter `
"(&(objectclass=controlAccessRight)(rightsguid=*))" -Properties
displayName,rightsGuid |
% {$extendedrightsmap[$_.displayName]=[System.GUID]$_.rightsGuid}
$extendedrightsmap
Please find the below link for more information: -
https://social.technet.microsoft.com/wiki/contents/articles/51121.active-directory-schema-update-and-custom-attribute.aspx

How to get an Azure Active Directory username in Windows Powershell?

I'm trying to get the current Windows username & domain from Powershell on a Windows 10 Azure Active Directory (AAD) joined machine.
I've tried the tips at this question, but none of them seem to work for Azure Active Directory-joined machines.
e.g. for the user: Jonathan Doe, john#example.com you'll get only the users' proper name & AzureAD (not their username or 'real' domain):
$env:UserName --> JonathanDoe
$env:UserDomain --> AzureAD
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name --> AzureAD\JonathanDoe
Does anyone know how to get any part of the user's actual credential or specific Azure AAD domain? (e.g. john or example.com or ideally john#example.com)
You can run the following command in PowerShell, the output will display the user name in UPN format.You can get both of the username and domain name from that.
whoami.exe /UPN
In addition, the program 'whoami.exe' provides many other parameters for getting additional information about current user. You can type the following command for more details about 'whoami.exe'.
whoami.exe /?
I'm not sure how official this is, but I found a link in the registry that contains the username which is user#company.com. This was under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IdentityStore\Cache\xxx\IdentityCache\xxx. The key name was UserName. You can use the built-in powershell registry provider to navigate to this registry entry.

SID for Administrators group doesn't show in a member account

Now, before I start, I will let you in on a secret: this is on a Domain Controller.*
*The above statement is stricken due to irrelevance as the only significant change that occurs to the Local Administrator account and the Local Administrator Group (within the context and scope of this question) is minimal and doesn't alter the outcome enough to require differentiation.
I didn't have this kind of trouble on any of the other servers and I am willing to bet that the reason behind it is because it is on a DC.*
*Same reason as stated above. The accepted answer explains the inconsistency and was an oversight on my part, not the architecture (read features) of Windows Security or Domain Controllers.
I have been playing around with a few ideas on how to check if a script has been called from an account that is either the local Administrator or, at the very least, called by an account that is part of the Local Administrators group.
I have renamed the local Admin account, however, I know that I can see if the script has been called by local Admin account by typing:
(New-Object System.Security.Principal.NTAccount('reserved')).Translate([System.Security.Principal.SecurityIdentifier]).Value
and I can see if the SID ends in -500.
The problem occurs when I run a condition to see if the calling account is part of the Administrators group (which is a larger scope) by typing:
PS> [bool](([System.Security.Principal.WindowsIdentity]::GetCurrent()).Groups -match "S-1-5-32-544")
PS> False
A quick check to see what account it was using:
PS> $env:username
PS> reserved
or the needlessly complicated way (though I prefer it sometimes):
PS> Write-Host ((Get-WmiObject Win32_Account | ?{$_.SID.Substring($_.SID.Length-4,4) -eq '-500'}).Caption).Split("\",2)[1] -fore GREEN
PS> reserved
and I even type:
PS> net user reserved
where it tells me Local Group Memberships *Administrators.
I pull up ADUC (dsa.msc) and I look in the Builtin container and double-click on the Administrators group. I select the Members tag and lo, and behold, reserved is actually a member!
So, a recap:
By typing net user reserved, I was able to verify it was part of the Local Administrators group
I looked in ADUC and verified reserved was a member of the builtin Administrators group
I ensured reserved was indeed the Local Administrator account by verifying the SID started with S-1-5... and ended with ...-500
To take it a step further, I made sure the SID matched the Active Directory Group named "Administrators" by typing Get-ADGroup -Identity "Administrators". I then typed Get-ADGroupMember -Identity "Administrators" and made sure reserved was listed (it was AND the SID matched!).
When I check to see if the well-known Administrators Group SID is found in the Groups of that account (by getting the current Windows Identity), it says that it isn't.
What gives?
Why do I get every indication that it actually is a member of the Local Administrators group but that SID isn't found in the account's groups?
When a computer is promoted to a domain controller, there are no more local users or groups on the machine. Member computers have local users and groups, and can also use domain users and groups for authentication, but on a DC, there are only domain objects.
See also: https://serverfault.com/a/264327/236470
I happened to stumble across something and I realized the answer to this question. For the sake of those that come here looking for assistance, here is the answer to my question:
Very simply--in regards to Powershell--if the Administrator Group SID (S-1-5-32-544) does not show up in the Groups of the user, that is a first-line indication that the script is not running with Administrative credentials.
For example, when I type out:
([Security.Principal.WindowsIdentity]::GetCurrent()).Groups
and I do not see the Administrator Group SID listed even though I know for a fact that the account I am signed into is a member of the Administrator Group, it means the current Powershell process does not have Administrative credentials.
If you click Run As Administrator and type the same as above, you will see that it lists the Administrator Group SID in Groups.
The reason why I was experiencing the inconsistency is simply because I was not running the Powershell process as an Administrator.
So, in short, there are a few ways you can check to verify if your current Powershell session has Administrator credentials. The first one is found in countless websites around the internet and is very common (I did not write this one):
$myWindowsID = [Security.Principal.WindowsIdentity]::GetCurrent()
$myWindowsPrincipal = New-Object Security.Principal.WindowsPrincipal($myWindowsID)
$adminRole = [Security.Principal.WindowsBuiltInRole]::Administrator
if($myWindowsPrincipal.IsInRole($adminRole)) {
\\ TODO: Process is running as Administrator
Clear-Host
} else {
$newProcess = New-Object System.Diagnostics.ProcessStartInfo "Powershell"
$newProcess.Arguments = "& '" + $script:MyInvocation.MyCommand.Path + "'"
$newProcess.Verb = "runas"
[System.Diagnostics.Process]::Start($newProcess)
exit
}
Here is another way (I did write this one):
[Security.Principal.WindowsIdentity]::GetCurrent() | %{
if($_.Groups -contains "S-1-5-32-544") {
\\ TODO: Process is running as Administrator
Clear-Host
} else {
Start Powershell -ArgumentList "& '$MyInvocation.MyCommand.Path'" -Verb runas
exit
}
}
# The Foreach-Object (%) could be replaced with another pipeline filter
I see a lot of people asking this question and because of Powershell appealing to many Systems Administrator (especially ones without a background in programming), I really think this will come in handy for others down the line.

Specify domain controller with get-aduser in powershell

Get-ADUser -identity $ntaccount1 -properties name, samaccountname, mail, enabled, passwordlastset
Is it possible, when looking up the user account information in powershell, to specify a domain controller to use? We have some DC's that get the data faster than others.
From Get-Help Get-ADUser -Parameter *
-Server <string>
Specifies the Active Directory Domain Services instance to connect to, by providing one of the following values for a
corresponding domain name or directory server. The service may be any of the following: Active Directory Lightweight Domain
Services, Active Directory Domain Services or Active Directory Snapshot instance.
Domain name values:
Fully qualified domain name
Examples: corp.contoso.com
NetBIOS name
Example: CORP
Directory server values:
Fully qualified directory server name
Example: corp-DC12.corp.contoso.com
NetBIOS name
Example: corp-DC12
Fully qualified directory server name and port
Example: corp-DC12.corp.contoso.com:3268
The default value for the Server parameter is determined by one of the following methods in the order that they are listed:
-By using Server value from objects passed through the pipeline.
-By using the server information associated with the Active Directory PowerShell provider drive, when running under that drive.
-By using the domain of the computer running Powershell.
The following example shows how to specify a full qualified domain name as the parameter value.
-Server "corp.contoso.com"
Required? false
Position? named
Default value
Accept pipeline input? false
Accept wildcard characters? false
I know that this is a bit of an old question, but I would like to expand on the answer given, to aid anyone else who had a similar query.
The following allows you to define a specific Domain Controller, which the entire of a script would be able to use... Why might you want to do this when the -server parameter is available to Get-ADUser, New-ADUser, Set-ADObject, etc?
Well I put together a script that creates an AD user, sets multiple properties and creates an exchange mailbox - However, one set of properties revolves around the RDS properties on a 2008 R2 user account, which cannot be set from within New-ADUser. I had to create a function that calls ADSI and uses psbase.invokeSet to update the settings. There is no parameter setting for -server that I'm aware of.
This in itself wouldn't be a big deal, but the script also creates an Exchange mailbox for the user. As my Exchange server is in different AD Site from my workstation, the user account gets created on my local DC, but the mailbox isn't set, because the DC in the same site as the Exchange server hasn't yet received a replicated copy of the new user account.
The solution I found is as follows and is courtesy of http://www.joseph-streeter.com/?p=799
Having loaded import-module activedirectory, you'll have access to AD options in the New-PSDrive commandlet which among everything else allows you to define a new Active Directory Provider to work with.
New-PSDrive -Name <<NameofYourChoice>> -PSProvider ActiveDirectory -Server <<DC Server>> -Root "//RootDSE/" -Scope Global
Once created, you can then change the working Provider with the following command.
CD <<NameofYourChoice>>:
To view the existing list of Providers, type Get-PSDrive. AD is the default Active Directory Provider created when using the ActiveDirectory commandlet. You should also see your newly created Provider.
So for instance if my remote DC is called RemoteDC I would run:
New-PSDrive -Name RemoteAD -PSProvider ActiveDirectory -Server RemoteDC -Root "//RootDSE/" -Scope Global
to create a new Provider called RemoteAD. If I then run:
CD RemoteAD:
All further active directory related commands in the script or the active shell will work with the new Provider RemoteAD. If I would need to change back to my original Provider, I'd simply type
CD AD:
Hope someone finds this useful...
This is what i use:
Get-ADUser -server dcservername.domain.local -identity username

How can I tell if I'm in a remote PowerShell session?

I would like to execute code that is specific to remote PSSessions. That is, the code doesn't apply locally, but applies to all remote sessions.
Is there any environment variable, function or cmdlet that would effectively return true if I'm in an active PSSession and false if I'm running locally?
Check if the $PSSenderInfo variable exists. From about_Automatic_Variables:
$PSSenderInfo
Contains information about the user who started the PSSession,
including the user identity and the time zone of the originating
computer. This variable is available only in PSSessions.
The $PSSenderInfo variable includes a user-configurable property,
ApplicationArguments, which, by default, contains only the
$PSVersionTable from the originating session. To add data to the
ApplicationArguments property, use the ApplicationArguments parameter
of the New-PSSessionOption cmdlet.
You could also test using this:
If ( (Test-Path variable:PSSenderInfo)
        -and ($Null -ne $PSSenderInfo)
        -and ($PSSenderInfo.GetType().Name -eq 'PSSenderInfo') ) {
    Write-Host -Object "This script cannot be run within an active PSSession"
    Exit
}
This was not my initial finding, but it helped with "variable PSSenderInfo not set" issue, if it doesn't exist.