Thanks for the reply. I was hoping the Git GUI might be able to handle the OpenID authentication flow, but it makes sense that it would be inconsistent with other git clients.
Azure AD does support both LDAP and Kerberos, but unfortunately only as an extra cost add-on called "Domain Services". I might try to hack up a script to just sync the Azure AD password hashes to the htpassword file. Otherwise I guess I'll have to bite the bullet and pay the extra bill. Nonetheless, thank you for the suggestion! Ralph On 10/16/2019 4:33 PM, brian m. carlson wrote: > On 2019-10-15 at 15:59:03, Ralph Ewig wrote: >> Hi Everyone, hoping you might have a solution for >> this problem: >> >> CONTEXT >> >> * I'm serving git repos using "smart https" via >> apache and basic authentication; everything works >> fine. >> * We're moving to SSO via Azure AD and apache >> mod_auth_openidc; this works fine for gitweb (on >> the same server as git). >> >> PROBLEM >> >> When trying to clone a repo with the OIDC setup, >> git breaks on the redirect for user authentication >> with the following error message (replaced server >> ids etc with xxx): >> >> C:\Users\void>git clone --progress -v >> "https://git.xxx.xxx/WebApps.git"; >> Cloning into 'WebApps'... >> fatal: unable to update url base from >> redirection: >> asked for: >> https://git.xxx.xxx/WebApps.git/info/refs?service=git-upload-pack >> redirect: >> https://login.microsoftonline.com/xxx/oauth2/authorize?response_type=code&scope=openid&client_id=xxx&state=xxx&redirect_uri=https%3A%2F%2Fgit.xxx.xxx%2Fredirect&nonce=xxx >> >> >> Can the git client just not handle a web based >> redirect for login, or is this a configuration >> issue? Any ideas would be greatly appreciated. Thanks! > The Git client doesn't handle any sort of web-based login. In general, > in order to do web-based login, you have to provide a fully functional > graphical web browser, and Git operates in many environments that don't > have one (such as servers, containers, and headless systems). > > You should treat your Git server like you would treat any API you may > access, since essentially it is one. That means that you would need to > provide a way to use some sort of external credential. > > I know next to nothing about Azure AD, but it claims to support > Kerberos, so you may be able to use that in conjunction with libcurl's > GSS-Negotiate support and Apache's mod_auth_kerb (which is shipped in > Debian). I use Kerberos-based authentication for my personal server > (which is Linux, not AD) and it does work, so it is possible to set up.
