I have a Solaris machine running that is connected to an LDAP. Users can login using their credentials stored in LDAP. When a user forgets his/her password, I can reset the password in LDAP and force the user to pick a new password after successful login (terminal and GUI).
Trying this on CentOS using PAM does not work (login screen just rejects the password as if it was wrong) or I am not quite sure how to configure PAM.
/etc/pam.d/password-auth-ac looks like this:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so
account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 1000 quiet
account [default=bad success=ok user_unknown=ignore] pam_ldap.so
account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password sufficient pam_unix.so sha512 shadow try_first_pass use_authtok
password sufficient pam_ldap.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_ldap.so
/etc/nsswitch.conf looks like this:
passwd: files sss ldap
shadow: files sss ldap
group: files sss ldap
netgroup: files sss ldap
...
I already looked into the configuration on the Solaris machine but that thing is ancient...
So again, what I need is that when a user successfully logs on with his/her password, the terminal will ask the user to immediately change the password.
Any help is greatly appreciated.
Related
I have a fresh install of a database on AWS. I have installed PG Admin 4 for Web and set up for a user login. This works.
I find it is not possible to connect to the localhost database using 'postgres' as a user, without a password. This appears to be enforced by the dialog. Is there a way around this enforcement? How would a user only having web access ALTER this ROLE? I would expect this to be relaxed for the initial login.
The database is local to the webserver and the web server is remote for the user.
TL:DR This logon is not a peer logon as the postgres *nix user.
It's a gap in the install. A manual step will always be required to add a password for postgres for anyone wanting to use the interface for initial USER/ROLE creation. It would be nice to have had this opportunity in the setup script.
I suppose it is expected that most administrators would also add other users/roles at this time and these would be supplied to the users. Changes to config files would still be managed. They are not getting shell access.
I stumbled upon PostgreSQL installations, where there is a PostgreSQL user with the same name as an operating system (Linux) user. If you are logged into the operating system as such a user, you can usually login to psql without specifying a username and password as this user.
How does this work? Is this a pure convention, or is there a special mechanism in PostgreSQL for this kind of behavior?
There are cases, where no corresponding PostgreSQL user is present for an operating system user. In this case, how do I create one, that can be logged into without having to specify username and password once I am logged into the operating system as this user?
There are several mechanisms. I don't know what makes a mechanism a special one, though.
The client always sends a username to the server. If you don't specify one to use then libpq-based clients look up the operating system name and use that. Some non-libpq-based clients might adopt the same convention.
For not requiring a password, maybe local connections are set to 'trust' in pg_hba.conf, in which case anyone else on the same machine can also log in to PostgreSQL as you, just by specifying your username to use, such as with -U martinw. Or maybe a password is required, but it is provided automatically via .pgpass file or via PGPASSWORD env variable, but if you set that up presumably you would remember doing so. Or maybe you have local connections set to peer in pg_hba, in which case the db server asks the OS "who is on the other end of this socket?" and verifies the answer matches the requested username (this is a common default setup, for example on Ubuntu Linux) or if a pg_ident map is in use, then it verifies the response system username is allowed to log in as the specified db username.
https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNECT-PASSFILE
create a pgpass file: vim ~/.pgpass
fill your credentials: hostname:port:database:username:password
exit file. and change ~/.pgpassfile access permission:
https://www.postgresql.org/docs/current/libpq-pgpass.html
chmod 0600 ~/.pgpass
If your linux user is the same as one of the pgpassfile user, then just type psql to connect to database.
I freshly installed Grafana and I cannot login at http://localhost:3000/login
All documentation shows that the default user/password should be admin/admin but I'm locked out.
If I go to check into the file C:\Program Files\GrafanaLabs\grafana\defaults.ini the values are set to:
[security]
# disable creation of admin user on first start of grafana
disable_initial_admin_creation = false
# default admin user, created on startup
admin_user = admin
# default admin password, can be changed before first start of grafana, or in profile settings
admin_password = admin
# used for signing
secret_key = SW2YcwTIb9zpOOhoPsMm
# current key provider used for envelope encryption, default to static value specified by secret_key
encryption_provider = secretKey
If I try to retrieve the password through the e-mail I receive no e-mail.
What am I doing wrong?
The problem come from the grafana.db file. This is where your password is stored.
In your local machine, install the sqlite3 package
sudo apt-get install sqlite3
Login into your sql database
sudo sqlite3 /var/lib/grafana/grafana.db
Reset the admin password using SQL update (the new password will be admin)
sqlite> update user set password = '59acf18b94d7eb0694c61e60ce44c110c7a683ac6a8f09580d626f90f4a242000746579358d77dd9e570e83fa24faa88a8a6', salt = 'F3FAxVm33R' where login = 'admin';
sqlite> .exit
Now, you could log in your Grafana web interface using username: admin and password: admin
Why is the login with admin:admin despite the configuration not working?
One possibility here is that you had Grafana installed previously (and when using it with the admin account already had to change the default password set in the config). In that case, you did not freshly install Grafana but instead upgraded it. That preserves the database including users and passwords, therefore you will have to use the password you set for that account.
Why are you not getting a reset password email?
I can think of two possibilities here: One is that Email is not configured in the Grafana config file and therefore no emails can be sent. The second one is that you did not set the email address for the account in question (afaik defaults to "admin#localhost") and therefore you don't get any emails. Of course it is possible that both is the case.
How can you solve this?
By either resetting the admin password (that will allow you to keep your existing data) or by removing Grafana and all files completely and making a fresh install.
New to MongoDB and databases in general but while installing MongoDB, the docs say we should use the period for the three inputs while installing (Domain,Name and Password). I did that and got this error, i used the period in all 3 inputs as the Docs said but still can't procced, what did i do wrong?
To install MongoDB as a local user you can use details as below:
Account Domain: . ( dot is the default value )
Account Name: Your Window's local username
Account Password: Your Window's login password
Note:
Your account should be local admin account or change that account to local account.
To get your local account name, you can open
Control Panel\User Accounts\User Accounts
location in your windows explorer.
This link can be helpful Installing MongoDB as Local User
As per official docs, Account Name and the Account Password is from your existing local user account.
For an existing local user account, specify a period (i.e. .) for
the Account Domain and the Account Name and the Account Password for
the user.
alternatively,
Install mongoDB as windows service as shown in below.
If error is still you need to right click on the MSI file which you downloaded and then select troubleshoot option.
After troubleshoot, it will prompt for the option to install and then it works for me
You don't have to do much in Account domain just put dot(.) And in account name you have to put your PC or local machine name and in password field put your local machine password.
Ensure Account Domain be set to the corporate domain in case you have one.
Username will be your id
i.e. in here Control Panel\User Accounts\User Accounts if you see <username>
you should set domain name in Account Domain
Username in Account Name and your password in Account Password
I stopped my db using db2stop force. The started did a backup restarted and after that
i cannot connect to db from the a client anymore i get:
using the command
db2 connect to "dbname" using "user"
SQL30082N Security processing failed
with reason "42" ("ROOT CAPABILITY
REQUIRED"). SQLSTATE=08001
password and username are correct. When im on the server connecting using command
db2 connect to "dbname"
or
db2 connect to "dbnmae" user "user"
or
db2 connect to "dbname" user db2inst1
works just fine.
I m really confused. Any help is much appreciated
Thanks.
What i tried so far :
db2 get dbm cfg | grep -i auth GSS
Plugin for Local Authorization
(LOCAL_GSSPLUGIN) = Server
Connection Authentication
(SRVCON_AUTH) = NOT_SPECIFIED
Database manager authentication
(AUTHENTICATION) = SERVER Cataloging
allowed without authority
(CATALOG_NOAUTH) = NO Trusted client
authentication
(TRUST_CLNTAUTH) = CLIENT Bypass
federated authentication
(FED_NOAUTH) = NO
switched to client but did not using
db2 update dbm cfg using
authentication client
Update:
Despite the age of this question, it would be wonderful to have a solid answer to this question. Hi locojay, how did you manage? :-)
I'm having the SQL30082N reason code 24 issue in my Windows PC, and today we experienced the same issue in an AIX server.
I googled for a couple hours and didn't find but one happy answer, related to having users with the same name both in the server and the client.
IMO it does not apply to me, as I'm running into a VBox that´s isolated from the domain (no network).
My case: I installed DB2 as user db2admin, no security. Then I granted DBADM to VIRTUALUSR01 and gave this user a password.
db2 connect to TheBase
works fine. But
db2 connect to TheBase user VIRTUALUSR01 using TheRightPassword
returns SQL30082N with reason code 24.
Using client authentication is generally a Bad Idea(TM). That's because you now rely on machines that you may not control for authentication. If I wanted to subvert your system, I could create a new user locally, say, db2inst1 or VIRTUALUSR01 or Administrator, with a password I know, and then, use that to wreak havoc on the database. If, however, no one in your organisation has root/administrator authority over their own machines, client authentication can be made to work. But all it takes is someone plugging in their own personal laptop, and your database could be at risk.
Instead, check the permissions of the files. If you've installed as root, ~db2inst1/sqllib/security/db2c[hk]pw (assuming instance ID of db2inst1) should be setuid root. If not, run db2iupdt against your instance (./db2iupdt db2inst1) which should fix the permissions.
If you've installed without root authority ("non-root install"), which I doubt, since you seem to have had this working, you would need to read the DB2 documentation on non-root installations and their limitations - I don't use non-root installs myself, so I'm not so familiar with them. However, there should be a set-root script that you can use to enable setuid root which, of course, you have to run as root.
I had the same problem and solved with the following way.
Problem occurs because of /etc/shadow file. If the user's password hash is created with SHA then DB2 cannot authenticate or authorize that user. You need MD5 for hashing that user's password.
If you are using Fedora or RedHat Linux, first change hashing method of passwords with:
# authconfig –-passalgo md5 –-update
Then drop and recreate the user:
# userdel userName
# useradd userName
# passwd userName
If you are using AIX or any other linux distros, authconfig won't work. So instead of passwd userName, issue this command:
# usermod --password `openssl passwd desiredPassword`
After that, your password hash belonging to userName will be generated with MD5.
Now grant user privilege to that user:
# su - db2inst1
(db2inst1)$ db2 connect to databaseName
(db2inst1)$ db2 GRANT DBADM with dataaccess with accessctrl on database to user userName
I hope it works for you too.
Thanks to Honza for his solution
Solutions to specific problem causes described previously in
this message are:
1. Run DB2IUPDT <InstName> to update the instance.
2. Ensure that the username created is valid. Review the DB2
General Naming Rules.
3. Ensure that catalog information is correct.