[Feature Request] Allow to run without administrator permissions

[Simon1511]

Problem

When running AuthenticatorChooser as a non-admin user, it will ask for Administrator credentials. After putting in my administrator credentials (another account), AuthenticatorChooser will run in the background. However, since it was started as that Admin user, it's running under that specific admin account and hence only works for the admin (who isnt even logged on to the machine) but not for my regular user.

The same applies for the --autostart-on-logon flag, which adds the autostart key in the admin users HKCU registry -> no effect for my regular user.

Would it be possible to have AuthenticatorChooser run as a non-admin user?

[Aldaviva]

Hi @Simon1511,

This is a good question with a tricky answer. The problem is that in the January 2026 Windows update, the dialog box we're trying to control started running at higher elevation than normal programs do.

1. This is why AuthenticatorChooser was updated to run as administrator, to have a sufficiently high elevation level to control the dialog UI. This isn't perfect, as you pointed out, and I would prefer it to not run as admin (like before), but this half-solved the problem.
2. An alternative approach is to make AuthenticatorChooser run not as administrator, but with UIAccess integrity level, which would let it control the dialog without needing admin elevation. Unfortunately, this requires being installed in Program Files and also requires valid code signing, which is quite expensive (and it got even more expensive since the problem started 7 months ago) or requires some very convoluted project changes with their own drawbacks.
3. A third option may be to modify Windows' CredentialUIBroker.exe to run with medium integrity again, but I fear this would be brittle (either getting undone every Windows Update or itself breaking Windows Update), as well as unpopular because it'd be changing system files to make then ostensibly less secure from malicious programs snooping your PIN digits (never mind there would already have to be malware on your computer for this to matter, but this still seems like a choice fraught with peril).
4. There was some thought put into being able to start this program automatically with a scheduled task as administrator but have it switch to the correct user, although I'm still not sure this works or is possible, and it may just go in circles and get us back to the issue you mentioned where it ends up running as the non-admin user anyway. I don't think non-admin users even have high integrity elevation tokens, which would make this a dead end. Maybe it can run as the admin user in the non-admin session, with access to the non-admin windows? I tried doing this before and was unable to make it work, but it's possible I missed something.

You can take a look at #62 and see if anything there seems useful. That uses the UIAccess approach with a paid code signing cert. I have not personally used or audited that artifact, it is from a different user.

[Simon1511]

Hi, thank you for the detailed explanation, that's very unfortunate.

I'll see if I can get the suggestion from post #62 running. Wonder if I could sign the executable with our internal Windows CA, so I could at least use it on my work PC. The CA cert is installed on all company devices and we sometimes do issue code signing certs with it for internal use.

[Aldaviva]

If you have your own CA that can issue code-signing certificates, it may be even easier. I believe you could do the following:

1. Install .NET SDK 8 or later
2. Clone or download this repository
3. Edit app.manifest to make it not run as administrator, but with UIAccess instead:

   - <requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
   + <requestedExecutionLevel level="asInvoker" uiAccess="true" />

4. Build with dotnet publish -p:PublishSingleFile=true
5. Sign bin\Release\net8.0\win-x64\publish\AuthenticatorChooser.exe with your code-signing cert using signtool.exe, or alternatively by editing the .csproj file before building if you prefer that tooling
6. Copy the signed AuthenticatorChooser.exe to a subdirectory of %ProgramFiles%
7. When registering for autostart, you may want to just manually add it to HKCU\Software\Microsoft\Windows\CurrentVersion\Run or the Startup folder, because as you mentioned the --autostart-on-logon flag will try to make a scheduled task and it may not get the user or elevation correct since it was designed for the admin case

I have not verified all of these steps myself but I believe this is a usable path. Hopefully I didn't forget anything.

[Simon1511]

Thanks for your input @Aldaviva , but I guess I'm doing something wrong.

I did manage to compile it. Then issued a Code Signing Cert from our Windows CA and successfully signed the EXE with it. Then copied the EXE to C:\Program Files\AuthenticationChooser\ and tried to run it, but unforunately nothing happens when I do so.

It's not running in the background according to Task Manager.

What worries me a little is that your release build is around 3.69MB in size while my EXE is only 220kB. This MIGHT be because I built it on Linux with the .NET 8 SDK and command dotnet publish -p:PublishSingleFile=true -r win-x64, but not sure if that's actually it. There's a whole bunch of other files in the output folder, guess those are the actual build artifacts, assuming I dont need any of those?

Thanks for your help!

