Creating a user returns "password, reset_password are missing, at least one parameter must be provided" for an LDAP authenticated user
Summary
Calling POST /users will return password, reset_password are missing, at least one parameter must be provided
even though an external user ID and provider have been specified in the function parameters.
This should not happen for a user with an external authentication provider (in my case LDAP) as the password storage is handled by LDAP and not Gitlab.
This is important for an external user raking task to be possible in order to assign users projects etc prior to their first self sign in.
Steps to reproduce
Call POST /users specifying with the following parameter keys:
- password:
null
, or don't define - reset_password:
false
, or don't define - username: User's LDAP UID
- name
- extern_uid: User's LDAP DN
- provider: LDAP instance name as per your Gitlab configuration
- skip_confirmation:
true
What is the current bug behavior?
The API function returns password, reset_password are missing, at least one parameter must be provided
.
If you define reset_password
as false
in the parameters then the API function instead returns "password" can't be blank
.
What is the expected correct behavior?
User should be created successfully without a password or the requirement to reset their password so the user can authenticate using their LDAP credentials in the same way they can do so when signing in for the first time.
Results of GitLab environment info
System information
System: Debian 9.6
Current User: git
Using RVM: no
Ruby Version: 2.4.5p335
Gem Version: 2.7.6
Bundler Version:1.16.6
Rake Version: 12.3.1
Redis Version: 3.2.12
Git Version: 2.18.1
Sidekiq Version:5.2.1
Go Version: unknown
GitLab information
Version: 11.5.4
Revision: 315df49
Directory: /opt/gitlab/embedded/service/gitlab-rails
DB Adapter: postgresql
URL: private
HTTP Clone URL: private
SSH Clone URL: private
Using LDAP: yes
Using Omniauth: yes
Omniauth Providers:
GitLab Shell
Version: 8.4.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
Results of GitLab application Check
Checking GitLab Shell ...
GitLab Shell version >= 8.4.1 ? ... OK (8.4.1)
hooks directories in repos are links: ... can't check, you have no projects
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Redis available via internal API: OK
Access to /var/opt/gitlab/.ssh/authorized_keys: OK
gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Gitaly ...
default ... OK
Checking Gitaly ... Finished
Checking Sidekiq ...
Running? ... yes
Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Reply by email is disabled in config/gitlab.yml
Checking LDAP ...
Server: ldapmain
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)
private, but a valid list of user DNs shows up with their correct UIDs
Checking LDAP ... Finished
Checking GitLab ...
Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
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: ... can't check, you have no projects
Redis version >= 2.8.0? ... yes
Ruby version >= 2.3.5 ? ... yes (2.4.5)
Git version >= 2.9.5 ? ... yes (2.18.1)
Git user has default SSH configuration? ... yes
Active users: ... 3
Checking GitLab ... Finished