When given a username to use, the plugin is using a different, made up, username

[Joibel]

Which version of GCM Core are you using?

2.0.394-beta+3fc6791abf
(Also tried with an earlier version)

Which Git host provider are you trying to connect to?

• Azure DevOps
• Azure DevOps Server (TFS/on-prem)
• GitHub
• GitHub Enterprise
• Bitbucket
• Other - please describe

Gerrit 3.3.2 via https.

I am attempting to access it as https://username@gerrit/repo

Can you access the remote repository directly in the browser using the remote URL?

• Yes
• No, I get a permission error
• No, for a different reason - please describe

Expected behavior

The GUI for password prompt contains username, and uses username.

I am authenticated and my Git operation completes successfully.

Actual behavior

Instead the dialog contains an uneditable DOMAIN\email@address.com which was used to log into the box and the DOMAIN having been somehow discovered.

Under no circumstance does it seem valid for the plugin to change the username that it attempts to use when authenticating with a generic backend when it has been told the username to use.

This wrong username is passed to the remote end, which unsuprisingly doesn't auth.

This doesn't happen if I use https://gerrit/repo (so no username@). In that event the username box is empty and editable. However, gerrit hands out clone command with the username pre-populated and we would like not to have to retrain users.

This happens on our trial 'InTune' Azure AD linked box, which is plugged into the internal network, but otherwise unassociated with DOMAIN (which we're unsure how it's discovering).

Logs

The logs don't mention where it makes up usernames.

14:58:40.174779 ...\Application.cs:84 trace: [RunInternalAsync] Version: 2.0.394.50751
14:58:40.174779 ...\Application.cs:85 trace: [RunInternalAsync] Runtime: .NET Framework 4.0.30319.42000
14:58:40.174779 ...\Application.cs:86 trace: [RunInternalAsync] Platform: Windows (x86-64)
14:58:40.174779 ...\Application.cs:87 trace: [RunInternalAsync] AppPath: C:\Program Files (x86)\Git Credential Manager Core\git-credential-manager-core
14:58:40.174779 ...\Application.cs:88 trace: [RunInternalAsync] Arguments: get
14:58:40.237275 ...GitCommandBase.cs:35 trace: [ExecuteAsync] Start 'get' command...
14:58:40.237275 ...GitCommandBase.cs:49 trace: [ExecuteAsync] Detecting host provider for input:
14:58:40.237275 ...GitCommandBase.cs:50 trace: [ExecuteAsync] protocol=https
14:58:40.237275 ...GitCommandBase.cs:50 trace: [ExecuteAsync] host=gerrit.redacted
14:58:40.237275 ...GitCommandBase.cs:50 trace: [ExecuteAsync] username=redacted
14:58:40.284146 ...viderRegistry.cs:100 trace: [GetProviderAsync] Host provider override was set id='generic'
14:58:40.284146 ...GitCommandBase.cs:52 trace: [ExecuteAsync] Host provider 'Generic' was selected.
14:58:40.284146 ...\HostProvider.cs:128 trace: [GetCredentialAsync] Looking for existing credential in store with service=https://gerrit.redacted account=redacted...
14:58:40.284146 ...\HostProvider.cs:133 trace: [GetCredentialAsync] No existing credentials found.
14:58:40.284146 ...\HostProvider.cs:136 trace: [GetCredentialAsync] Creating new credential...
14:58:40.346642 ...icHostProvider.cs:60 trace: [GenerateCredentialAsync] Checking host 'https://gerrit.redacted/' for Windows Integrated Authentication...
14:58:40.346642 ...Authentication.cs:36 trace: [GetIsSupportedAsync] HTTP: HEAD https://gerrit.redacted/
14:58:40.346642 ...pClientFactory.cs:54 trace: [CreateClient] Creating new HTTP client instance...
14:58:40.534128 ...Authentication.cs:39 trace: [GetIsSupportedAsync] HTTP: Response code ignored.
14:58:40.534128 ...Authentication.cs:41 trace: [GetIsSupportedAsync] Inspecting WWW-Authenticate headers...
14:58:40.534128 ...icHostProvider.cs:65 trace: [GenerateCredentialAsync] Host does not support WIA.
14:58:40.534128 ...icHostProvider.cs:86 trace: [GenerateCredentialAsync] Prompting for basic credentials...
trace: built-in: git config --null credential.authority
14:58:40.362266 exec-cmd.c:237 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
14:58:40.362266 git.c:444 trace: built-in: git config --null --list --show-scope
14:58:40.377890 exec-cmd.c:237 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
14:58:40.377890 git.c:444 trace: built-in: git config --null credential.httpsProxy
14:58:40.393515 exec-cmd.c:237 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
14:58:40.393515 git.c:444 trace: built-in: git config --null --list --show-scope
14:58:40.409138 exec-cmd.c:237 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
14:58:40.409138 git.c:444 trace: built-in: git config --null credential.httpProxy
14:58:40.424763 exec-cmd.c:237 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
14:58:40.424763 git.c:444 trace: built-in: git config --null --list --show-scope
14:58:40.440386 exec-cmd.c:237 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
14:58:40.440386 git.c:444 trace: built-in: git config --null http.proxy
14:58:40.471636 exec-cmd.c:237 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
14:58:40.471636 git.c:444 trace: built-in: git config --null --list --show-scope
14:58:40.487260 exec-cmd.c:237 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
14:58:40.487260 git.c:444 trace: built-in: git config --null http.sslVerify
14:58:40.565377 exec-cmd.c:237 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
14:58:40.565377 git.c:444 trace: built-in: git config --null --list --show-scope
14:58:40.581001 exec-cmd.c:237 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
14:58:40.581001 git.c:444 trace: built-in: git config --null credential.interactive

[mjcheetham]

Hi @Joibel, thanks for reporting this.

It looks like the Windows CredUI interface that we're using (CredUIPromptForWindowsCredentials) is assuming that given a username value that matches a the local Windows user account (and the machine is AAD or classic domain joined), then Windows will 'auto-complete' the user to a fully qualified UPN.

We should probably replace the use of this API with a custom credential capture UI. The CredUI API in Windows really does assume the creds are regarding Windows accounts. I've not been able to find any combination of flags to prevent this.

[Joibel]

Thanks @mjcheetham, that does sound like the scenario we're seeing. If you'd like me to test with some non-matching credentials I can do so, to prove that it stops being annoying in that circumstance.

[mjcheetham]

The best solution to this problem is to stop using the Windows API CredUIPromptForWindowsCredentials. To replace we'd need a simple username/password GUI prompt. This would be useful not only for fixing this scenario, but also on macOS and Linux where we currently have no such GUI support for username/password auth, and instead require a terminal.

[mjcheetham]

The fix for this problem (replacing the Windows prompt with a custom one) has made it in to the main branch, and will be included in the next release.