Sign In Prohibited

Gitea Usages
1

Sign In Prohibited

Your account is prohibited to sign in, please contact your site administrator.

HI,
I’m a bit mystified why I am all of a sudden getting this message when trying to log in. As far as I am aware I am authenticated correctly (ie. if I type an incorrect password I get a Username or password is incorrect. message). This via LDAP or local.
In my postgres db prohibit_login is set to false in the user table. Is there anywhere else I should be looking ?

Many Regards

Gitea Version: 1.13.0+dev-344-g4315e313d

1 Like
2

Hey I’m getting this too, interestingly enough. I’m using LDAP auth, and it obviously authenticates me because it shows who I am and actually signs me in. I haven’t changed anything since it worked last. At least that I know of.

Is there any way to recover login access, even if it’s by creating a new user that has admin or something manually?

3

So I’m messing around with the database trying to figure out how to unlock the accounts and so far the only thing I’ve noticed is that if you set prohibit_login on the user in the user table, it will actually stop you from logging in, but the symptom that I notice right now is that you do login, it gets your avatar and your theme preferences even, but it doesn’t let you navigate to any pages without showing the prohibited page.

I’m using Gitea 1.9.

4

Hey @hwg I just fixed it. :slight_smile:

Somehow it appears that all of the user accounts were deactivated. If you check the is_active column in the database it is probably 0. Just set that to 1 and it works. Now I’m not sure how the accounts ended up in this state, though. :confused: That’s a little concerning.

On my Sqlite database I just ran:

update users set is_active = 1;

That’s assuming you want to activate every user account.

5

Yeah that fixed it for me. I saw the is_active field before and was sure I’d changed it but can only assume I did not commit it. Still I have no idea what deactivated the account. It had happened to one other account as well. Seems pretty random. Thanks for following up with this, saved me some grief.

1 Like
6

Strangely it happened to all of my accounts. I’m completely clueless of what caused it. Something to keep an eye on.

7

It has randomly happened to me again. No idea what has has triggered this. I hadn’t looked at it for a few days and it’s not in production yet. Perhaps inactivity ?

8

Maybe this is related:

I don’t seem to have logging set up very well and cannot see if that is the issue for me.

9

Hi,
I am a very beginner on truenas & surprised to have to install sqlite3 twice on the jail to update user’s rights

pkg update
pkg install sqlite3
cd /usr/local/share/gitea/data
sqlite3 gitea.db

Then make the update

pdate user set is_active = 1;
10

I think I just solved this. It turns out that the “Username Attribute” field is case sensitive and not at all optional. For Microsoft Active Directory, it has to be sAMAccountName.

Before this, every directory sync, either manual or scheduled, would deactivate the users. Also, the users would only start showing up on the Gitea user list after their first login.

My settings are as follows:

Authentication Type: LDAP (via BindDN)
Authentication Name: AD
Security Protocol: LDAPS
Host: corp.domain.com
Port: 636
Skip TLS Verify: >checked<
Bind DN: CN=LDAP read,OU=Users,OU=Administration,ou=root,DC=corp,DC=domain,DC=com
Bind Password: <encrypted...>
User Search Base: OU=Users,OU=Accounts,ou=root,DC=corp,DC=domain,DC=com
User Filter: (&(objectCategory=Person)(memberOf=CN=Git Users,OU=Roles,OU=Groups,OU=Accounts,ou=root,DC=corp,DC=domain,DC=com)(sAMAccountName=%s)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))
Admin Filter: (memberOf=CN=Git Admins,OU=Roles,OU=Groups,OU=Accounts,ou=root,DC=corp,DC=domain,DC=com)
Restricted Filter: <blank>
Username Attribute: sAMAccountName
First Name Attribute: givenName
Surname Attribute: sn
Email Attribute: mail
Public SSH Key Attribute: >blank<
Avatar Attribute: >blank<
Verify group membershipt in LDAP: >not checked<
Use Paged Search: >not checked< (might be a good idea for large environments, though)
Fetch Attributes in Bind DN Context: >not checked<
Skip local 2FA: >not checked<
Allow an empty search result to deactivate all users: >not checked<
Enable User Synchronization: >checked<
This Authentication Source is Activated: >checked<

Since I’ve fixed this the behaviour has changed. Not only are external user accounts no longer deactivated at every directory sync, but users that fulfill the criteria of the user filter are populated in the Gitea user directory right away - not only after their first login. So this might help as a hint that you solved it in your environments if the users are populated.

(edit: reformatted for better legibility)

2 Likes
11

I also had sync issues and found this post during my research. However, in my case the root cause was different. The setup in gitea was correct, but the missing part was lack of permissions for the Bind DN user account. The account I used there was only member of the default “Domain Users” group in my Active Directory. But that is not enough to read all attributes in AD (at least not anymore in newer versions of Windows Server OS - see here for more information: Understanding the Risks of Pre-Windows 2000 Compatibility Settings in Windows 2022 | Semperis)

To solve the issue in my case: I granted the Bind DN user account “Read all attributes” permission in the domain for “this object and all child objects”.
Instead for the whole domain, it should be enought to grant permissions on the OU and subtree where all required user accounts are in.