turning external users into standard ones

Summary

Users are authenticated either via our companies LDAP or via Omniauth. Omniauth default to restricted access (external users). LDAP users have normal privileges.

Issue: The site admin is unable to un-restrict an oauth-user.

Steps to reproduce

  1. Enable only LDAP and oauth for login

  2. add oauth provider to the external_providers. e.g.:

    gitlab_rails['omniauth_external_providers'] = ['github']

  3. first-time login via oauth: the user (say OAUTHUSER) is created, and marked as external

  4. as admin, go to https://git.EXAMPLE.COM/admin/users/OAUTHUSER/edit note that the user has external checked (as expected)

  5. uncheck the external checkbox, then Save the page reloads and displays

External User: No

  1. re-login as user. note that the user still cannot create repositories,...

  2. note that on the user-page (admin-view), the external flag is again checked.

Expected behavior

I expect that, as the site admin, I can override the default external state, granting a specific user (who authenticates only via oauth) internal permissions.

While I already had this expectation when searching for the option to disable external for the specific user, the expectation was further raised by the existence of an active checkbox (which would allow me to un-check the external flag)

Actual behavior

It seems that the external flag is reset whenever the user logs-in via oauth. This basically undoes whatever the admin has chosen :-(

Intentional behaviour?

on re-reading the docs, I stumbled upon:

You can define which OmniAuth providers you want to be external so that all users creating accounts, or logging in via these providers will not be able to have access to internal project.

This might indicate that all users authenticating via (external) oauth are always forced to external, and that this is intended (at least: documented) behavior.

I think there is little merit in forcing all users to external users.

in our specific case, people can only authenticate via LDAP (if they are part of the company) or via oauth (if they are not). from the gitlab perspective, the LDAP backend is read only (that is: we cannot add people whom we want to grant full internal access to our gitlab instance to the LDAP). we don't want to open ordinary ("local") gitlab users for authentication.

Output of checks

(If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com)

Results of GitLab application Check

# gitlab-rake gitlab:check SANITIZE=true
Checking GitLab Shell ...

GitLab Shell version >= 4.1.1 ? ... OK (4.1.1)
Repo base directory exists?
default... yes
Repo storage directories are symlinks?
default... no
Repo paths owned by git:git?
default... yes
Repo paths access is drwxrws---?
default... yes
hooks directories in repos are links: ...

[skipped: few 'repository is empty'; rest is 'ok']

Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Access to /var/opt/gitlab/.ssh/authorized_keys: OK
Send ping to redis server: OK
gitlab-shell self-check successful

Checking GitLab Shell ... Finished

Checking Sidekiq ...

Running? ... yes
Number of Sidekiq processes ... 1

Checking Sidekiq ... Finished

Checking Reply by email ...

IMAP server credentials are correct? ... yes
Init.d configured correctly? ... skipped (omnibus-gitlab has no init script)
MailRoom running? ... can't check because of previous errors

Checking Reply by email ... Finished

Checking LDAP ...

Server: ldapmain
LDAP authentication... Anonymous. No `bind_dn` or `password` configured
LDAP users with access to your GitLab server (only showing the first 100
results)
        DN: [skipped]

Checking LDAP ... Finished

Checking GitLab ...

Git configured with autocrlf=input? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config outdated? ... no
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory setup correctly? ... no
  Try fixing it:
  sudo chown -R git /var/opt/gitlab/gitlab-rails/uploads
  sudo find /var/opt/gitlab/gitlab-rails/uploads -type f -exec chmod 0644 {} \;
  sudo find /var/opt/gitlab/gitlab-rails/uploads -type d -not -path
/var/opt/gitlab/gitlab-rails/uploads -exec chmod 0700 {} \;
  For more information see:
  doc/install/installation.md in section "GitLab"
  Please fix the error above and rerun the checks.
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
projects have namespace: ...

[skipped: all 'yes']

Redis version >= 2.8.0? ... yes
Ruby version >= 2.1.0 ? ... yes (2.3.3)
Your git bin path is "/opt/gitlab/embedded/bin/git"
Git version >= 2.7.3 ? ... yes (2.10.2)
Active users: 73

Checking GitLab ... Finished

Results of GitLab environment info

# gitlab-rake gitlab:env:info

System information
System:		Debian 8.7
Current User:	git
Using RVM:	no
Ruby Version:	2.3.3p222
Gem Version:	2.6.6
Bundler Version:1.13.7
Rake Version:	10.5.0
Sidekiq Version:4.2.7

GitLab information
Version:	8.16.3
Revision:	d225908
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	postgresql
URL:		https://git.EXAMPLE.COM
HTTP Clone URL:	https://git.EXAMPLE.COM/some-group/some-project.git
SSH Clone URL:	git@git.EXAMPLE.COM:some-group/some-project.git
Using LDAP:	yes
Using Omniauth:	yes
Omniauth Providers: google_oauth2, github

GitLab Shell
Version:	4.1.1
Repository storage paths:
- default: 	/var/opt/gitlab/git-data/repositories
Hooks:		/opt/gitlab/embedded/service/gitlab-shell/hooks/
Git:		/opt/gitlab/embedded/bin/git