starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Isolated Mode? Logon NetCredentials Only Not Respected In Shell Process #23718

New Issue
Open
opened 2026-01-31 08:50:21 +00:00 by claunia · 2 comments
claunia commented 2026-01-31 08:50:21 +00:00
Owner
Copy Link

Originally created by @mattcargile on GitHub (Oct 16, 2025).

Windows Terminal version

1.23.12811.0

Windows build number

10.0.22631.0

Other Software

No other software.

Notes

The related api is this link, namely, the dwLogonFlags parameter and LOGON_NETCREDENTIALS_ONLY. Switching to wezterm for now because I need this workflow and I can't go back to conhost.exe.

Other Attempts

I use scoop too. I used to be able to make it work by calling WindowsTerminal.exe directly thereby avoiding the shim and soft link. Now even calling WindowsTerminal.exe directly stopped working.

Steps to reproduce

Can use ProcessEx or native binary runas.exe.

Install-Module ProcessEx
start-processwith -FilePath wt -Credential (get-credential domain\user) -NetCredentialsOnly
# or
runas /netonly /user:domain\user wt

Expected Behavior

When using Invoke-Command -ComputerName remote -ScriptBlock { whoami } or the like should return the net credential user name.

Actual Behavior

When using Invoke-Command -ComputerName remote -ScriptBlock { whoami } or the like the local non network only credential user is returned.

Workaround

So it appears this is related to wt and WindowsTerminal avoiding creating a brand new process when one already exists. So I was inheriting from the previous process so my net only cred was being ignored.

Solution is to open conhost first and then launch wt making sure that there isn't already a window opened.

It would be nice if there was a way to launch a brand new process though. It appears one is only able to have one wt process open at once.

Originally created by @mattcargile on GitHub (Oct 16, 2025). ### Windows Terminal version 1.23.12811.0 ### Windows build number 10.0.22631.0 ### Other Software No other software. #### Notes The related api is this [link](https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createprocesswithtokenw#parameters), namely, the `dwLogonFlags` parameter and `LOGON_NETCREDENTIALS_ONLY`. Switching to `wezterm` for now because I need this workflow and I can't go back to `conhost.exe`. #### Other Attempts I use `scoop` too. I used to be able to make it work by calling `WindowsTerminal.exe` directly thereby avoiding the _shim_ and _soft link_. Now even calling `WindowsTerminal.exe` directly stopped working. ### Steps to reproduce Can use [`ProcessEx`](https://github.com/jborean93/processex) or native binary `runas.exe`. ```pwsh Install-Module ProcessEx start-processwith -FilePath wt -Credential (get-credential domain\user) -NetCredentialsOnly # or runas /netonly /user:domain\user wt ``` ### Expected Behavior When using `Invoke-Command -ComputerName remote -ScriptBlock { whoami }` or the like should return the net credential user name. ### Actual Behavior When using `Invoke-Command -ComputerName remote -ScriptBlock { whoami }` or the like the local non network only credential user is returned. #### Workaround So it appears this is related to `wt` and `WindowsTerminal` avoiding creating a brand new process when one already exists. So I was inheriting from the previous process so my net only cred was being ignored. Solution is to open `conhost` first and then launch `wt` making sure that there isn't already a window opened. It would be nice if there was a way to launch a brand new process though. It appears one is only able to have one `wt` process open at once.
claunia added the Issue-BugPriority-3Product-TerminalArea-Remoting labels 2026-01-31 08:50:21 +00:00
claunia commented 2026-01-31 08:50:22 +00:00
Author
Owner
Copy Link

@jborean93 commented on GitHub (Oct 16, 2025):

I've had a look into this and it seems like wt.exe and the direct WindowsTerminal.exe works like VSCode in that if no existing WT processes are running it'll continue running as the WT process. If a new WT process is started it'll communicate back with the first WT process to open a new window and the new process exits. This means that WT only ever has 1 process running outside of an limited vs elevated through UAC context.

The only way around this is to ensure that the first WT instance was launch with the /netonly argument which could be done by using conhost directly. This would mean that any new console process' started normally would also inherit this output network credential. Another alternative is to see if there is any flag on wt.exe to force it to use a new process but I'm unsure if this is possible.

@jborean93 commented on GitHub (Oct 16, 2025): I've had a look into this and it seems like `wt.exe` and the direct `WindowsTerminal.exe` works like VSCode in that if no existing WT processes are running it'll continue running as the WT process. If a new WT process is started it'll communicate back with the first WT process to open a new window and the new process exits. This means that WT only ever has 1 process running outside of an limited vs elevated through UAC context. The only way around this is to ensure that the first WT instance was launch with the `/netonly` argument which could be done by using conhost directly. This would mean that any new console process' started normally would also inherit this output network credential. Another alternative is to see if there is any flag on `wt.exe` to force it to use a new process but I'm unsure if this is possible.
claunia commented 2026-01-31 08:50:22 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Oct 22, 2025):

Oh yeah, this is a case we've never really looked into. We recently fixed some issues around account handling and handing Terminal commandlines over to running instances, but I legitimately have no idea how we should differentiate "net-only" tokens...

We also recently got rid of isolated mode. Perhaps we should bring it back... so that you can run wt --isolated with net credentials :)

@DHowett commented on GitHub (Oct 22, 2025): Oh yeah, this is a case we've never really looked into. We recently fixed some issues around account handling and handing Terminal commandlines over to running instances, but I legitimately have no idea how we should differentiate "net-only" tokens... We also recently got rid of isolated mode. Perhaps we should bring it back... so that you can run `wt --isolated` with net credentials :)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Remoting Issue-Bug Priority-3 Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#23718
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?