Geo: not possible to switch to Replication details page if password authentication is disabled & admin mode is enabled
Summary
It is not possible to switch to Replication details page of a secondary node if password authentication is disabled & admin mode is enabled on a GitLab instance.
Steps to reproduce
- Have Geo instance configured
- Enable Require additional authentication for administrative tasks via Menu > Admin > General > Sign-in restrictions
- Configure Azure OAuth or any other Omniauth authentication (checked it with Azure OAuth only) and disable Password authentication enabled for web interface via Menu > Admin > General > Sign-in restrictions so that it is only possible to login via Azure
- Go to Menu > Admin > Geo and click
Replication details
on the secondary node
What is the current bug behavior?
You will be redirected to https://<secondary-host-name>/admin/session/new
, and UI will ask you to re-authenticate as you are accessing admin related settings, but there will be no option to enter the password or authenticate with Azure as shown at the attached screenshot.
What is the expected correct behavior?
It should be possible to re-authenticate: Azure or any other available auth type should be shown there.
Workaround
Either enable Password authentication enabled for web interface or disable Require additional authentication for administrative tasks.
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
**primary:** System information System: Ubuntu 18.04 Proxy: no Current User: git Using RVM: no Ruby Version: 2.7.2p137 Gem Version: 3.1.4 Bundler Version:2.1.4 Rake Version: 13.0.3 Redis Version: 6.0.14 Git Version: 2.32.0 Sidekiq Version:5.2.9 Go Version: unknown GitLab information Version: 14.1.0-ee Revision: e4567ef4362 Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 12.6 URL: https://gitlabhost-primary.tld HTTP Clone URL: https://gitlabhost-primary.tld/some-group/some-project.git SSH Clone URL: ssh://git@gitlabhost-primary.tld:2222/some-group/some-project.git Elasticsearch: yes Geo: yes Geo node: Primary Using LDAP: no Using Omniauth: yes Omniauth Providers: azure_oauth2 GitLab Shell Version: 13.19.0 Repository storage paths: - default: /var/opt/gitlab/git-data/repositories GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell Git: /opt/gitlab/embedded/bin/git **secondary:** System information System: Ubuntu 18.04 Proxy: no Current User: git Using RVM: no Ruby Version: 2.7.2p137 Gem Version: 3.1.4 Bundler Version:2.1.4 Rake Version: 13.0.3 Redis Version: 6.0.14 Git Version: 2.32.0 Sidekiq Version:5.2.9 Go Version: unknown GitLab information Version: 14.1.0-ee Revision: e4567ef4362 Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 12.6 URL: https://gitlabhost-secondary.tld HTTP Clone URL: https://gitlabhost-secondary.tld/some-group/some-project.git SSH Clone URL: ssh://git@gitlabhost-secondary.tld:2222/some-group/some-project.git Elasticsearch: yes Geo: yes Geo node: Secondary Using LDAP: no Using Omniauth: yes Omniauth Providers: GitLab Shell Version: 13.19.0 Repository storage paths: - default: /var/opt/gitlab/git-data/repositories GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell Git: /opt/gitlab/embedded/bin/git
Results of GitLab application Check
Expand for output related to the GitLab application check
**primary:**sudo gitlab-rake gitlab:geo:check Checking Geo ... GitLab Geo is available ... GitLab Geo is enabled ... yes This machine's Geo node name matches a database record ... yes, found a primary node named "Primary Site" HTTP/HTTPS repository cloning is enabled ... yes Machine clock is synchronized ... yes Git user has default SSH configuration? ... yes OpenSSH configured to use AuthorizedKeysCommand ... warning Reason: OpenSSH configuration file points to a different AuthorizedKeysCommand Try fixing it: We were expecting AuthorizedKeysCommand to be: /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-authori zed-keys-check git %u %k but instead it is: /usr/bin/google_authorized_keys If you made a custom command, make sure it behaves according to GitLab's Documentation For more information see: doc/administration/operations/fast_ssh_key_lookup.md warning Reason: OpenSSH configuration file points to a different AuthorizedKeysCommandUser Try fixing it: We were expecting AuthorizedKeysCommandUser to be: git but instead it is: root Fix your OpenSSH configuration file pointing to the correct user For more information see: doc/administration/operations/fast_ssh_key_lookup.md GitLab configured to disable writing to authorized_keys file ... yes GitLab configured to store new projects in hashed storage? ... yes All projects are in hashed storage? ... yes Checking Geo ... Finished
secondary:
sudo gitlab-rake gitlab:geo:check Checking Geo ... GitLab Geo secondary database is correctly configured ... yes Database replication enabled? ... yes Database replication working? ... yes GitLab Geo HTTP(S) connectivity ...
- Can connect to the primary node ... yes GitLab Geo is available ... GitLab Geo is enabled ... yes This machine's Geo node name matches a database record ... yes, found a secondary node named "Secondary Site" HTTP/HTTPS repository cloning is enabled ... yes Machine clock is synchronized ... yes Git user has default SSH configuration? ... yes OpenSSH configured to use AuthorizedKeysCommand ... warning Reason: OpenSSH configuration file points to a different AuthorizedKeysCommand Try fixing it: We were expecting AuthorizedKeysCommand to be: /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-authori zed-keys-check git %u %k but instead it is: /usr/bin/google_authorized_keys If you made a custom command, make sure it behaves according to GitLab's Documentation For more information see: doc/administration/operations/fast_ssh_key_lookup.md warning Reason: OpenSSH configuration file points to a different AuthorizedKeysCommandUser Try fixing it: We were expecting AuthorizedKeysCommandUser to be: git but instead it is: root Fix your OpenSSH configuration file pointing to the correct user For more information see: doc/administration/operations/fast_ssh_key_lookup.md GitLab configured to disable writing to authorized_keys file ... yes GitLab configured to store new projects in hashed storage? ... yes All projects are in hashed storage? ... yes Checking Geo ... Finished