informix@IP: Incorrect password or user informix@IP is not known on the database server.
Posted in 2020
Arjen Van Drie got error -951 (incorrect password or user not known) as informix to Informix 10 on Windows 2003 in a test domain. Others suggested trusted-host setup such as hosts.equiv, which did not help. Arjen later found the domain controller was a Samba 4 DC; it worked against a Microsoft 2012 DC. John Smith's similar AIX 14 error was fixed by granting read access to /etc/security and pwdalg.cfg.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Topics: Installation, Setup & Upgrades, SQL Development & Query Writing, Server Administration, Security, Permissions & Auditing, Platform-Specific Issues
Hi Members,
just joined 'cos I can't seem to work this one out. Been searching the Internet, but no solution that works for me.
We are running Informix 10 on windows server 2003 in an AD domain. Yes, I know it is old, both Informix and Windows, but we cannot upgrade just yet.
For the upgrade possibility to come in sight, I have set up a separate environment with a DC running a separate Windows domain, and a windows 2003 server as a member. The "informix" user is a domain user and groups such as Informix-Admin are set up. The database was backed up in production (which is a different windows domain) and restored in the test environment. Dbaccess, onstat, etc all work, as user administrator and informix. IDS runs as the domain user informix. I can auth to the domain as user informix as well (with RDP for example).
But when I try to connect over the network as user informix, I get that the password is incorrect or the user is unknown. IDS logs:
11:29:42 listener-thread: err = -951: oserr = 0: errstr =
informix@192.168.212.150
: Incorrect password or user
informix@192.168.212.150
is not known on the database server.
There is communication with the DC (tcpdump shows connections over port 445), group membership is requested and returned, but no dice. As far as I understand the concepts, the registry on the domain member also contains correct entries for IDS.
Can someone point me to the right direction?
Thanks and best regards,
Arjen Van Drie,
Antwerp, Belgium.
------------------------------
Arjen Van Drie
------------------------------
#Informix
Arjen, This user is not authenticated on the database server, this is why you have this error. Considering you run V10, which is very old yes, you should on one side authenticate the client host on the server machine at OS level: no clue on how to do this on windows. In unix this would be hosts.equiv Then you should authenticate the USER on the server. In unix, this is filling the client name in the server, home directory of the user; in the .rhosts file. If you had 12.10 or 14.10, you could use 2 files in $INFORMIXDIR/etc/ that you declare in the ONCONFIG file. This is much more simple to handle. Hoping a windows specialist will help here Regards Eric
Arjen: As Eric had said you should actually be able to use the hosts.equiv file to get around the issue you are seeing. On a Windows server this would be created by you in: "C:\\Windows\\System32\\drivers\\etc\\hosts.equiv". In this file you can list the system in question 192.168.212.150. This should then allow connections from 192.168.212.150 to the Informix instance. I do not recommend this as a permanent solution as it somewhat circumvents the Windows pass-through authentication security. Is there a reason that the system is showing up as an IP (192.168.212.150) rather than the system name or a FQDN? This may be one issue. I have found that Informix is always happier when DNS is working. Also, I would check the Windows Server's Security event log on the system hosting the Informix instance to see if there are any entries referencing the authentication error. This will give you a better idea of why your domain user is not being authorized to connect to the Informix server. ------------------------------ Best regards, Martin Graney Queues Enforth Development, Inc. Stoneham, MA 02148 ------------------------------
Hello Eric, Martin, I have tried (just now) hosts.equiv with therein the client IP address; the error remains. The reason why DNS doesn't work is because I connect from a different subnet. The subnet in which is the windows server running IDS does not know (as far as name resolving) about any other subnet. It is the router in between that allows access on a network level. The Security event log shows that authentication for user informix succeeds. Currently comparing the registry... Thanks, Arjen. ------------------------------ Arjen Van Drie ------------------------------
Hi again, I have crawled through the registry and compared it with production, looks pretty much similar. Accounts, SQLHOSTS, Groups, it is all in there. Could somewhere in the restored database itself be a reference to the production environment where it is coming from, being a different windows domain than the separate testing env? Regards, Arjen. ------------------------------ Arjen Van Drie ------------------------------
Arjen: This is definitely some kind of trusted host issue. Art Art S. Kagel, President and Principal Consultant ASK Database Management www.askdbmgt.com Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.
Thank you all for replying, I have now tried a connection from a host within the same subnet, where reverse DNS works, with an entry in C:\\WINDOWS\\system32\\drivers\\etc\\hosts.equiv like so: st98svr1.uat.gugu.be informix but still 11:37:24 listener-thread: err = -951: oserr = 0: errstr = informix@st98svr1.uat.gugu.be : Incorrect password or user informix@st98svr1.uat.gugu.be is not known on the database server. I am at a loss for the moment... ------------------------------ Arjen Van Drie ------------------------------
Hi!
How do you try to connect to the database server?
dbaccess/jdbc/odbc?
Have you tried to connect with "DOMAIN\\informix"?
------------------------------
Kind Regards
Stefan
------------------------------
Hi Stefan, thanks for picking this up, still no success here. Currently I am trying to connect with jdbc (squirrel SQL). I am 100% certain that the jdbc connection string is correct. I have tried with GUGUAT\\informix, no go... Currently building an entirely new w2k3r2 domain member with a virgin registry. Best, Arjen. ------------------------------ Arjen Van Drie ------------------------------
Hi Arjen, I also had the same issue earlier with same error. In my case someone had changed the password for unix user which was the bridge between Informix and .Net Application (SQL Server authentication) . Not sure same issue , but please try to check the user password and Informix privilege. Regards Amit Patel ------------------------------ AMIT PATEL ------------------------------
Hello All, this thread is quite old, but since I found out what was wrong I will share it here: the DC was a Samba 4 DC on Ubuntu. As soon as I tried the above on a w2k3 server as member of a Microsoft Windows 2012 DC, it worked. I haven't put more effort in it to understand why. Arjen Van Drie. ------------------------------ Arjen Van Drie ------------------------------
Hello
Have a similar issue on one server (hostname is srv1),
AIX 7.2
Informix 14
dbaccess/select database OK
dbaccess/connect/selecting/entering user/password (local account) KO,
and have following errors
on dbaccess 951: Incorrect password or user user1@srv1 is not known on the database server.
on informix log : listener-thread: err = -952: oserr = 0: errstr = user1@srv1: User (user1@srv1)'s password is not correct for the database server.
what i tried but without success :(
- changed user1 password
- added srv1 and its IP adress to /etc/hosts.equiv
- used REMOTE_SERVER_CFG REMOTE_USERS_CFG S6_USE_REMOTE_SERVER_CFG parameters
REMOTE_SERVER_CFG hosts.equiv contains srv1
REMOTE_USERS_CFG users.equiv contains user1
S6_USE_REMOTE_SERVER_CFG 1- restarted the informix server after each action
but nothing works
Any ideas ?
Thanks a lot in advance :)
------------------------------
John Smith
------------------------------
John: If the client is connecting to the remote server without a password then the problem isn't the password but rather that the client's host isn't trusted on the server host! Try adding the client's host to the /etc/hosts.equiv or to the Informix trusted host file recorded in REMOTE_SERVER_CFG in the ONCONFIG file (usually $INFORMIXDIR/etc/hosts.equiv) if your systems do not permit adding to the global /etc/hosts.equiv. Art ------------------------------ Art S. Kagel, President and Principal Consultant ASK Database Management Corp. www.askdbmgt.com ------------------------------
Hi Art
In fact, i'm testing locally on the server
dbaccess/connect/select a connection (tcp one) /entering user user1 / password (local account)
but does'nt work, KO,
if it doesn't work locally
:(
------------------------------
John Smith
------------------------------
Reading only AIX, but no Windows or AD, I'm asssuming this might be completely unrelated to any remote auth service (ldap, DC) and rather is about AIX local auth, correct? Furthermore, from the -951 error you're citing, we can assume a user/pw combo had been provided, yet failed given auth mechanism. Meaning there's no point in trying anything like hosts.equiv or any of the *_REMOTE_* configurations as they're meant for pw-less 'trusted' connections. Since this is AIX, is pwd_algorithm configured in /etc/security/login.cfg , and if so, to what value? Any such value had to be 'resolved' by a lookup in /etc/security/pwdalg.cfg, with any new auth attempt, which only would be possible with either root permissions or if caller is member of the security group, neither of which are true for the Informix process that's performing the auth. S.a. https://www.ibm.com/support/pages/951-952-when-using-loadable-password-algorithm-lpa-ie-ssha1-ssha256-blowfish-smb5-aix Possible workarounds: switch back to simple 'crypt' usage, by disabling pwd_algorithm - probably not desirable, and it would require all already existing non-crypt pws for users needing to access Informix to be recreated as simple crypt pws, by means of 'change pw' relax permissions on /etc/security dir and /etc/security/pwdalg.cfg - your security department might not like this ;-) add informix to security group switch to PAM auth (which runs with root permissions) HTH, Andreas ------------------------------ Andreas Legner ------------------------------
Hello :) Yes i was exploring this path also, Will see thanks ------------------------------ John Smith ------------------------------
Hello,
from my experience on AIX, if algorithm is not crypt, you have to use both workarounds (informix is member of security group AND PAM configuration/dbserver alias) OR you must start informix (oninit) as user root.- otherwise user inforrmix cannot connect locally with password, other users can. Remotely it is always working using password if PAM is configured.
------------------------------
Milan Rafaj
------------------------------
If you are using REMOTE_SERVER_CFG, then the file containing the trusted hosts should be in $INFORMIXDIR/etc. For example, if REMOTE_SERVER_CFG is "authfile", then the host info should be in $INFORMIXDIR/etc/authfile. Using this overrides anything in /etc/hosts.equiv for the informix authenticated connections. Also be sure that it is owned by informix:informix and that the permissions are such that ONLY informix can modify the file, e.g. 640. ------------------------------ Mike Walker ------------------------------
its worked :) add read permissions on /etc/security dir and /etc/security/pwdalg.cfg thanks a lot to all :) ------------------------------ John Smith ------------------------------
I think the minimum viable solution here would be: chmod o+x /etc/security chmod o+r /etc/security/pwdalg.cfg So you'd want it to be drwxr-x-- x 12 root security 4096 Dec 19 12:49 . and -rw-r-- r -- 1 root security 4126 Jun 01 2015 pwdalg.cfg This should also have the least impact from a security perspective. And the content of the pwdalg.cfg doesn't really bear any secrets... ------------------------------ Andreas Legner ------------------------------