### 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'] 2. first-time login via oauth: the user (say `OAUTHUSER`) is created, and marked as `external` 3. as *admin*, go to https://git.EXAMPLE.COM/admin/users/OAUTHUSER/edit note that the user has `external` checked (as expected) 4. uncheck the `external` checkbox, then <kbd>Save</kbd> the page reloads and displays > External User: No 5. re-login as user. note that the user still cannot create repositories,... 6. 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 ```