I have lost the Sonarqube Server admin password, want to recover that, any support will be appreciated.
Environment docker images:
sonarqube:7.9.5-community
postgres:12.5-alpine
I have gone through the previously answered block but unfortunately nothing worked out.
Best
The Idea is same as mentioned # Sonarqube Security Docs under the title "Reinstating Admin Access".
My Solution:
I had to spin up fresh Docker container in order to get the default crypted_password value. If you already know/have the crypted password value then no need to spin up fresh containers, just follow the below steps by replacing the crypted_password accordingly.
Below crypted_password value belongs to admin.
exec to postgres docker container :
docker exec -it POSTGRES-CONTAINER-NAME bash
Inside Postgres Container, login with the Credentials and follow on screen instructions:
psql -U sonar -W
Confirm the Database and Users :
select * from users;
Output must show a Sonarqube Users Table.
Then Update the password to default i.e. admin :
update users set crypted_password = '$2a$12$2NA1PhmvfPVwdwq5WeQj.Opb0z4OGYP8s2yPMRRum18bGV5nJK86W', salt=null where login = 'admin';
try login to Sonarqube server with default credentials,
ID : admin
Password : admin
To learn more about # Sonarqube Security Docs.
Related
I have a local test installation of keycloak 12 and unfortunately I've lost the admin password, any idea on how to reset it or reset the keycloak configuration without losing the realms ?
I already used add-user cli command to add a user but even with that one I can't access
The Keycloak's admin user is created only during the first initialization of the container image. Once it's created, the environment variable KEYCLOAK_PASSWORD has no effect. When restarting the pod you can see in the initialization logs:
16:16:35,881 WARN [org.keycloak.services] (ServerService Thread Pool -- 62) KC-SERVICES0104: Not creating user admin. It already exists.
To create a new admin user you should delete the current one in the database. Or just change the admin username to admin_bkp if you prefer. After this, just restart the container and the admin user is created again.
Connect to the database
$ kubectl exec -it keycloak-database-bd94f668c-rvmbt -- bashbash-5.1$ psql $ keycloak -U postgre -W
Delete or update the current admin user:
psql (12.10)
Type "help" for help.
keycloak=# update user_entity set "username"='admin_bkp' where "username"='admin';
UPDATE 1
Delete the application pod
$ kubectl delete pod keycloak-database-bd94f668c-rvmbt
Now you should be able to log in using the admin user passed through the environment variables KEYCLOAK_USER and KEYCLOAK_PASSWORD
If you are using Keycloak Docker image, you can get admin crendential using docker inspect:
docker inspect <keycloak_container_id>
then search for Config > Env, you will find KEYCLOAK_USER and KEYCLOAK_PASSWORD.
For me, I had to find the user in the user_entity table. Then delete rows in related tables. After this, I restarted the pod, and the admin user login became the one passed through the environment variables KEYCLOAK_USER and KEYCLOAK_PASSWORD.
Find the user id
select * from user_entity
Delete rows
delete from credential where user_id = '<user-id>';
delete from user_role_mapping where user_id = '<user-id>';
delete from user_entity where id = '<user-id>';
I have installed gitlab server using docker compose but after the installation I am not getting a default screen where we create first Admin user. Instead of that it is asking me to enter username and password.
If I see this correctly, the gitlab_root_password should be set in the Compose file. This should then be used to log in for the first time.
Source: https://docs.gitlab.com/ee/install/docker.html#install-gitlab-using-docker-swarm-mode
I'm trying to create a database and a user with limited privileges. The user should have access only to that database, nothing more.
In a blank slate Postgres 13 deployment using Docker, I connect with the user postgres, a superadmin, and run the following:
CREATE DATABASE db_foo;
CREATE USER usr_bar with NOINHERIT LOGIN password 'pwd1234';
That's just it. Nothing more than that. Then I connect to it with the newly created user, using psql -h <pg_host> -U usr_bar -d <db_name>.
Replacing <pg_host> with either 127.0.0.1 when running psql from the Docker host machine or with the docker container name when running psql from another docker container. Also replacing <db_name> with either postgres or db_foo; they both yield the same odd behavior.
What I expected to happen is that the login above (with usr_bar user) for any of the databases would fail due to lack of permission. Or that at least I wouldn't be able to make any changes, but I'm able to run, for instance, a create table command and it works. I would expect the user to not have any permissions by default, since no GRANT was performed.
So my question is: Why does this newly created user has so much permission by default? What am I doing wrong? If anyone can also suggest how to solve this, you're welcome; but I'd like to understand the reasoning behind it.
NOTE: For the docker image, I tried with two different ones, but had the same results. They are:
$ docker run --rm -ti -e POSTGRES_PASSWORD=root1337 --network some_net --name some-pg postgres:13
and
$ docker run --rm -ti -e POSTGRESQL_PASSWORD=root1337 --network some_net --name some-pg bitnami/postgresql:13
You are not doing anything wrong. There are two things that conspire to produce the behavior you see:
The default permissions for databases allow CONNECT and TEMP to PUBLIC, i.e., everyone.
That may seem lax, but it is mitigated by the fact that the default pg_hba.conf does not allow remote connections at all, which is restrictive.
In a way, the CONNECT permission on databases and pg_hba.conf rules overlap: they both restrict access of users to databases. I guess it was decided that being strict in one of them is good enough.
The default permissions on the public schema allow CREATE to PUBLIC.
That is an unsafe default, and the documentation recommends to REVOKE that privilege in databases.
The reason why this is not changed is backward compatibility, which is highly priced in PostgreSQL.
I'm trying to create a user for ceph dashboard with admin role. Version is Nautilus 14.2.19 and deployed with manuel installation.
I've installed dashboard module, installed all dependencies and enabled it. My dashboard is reachable from the monitor ip and default port of 8443.
When I run te command:
ceph dashboard ac-user-create <user> <pw> administrator
I get the following error:
Please specify the file containing the password/secret with "-i" option.
After digging for information about this it says there must be a file in bcrypt format. Is there a default created file for this? Or if it's needed to create one how can I do it?
Nevermind, it seems you just need to create a text file and write your password in it.
When you run the command like this:
ceph dashboard ac-user-create <user> -i /file/location administrator
It creates the user and applies the password in an encrypted format.
We use Mattermost using the 'Production Docker' setup as described in Mattermost documentation. For authentication, we federate using GitHub:Enterprise.
To setup our Mattermost team, I imported the whole Slack history. This lead to the problem that everyone who did not yet log into Mattermost via GitHub:Enterprise was not able to login. Mattermost helpfully returned the error message
"An existing user is already attached to your gitlab account"
How can I fix this issue without having to setup a new Mattermost instance and force everyone to login once before importing the Slack data?
Prerequisites
In order for this to work, you need
GitHub:Enterprise Administrator permissions
On the Mattermost machine, either root permissions or an account that is allowed to control docker, and, if psql is not installed, a way to install the psql command-line tool.
Steps
ssh into the Mattermost vm/machine (where the mattermost docker containers are running).
Change to an account with docker permissions (root; or the account you setup during Mattermost installation; or ... )
Use docker ps and note the hash of the container mattermostdocker_db. We will assume it starts with 5c23.
Run docker inspect 5c23 | grep IPAddress. Note the IP address of the container. We will assume it is 172.17.0.2.
Ensure that the psql commandline tool is installed on the machine where mattermost/docker is running.
On debian: apt-get install postgresql-client
Connect to the mattermost db of postgresql running inside the docker container:
psql -h 172.17.0.2 -p 5432 -d mattermost -U postgres -W
The (default?) password seems to be postgres.
Verify that a user account with the correct email exists. Assume the email of the account that has the problem is 'john#example.com`
mattermost-# select email, authdata from users where email = 'john#example.com';
Connect to GitHub:Enterprise and open the admin console. We will assume the local github enterprise instance is at https://github.example.com.
Click on the rocket symbol, or
https://github.example.com/stafftools
Click on all users and find the user that cannot login. We assume the github username is john, which would correspond to https://github.example.com/john
Visit the stafftools user security page for that user.
https://github.example.com/stafftools/users/john/security
Click on the 'Search logs' link under the 'Audit logs' header. This will open a page with a query field. On this page, you will find the internal github user number for that user. Note this number. We will assume the number is 37.
Back in the psql console, update the user entry with the correct number:
update users set authservice = 'gitlab', authdata = '37' where email = 'john#example.com' ;
Exit the psql console with \q:
mattermost-# \q
Done. The user can now log into Mattermost with GitHub:Enterprise user authentication.
Notes
Don't forget to complete each statement in psql with a ;
It's gitlab, not github, even if you use GitHub:Enterprise
Tested with Mattermost 3.0, GitHub:Enterprise 2.6.2