~/AuthenticatorChooser/AuthenticatorChooser/bin/Release/net8.0-windows/win-x64$ ll
total 4552
drwxrwxr-x 55 simon simon   4096 Jul 31 14:05 ./
drwxrwxr-x  4 simon simon   4096 Jul 31 13:51 ../
-rw-rw-r--  1 simon simon  16684 Jul 31 13:51 AuthenticatorChooser.deps.json
-rw-rw-r--  1 simon simon 143872 Jul 31 13:51 AuthenticatorChooser.dll
-rwxr-xr-x  1 simon simon 220160 Jul 31 13:51 AuthenticatorChooser.exe*
-rw-rw-r--  1 simon simon    469 Jul 31 13:51 AuthenticatorChooser.runtimeconfig.json
-rw-rw-r--  1 simon simon 225272 Jul 31 14:05 AuthenticatorChooser_signed.exe
-rwxrw-r--  1 simon simon   3072 Jul  7  2020 ManagedWinapiNativeHelper.dll*
-rwxrw-r--  1 simon simon 184832 Apr  5 08:08 McMaster.Extensions.CommandLineUtils.dll*
-rwxrw-r--  1 simon simon 335360 Jul  8  2025 Microsoft.Win32.TaskScheduler.dll*
-rwxrw-r--  1 simon simon 929280 May  4 23:52 NLog.dll*
-rwxrw-r--  1 simon simon 183592 Apr 30 03:34 System.CodeDom.dll*
-rwxrw-r--  1 simon simon 801080 Sep 17  2024 System.Diagnostics.EventLog.Messages.dll*
-rwxrw-r--  1 simon simon 172704 Sep 17  2024 System.Diagnostics.EventLog.dll*
-rwxrw-r--  1 simon simon 313168 Apr 30 03:39 System.Management.dll*
-rwxrw-r--  1 simon simon  76800 Apr  3 03:05 ThrottleDebounce.dll*
-rwxrw-r--  1 simon simon  37888 Apr 16 11:54 Unfucked.Windows.dll*
-rwxrw-r--  1 simon simon 122880 Apr 16 11:50 Unfucked.dll*
-rwxrw-r--  1 simon simon 165424 Jun 25  2024 Workshell.PE.Resources.dll*
-rwxrw-r--  1 simon simon 324656 Jun 25  2024 Workshell.PE.dll*
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 ar-SA/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 bg-BG/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 ca-ES/
-rwxrwxr-x  1 simon simon   6426 Jul 31 14:04 cert.pfx*
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 cs-CZ/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 da-DK/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 de/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 de-DE/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 el-GR/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 en-GB/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 es/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 es-ES/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 es-MX/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 et-EE/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 eu-ES/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 fi-FI/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 fr/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 fr-CA/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 fr-FR/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 gl-ES/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 he-IL/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 hr-HR/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 hu-HU/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 id-ID/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 it/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 it-IT/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 ja/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 ja-JP/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 ko-KR/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 lt-LT/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 lv-LV/
-rwxrw-r--  1 simon simon 133120 Mar  5 16:14 mwinapi.dll*
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 nb-NO/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 nl-NL/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 pl/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 pl-PL/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 pt-BR/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 pt-PT/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 publish/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 ro-RO/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 ru/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 ru-RU/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 sk-SK/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 sl-SI/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 sr-Latn-RS/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 sv/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 sv-SE/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 th-TH/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 tr/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 tr-TR/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 uk-UA/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 vi-VN/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 zh-CN/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 zh-Hant/
drwxrwxr-x  2 simon simon   4096 Jul 31 13:51 zh-TW/

[Aldaviva]

Oh sorry, I always forget that the big EXE will be inside that publish subdirectory. This win-x64 intermediate directory is where it gets built first before being relinked into the big EXE by PublishSingleFile. I have fixed my instructions above.

[Simon1511]

Ahhh I see. I probably could have noticed that if I had searched further😂

I'll check it out, thank you!

[Simon1511]

Its been a few weeks, I've been on vacation and only returned to the office this week.

I successfully signed the EXE now using our internal Windows CA and it works pretty well.

Here are the steps I followed:

1. Be on a Domain joined Windows PC (might work with Entra joined + Entra hosted CA too, not sure)
2. Administrator permissions are required (Domain Admin, server admin or whatever security construct your company uses). I'm one of the Sysadmins, so that wasn't an issue for me.
3. Have a Windows CA Domain joined.
4. Connect to the Windows CA via RDP
5. Open the "Certificate Authority" MMC Snap-In
6. In case you havent done this before: Go to "Certificate Templates" -> Right click -> New -> Issue new Certificate template (might be called different, Im just translating this)
7. Select the "code signing" template and confirm
8. Now open "User certificates" (you can find it via the Windows search or also via MMC Snap-In)
9. Right click on "My certificates" -> All Tasks -> Request new Certificate
10. Next -> Next -> Mark the checkbox next to the "Code Signing" template
11. Click on the blue text below the template, it wants you to fill out additional Information
12. Add some Basic Information (I only set Common Name in the first box to "AuthenticationChooser")
13. Confirm
14. Register the cert
15. You should now see the Certificate Request in the CA Snap-In under "Pending Requests"
16. Right Click your pending certificate request -> all Tasks -> Issue
17. Go to "Issued Certificates" in the CA Snap-In
18. Find your certificate in the list, open it by double click, go to "Details" and select "Copy to File" (Keep the Defaults)
19. Double Click the certificate file you just exported and click "Install Certificate" (on the same machine!)
20. Select "current User" and continue with the Defaults for the rest
21. In the "User certficates" Snap-In, refresh the "My Certificates" container, it should now show the cert you just imported
22. Right click -> All Tasks -> Export -> With Private Key -> Next -> set a Password and set the encryption to AES256 (optional) -> Give it a filename -> Confirm
23. Since I compiled it on Linux, I used osslsigncode on Linux to sign the EXE: osslsigncode sign -pkcs12 cert.pfx -askpass -n "AuthenticationChooser" -in AuthenticatorChooser.exe -out AuthenticatorChooser_signed.exe (the -n stands for descrption; I'm not sure if this needs to match the Common Name I set in the cert).
24. This will sign the EXE and create a new one called AuthenticationChooser_signed.exe
25. Right click the AuthenticationChooser_signed.exe -> Properties -> "Digital Signatures" should Show it being signed
26. Move the signed EXE to a subdir of C:\Program Files\
27. Right click the file, select properties, make sure it is unblocked
28. Run the EXE
29. It should now run in the background and successfully "do its thing" when FIDO2 authentication is used anywhere in the system

Do NOTE that this will only work on machines that trust your CA. Copying the signed EXE to another machine that doesnt trust your CA, it will probably not work.

I'm closing this issue here as my initial issue is now resolved. You're free to use above steps as a guide for others, though I doubt there will be many people resolving it this way.

Thank you for this great tool!