We are using LDAP accounts in our self-managed Gitlab. A GitLab account could be locked due to an excessive amount of unsuccessful sign in attempts. We have found that an excessive amount of unsuccessful https authentication attempts also makes the account locked.
It makes sense. But, what's troubling us is that it seems if a user doesn't sign in for several days, the account gets blocked too. Some of our Gitlab users don't sign in on the Gitlab page. They simply use git pull and git push with https. If the account gets blocked, the https authentication fails too. It annoys them if they have to sign in from time to time.
Is is possible to disable Gitlab from locking an account if the user does not sign in for days?
This might be related to the configuration of your LDAP server. Specifically the remember-me token config.
See also GitLab LDAP Auth docs.
If you have an idea for improving GitLab, you can always open an issue with your feature suggestion and use case.
With GitLab 14.7 (January 2022), you now have an UI-based alternative:
GitLab UI identifies to administrators that a user is locked
In previous versions of GitLab, administrators could not see in the UI that a user was locked.
Now, the GitLab UI identifies locked users to administrators, which helps confirm they are locked.
See Documentation and Issue.
Related
So far we have always checked out our Git repositories locally via SSH and on the webserver via HTTPS.
Since the GitLab update from August 3, 2021 to version "14.1.2-ee", we noticed that GIT no longer asks for the username and password of the GitLab user during "git push". The only way to push over HTTPS at this moment is to create and add a private token.
Is this a bug in the current version of GitLab or a feature? Is there a setting somewhere to define authentication via HTTPS like before the update?
PAT (Personal Access Token) are recommended with Git to authenticate over HTTP, and mandatory if 2FA has been activated.
That being said, It depends on
what was your previous version of GitLab before this upgrade
which authentication backend your on premise 14.1.2 GitLab server is using.
If it is LDAP, then this issue seems to be similar to gitlab-org/gitlab issue 337875:
LDAP integration generates masstiv amount of invalid logins
I have updated to Version 14.1.2 yesterday since then the are huge amounts of invalid logins via LDAP on the configured AD Controller.
This locks affected ad accounts.
We have registered over 5000 failed log in events in the last 12h.
So check the server logs, and see if the affected accounts (that no longer manage to authenticate) are locked. (you can unlock one from command line, for testing).
The OP eckonator clarifies in the comments:
The error was not due to the update, but was activated CAPTCHA at the same time.
After disabling the CAPTCHA function, everything does again as usual.
I want to connect my own system to gitlab only for authentication.
After that i should be able to manage all the usernames and passwords of gitlab through my system.
Could you please help me to solve this scenario. Thank you.
That would be using the GitLab User API (as admin of your GitLab instance)
You can then add SSH keys for a user, or modify an existing user account (including their password)
You can do so through any number of GitLab API client.
I have built an integration with the Docusign API, but am unable to successfully complete the JWT auth flow with our production account.
Everything works fine in our sandbox account - I went through all the steps described in the docs (https://developers.docusign.com/esign-rest-api/guides/authentication/oauth2-jsonwebtoken),
and successfully promoted the integration key to our production account.
However, with the production account, running through the same code to initiate the JWT results in a 400 Bad Request error, with no additional information about the nature of the failure. I've double checked that we are using the correct oauth base domain (what Docusign calls aud) and that RSA keys and redirect URLs are correctly
configured for the production account.
I've also gone through all of the "go live" steps, except for one which mentions migrating users, since it doesn't seem
like this functionality is available on our production account dashboard. On the sandbox account, which has all enterprise features enabled,
the sidebar has a section for "Users and Groups" but there is no such section on our production account.
I'm wondering if the root of the problem is that our production account, which is the Basic API level account, doesn't have adequate permissions
to support the use case I'm building for.
Unfortunately I can't get a straight answer from either account reps or tech support folks as to whether this is true.
are you trying to use the same RSA key you used in Sandbox in Production by any chance?
Also, did you actually get your IK certified and active in production?
While using a paid account on github, we currently have a private repository which is forked only by contributors that work within the same network.
What is the best way to ensure that the code remains private? In other words, how can the organization restrict reading/cloning/downloading of the repository (or its forks) by a computer off network?
Thank you in advance for your help!
If you're using a version hosted on github.com, then there's no technical way to restrict access to that private repository based on the network from which the connection comes. If you need that functionality, you'll need to self-host with GitHub Enterprise Server, which is the on-premises version. You can then limit access to that server to only people on your network.
You could also enable SAML single sign-on and only allow access to GitHub if the SAML authentication comes from your network. However, do be aware that once a user has logged in, the SAML session is cached, so a user could log in while on your network and then take their laptop somewhere else and still access things. That also wouldn't prevent actually cloning a repository with a token or a key, however.
If your goal is solely to ensure that the code remains private and you generally trust your employees, you could try techniques like requiring 2FA for all employees, which makes it harder for people to compromise accounts.
TL;DR -- How do I override all internal passwords for GitLab (non-admin, non-external) users so that they cannot change their password and must use SAML to login?
We have an internal GitLab server that is set to authenticate via SAML to an AD which has MFA enabled (Azure reverse proxy).
Security has found out that users are setting a local password in GitLab and getting around MFA and logging locally into the server.
They're asking me to remove the login screen completely. I rather set an internal password for non-admin and non-external users, and somehow disable the password recovery (blocking email?). Is that possible?
This is the closest thing I found but no easy way to script that as far as I can see. https://docs.gitlab.com/ee/security/reset_root_password.html