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

When using Portable Preview in domain environment, opening a terminal as a different user when current user has terminal window already open results in second terminal for current user and not the different user #23039

New Issue
Closed
opened 2026-01-31 08:30:37 +00:00 by claunia · 9 comments
claunia commented 2026-01-31 08:30:37 +00:00
Owner
Copy Link

Originally created by @PGomersall on GitHub (Mar 19, 2025).

Windows Terminal version

1.23.10353.0 and 1.23.10732.0

Windows build number

10.0.26100.3476 W11 24H2
Windows Server 2025

Other Software

N\A

Steps to reproduce

Computer needs to be domain joined. Also fixes noted at the end of https://github.com/microsoft/terminal/issues/18105 needs to be applied - i.e. Accent colors.
Setup WT portable Preview in location accessible to all users, e.g. C:\WT
Add .portable file and settings.json in settings folder.
Run C:\WT\WindowsTerminal.exe as current user
Terminal open correctly as current user
Run C:\WT\WindowsTerminal.exe as different user
Terminal requests correctly different user's credentials
Terminal then opens as current user and not the different user.
This has been tested on different computers and OS's all at least 24H2 Windows 11 or Server 2025 and all exhibit same effect.
Have used standard users, admin users, domain admin account with and without smartcards.

Notes:
Using Terminal portable stable (not preview) works correctly.
Using Terminal Portable stable for one session and Preview for the other works. Same is true for built-in app version and Terminal portable preview.
This does not seem to occur on a non-domain joined computer

Expected Behavior

Opening Terminal as different user when one from current is also running results in second terminal opening as the different user and NOT the current user.

Actual Behavior

Terminal Preview opens as same user as that running the first Terminal session.

Originally created by @PGomersall on GitHub (Mar 19, 2025). ### Windows Terminal version 1.23.10353.0 and 1.23.10732.0 ### Windows build number 10.0.26100.3476 W11 24H2 Windows Server 2025 ### Other Software N\A ### Steps to reproduce Computer needs to be domain joined. Also fixes noted at the end of https://github.com/microsoft/terminal/issues/18105 needs to be applied - i.e. Accent colors. Setup WT portable Preview in location accessible to all users, e.g. C:\WT Add .portable file and settings.json in settings folder. Run C:\WT\WindowsTerminal.exe as current user Terminal open correctly as current user Run C:\WT\WindowsTerminal.exe as different user Terminal requests correctly different user's credentials Terminal then opens as current user and not the different user. This has been tested on different computers and OS's all at least 24H2 Windows 11 or Server 2025 and all exhibit same effect. Have used standard users, admin users, domain admin account with and without smartcards. Notes: Using Terminal portable stable (not preview) works correctly. Using Terminal Portable stable for one session and Preview for the other works. Same is true for built-in app version and Terminal portable preview. This does not seem to occur on a non-domain joined computer ### Expected Behavior Opening Terminal as different user when one from current is also running results in second terminal opening as the different user and NOT the current user. ### Actual Behavior Terminal Preview opens as same user as that running the first Terminal session.
claunia commented 2026-01-31 08:30:39 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Mar 19, 2025):

When discussing this we had the theory that HWNDs are global objects, so when we call FindWindow it gets us the wrong window. An idea to fix this may to add the SID to the HWND name. We use a NT mutex object to prevent two instances from being concurrently created and we could also swap that one out for one that stores the HWND in a shared memory section.

@lhecker commented on GitHub (Mar 19, 2025): When discussing this we had the theory that HWNDs are global objects, so when we call `FindWindow` it gets us the wrong window. An idea to fix this may to add the SID to the HWND name. We use a NT mutex object to prevent two instances from being concurrently created and we could also swap that one out for one that stores the HWND in a shared memory section.
claunia commented 2026-01-31 08:30:39 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 8, 2025):

FWIW, instead of using a shared memory region I just hashed the SID into the window name. https://github.com/microsoft/terminal/compare/main...dev/duhowett/window-sid

We can pursue a larger architectural change if we want to later.

I think it's more complicated than just switching to a shared memory region. My understanding here is somewhat limited, of course.

Mutants show up in \Session\1\BaseNamedObjects regardless of the user who created them. The two users on the same desktop share a session, and do not have BNO isolation. We would still need some extra namespacing to prevent the two users' named mappings from colliding.

@DHowett commented on GitHub (Jul 8, 2025): FWIW, instead of using a shared memory region I just hashed the SID into the window name. https://github.com/microsoft/terminal/compare/main...dev/duhowett/window-sid We can pursue a larger architectural change if we want to later. I think it's more complicated than just _switching_ to a shared memory region. My understanding here is somewhat limited, of course. Mutants show up in `\Session\1\BaseNamedObjects` _regardless of the user who created them_. The two users on the same desktop share a session, and do not have BNO isolation. We would still need some extra namespacing to prevent the two users' named mappings from colliding.
claunia commented 2026-01-31 08:30:40 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 8, 2025):

