I am locking for the right GitLab CE server configuration to block new users, which signed up manually via the sign-up page (username / name / password). This users should be blocked until manually confirmed by an admin.
I found options to block new (auto-created) users for LDAP and OmniAuth in gitlab.yml but not for plain user accounts, who just registered on the sign-up page:
## LDAP settings
ldap:
servers:
main:
block_auto_created_users: true
## OmniAuth settings
omniauth:
block_auto_created_users: true
I want to let the users register themselves, so completely disabling this the admin area is not wanted:
How can I configure GitLab CE to block new users who just signed-up so that I have an admin confirmation for new users (not using LDAP or OmniAuth)?
GitLab version is 8.5.7 CE.
You now (October 2020) have an alternative with GitLab 13.5:
Required approval for new user registration
To reduce the operational burden on GitLab administrators without compromising security, GitLab 13.5 introduces a new instance-level option to require administrator approval for any new user accounts.
This option is disabled by default but when enabled, will require manual approval by instance administrators before users that completed the sign-up process can access the instance.
See Documentation and Epic.
And:
See GitLab 13.6 (November 2020)
Admin approval required by default for new user registrations
In GitLab 13.5, we introduced the option to require administrator approval for new user registrations.
To increase security of our default configuration, GitLab 13.6 makes this option the default experience for new instances.
We have also introduced email notifications to instance administrators when a new signup occurs and to users when their registration is approved.
Email notifications at these critical steps in the process help reduce the turnaround time to onboard users when administrator approval is required.
See Documentation and Epic.
Related
Your account is pending approval from your GitLab administrator and hence blocked. Please contact your GitLab administrator if you think this is an error
Well as the message states. You have created an account on a self-hosted GitLab instance.
The administrators of that instance have configured it so that they have to manually approve every account that is created. This is usually to prevent spam and exploiting of publicly reachable instance.
When this setting is enabled, any user visiting your GitLab domain and signing up for a new account using the registration form must be explicitly approved by an administrator before they can start using their account. In GitLab 13.6 and later, this setting is enabled by default for new GitLab instances. It is only applicable if sign ups are enabled.
- gitlab docs; link
The first time you access your self-hosted Gitlab it asks you to set up a password. Then you can access using user root and the password you set up. Hope it helps!
I just ran into the same problem (Vbox, VM; self-managed gitlab on my VM's static IP).
I remembered installing with export GITLAB_HOME=/srv/gitlab
sudo more /srv/gitlab/initial_root_password
in that file is a long password which I used along with root as the user.
I trey gitlab-ee-11.8 ; gitlab-ce-11.8
new user can login and create account from crowd to gitlab ;
but exist user can't.
Sign-in failed because Email has already been taken
https://docs.gitlab.com/ee/integration/omniauth.html#enable-omniauth-for-an-existing-user
Enable OmniAuth for an Existing User
Existing users can enable OmniAuth for specific providers after the account is created. For example, if the user originally signed in with LDAP, an OmniAuth provider such as Twitter can be enabled. Follow the steps below to enable an OmniAuth provider for an existing user.
Sign in normally - whether standard sign in, LDAP, or another OmniAuth provider.
Go to profile settings (the silhouette icon in the top right corner).
Select the “Account” tab.
***Under “Connected Accounts” select the desired OmniAuth provider, such as Twitter.** where ? I can't find!!!*
The user will be redirected to the provider. Once the user authorized GitLab they will be redirected back to GitLab.
follow code
button_based_providers
crowd is form_based_providers
so only twitter will have "Connected Accounts" menu
crowd not support it !
I am using GitLab Community Edition Version - 11.3.4 (30f019d).
I have integrated our Gitlab with Atlassian Crowd, Centralized login is working perfectly, now I am looking for a way to disable Standard Login tab from GitLab home Page. Since we have already granted GitLab Admin permission to my Crowd-AD account.
Team, For the same, i have disabled the below settings, Post that i can able to see only my Crowd login Section. Under Admin--> Settings--> General--> Sign-in restrictions
YouTrack supports integration with GitLab, which I would like to use.
When I create a new integration, YouTrack asks for a private token and gives me the option to navigate to my own user profile on our GitLab server to copy my token.
Does that mean that all future actions performed by YouTrack will be performed with my user account? Should I create a separate user for YouTrack?
It does mean that all future actions are performed with this user, but all those actions are read-only. The only modifying action is that if you delete/disable the integration, YouTrack will delete a web hook that it registers in GitLab.
I have a requirement to deactivate a user for a particular organization.In liferay we deactivate the user directly by control panel under users tool.if i deactivate,The user will deactivate in portal level so it is applicable to all organizations not to particular organization.so can i do manual code for this or is there any alternative by default?
User Management in Liferay is global - to the whole portal. You authenticate to the portal, thus a deactivated user can't be authenticated to the portal.
You can make users members of Organizations or site - and this membership (or other organization- or site-level roles) can be used to provide them with permissions.
If you want them to be able to sign in, don't deactivate them. If you don't want them to access a certain organization, make the content of that organization available to members only - and exclude the user from the members of that organization.
OK you could do this in code level ,
User singleUser=UserLocalServiceUtil.getUser(userId)
singleUser.setStatus(WorkflowConstants.STATUS_DENIED);
UserLocalServiceUtil.updateUser(singleUser);
So basically setting User Status to either WorkflowConstants.STATUS_DENIED, WorkflowConstants.STATUS_EXPIRED or WorkflowConstants.STATUS_INACTIVE will do the work of deactivating particular User.
But you need to research on the aftermath effect of these status field.