@pgomersall I'm slightly worried about our approach here; if you would have some time to test out Canary Portable builds over the next couple days, I would greatly appreciate it. They usually come out around 11PM Central Time every night.

@DHowett commented on GitHub (Jul 8, 2025): @pgomersall I'm slightly worried about our approach here; if you would have some time to test out Canary Portable builds over the next couple days, I would greatly appreciate it. They usually come out around 11PM Central Time every night.
claunia commented 2026-01-31 08:30:40 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 8, 2025):

I did confirm it reproduced locally without the fix, and didn't reproduce with the fix; my concern is in the other direction, however: including the SID unconditionally may have broken some other normal remoting scenario we didn't think of.

@DHowett commented on GitHub (Jul 8, 2025): I did confirm it reproduced locally without the fix, and didn't reproduce _with_ the fix; my concern is in the other direction, however: including the SID unconditionally may have broken some other normal remoting scenario we didn't think of.
claunia commented 2026-01-31 08:30:40 +00:00
Author
Owner
Copy Link

@PGomersall commented on GitHub (Jul 8, 2025):

@DHowett yes Dustin I will test once the Canary is published.

@PGomersall commented on GitHub (Jul 8, 2025): @DHowett yes Dustin I will test once the Canary is published.
claunia commented 2026-01-31 08:30:40 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 9, 2025):

Thank you!

@DHowett commented on GitHub (Jul 9, 2025): Thank you!
claunia commented 2026-01-31 08:30:40 +00:00
Author
Owner
Copy Link

@PGomersall commented on GitHub (Jul 9, 2025):

@DHowett

OK so I have initial testing done for Canary terminal-1.24.1891.0 x64 zip. WT launches correctly now under correct user from run as a different user. Tested opening as second session and first. So far I have not had any other underlying issues from within the launched terminals - doing things like using AD cmdlets, opening other win32 apps etc. Seems to interact with the users desktop session correctly, like minimizing to the tray and returning to focus.
I will keep testing going forward and report back on both stability and any subsequently found issues.

@PGomersall commented on GitHub (Jul 9, 2025): @DHowett OK so I have initial testing done for Canary terminal-1.24.1891.0 x64 zip. WT launches correctly now under correct user from run as a different user. Tested opening as second session and first. So far I have not had any other underlying issues from within the launched terminals - doing things like using AD cmdlets, opening other win32 apps etc. Seems to interact with the users desktop session correctly, like minimizing to the tray and returning to focus. I will keep testing going forward and report back on both stability and any subsequently found issues.
claunia commented 2026-01-31 08:30:41 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 10, 2025):

@PGomersall thanks so much for testing. I'm marking this up for inclusion in v1.22 and v1.23 for our next servicing release (this month) :)

@DHowett commented on GitHub (Jul 10, 2025): @PGomersall thanks so much for testing. I'm marking this up for inclusion in v1.22 and v1.23 for our next servicing release (this month) :)
claunia commented 2026-01-31 08:30:41 +00:00
Author
Owner
Copy Link

@PGomersall commented on GitHub (Jul 10, 2025):

@DHowett
I ran the 2 separate terminal sessions all day yesterday doing a variety of things.
I was logged on to my work office computer remotely via RDP where they were running.
I did have one issue during the day that I have not had recently, where I was opening an app (unrelated to WT) as administrator that initiated the secure desktop; I could see that UAC was raised in the taskbar but the UI for it was hidden which locked what I could do; clicking the icon on the taskbar didn't bring the UI into focus. Getting Task Manager open and restarting Explorer enable me to click the UAC icon in the taskbar and accept the prompt.
I am running a couple of non standard utilities that may impact what I saw rather than WT - StartAllBack and Explorer Tab Utility.
But since I had not seen this issue recently I thought I would mention the issue; it did occur while both Canary terminal windows were running but it seemed more related to my other still open issue: #18105 rather than this one.

@PGomersall commented on GitHub (Jul 10, 2025): @DHowett I ran the 2 separate terminal sessions all day yesterday doing a variety of things. I was logged on to my work office computer remotely via RDP where they were running. I did have one issue during the day that I have not had recently, where I was opening an app (unrelated to WT) as administrator that initiated the secure desktop; I could see that UAC was raised in the taskbar but the UI for it was hidden which locked what I could do; clicking the icon on the taskbar didn't bring the UI into focus. Getting Task Manager open and restarting Explorer enable me to click the UAC icon in the taskbar and accept the prompt. I am running a couple of non standard utilities that may impact what I saw rather than WT - StartAllBack and Explorer Tab Utility. But since I had not seen this issue recently I thought I would mention the issue; it did occur while both Canary terminal windows were running but it seemed more related to my other still open issue: #18105 rather than this one.
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-Windowing Help Wanted Issue-Bug Needs-Tag-Fix Priority-2 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#23039
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?