User 'informix' must be a Domain Member for ODBC Connection?
red_v...@yahoo.com
gone smoothly so far (just remember to drop distributions when
updating statistics). I downloaded and installed Open Admin Tool on
my WinXP PC to maintain the newly upgraded instance, using the CSDK
3.50 I'd already loaded. When I attempted to connect as user
'informix', I consistently received this error:
Connection Failed:
DSN:informix:host=hrmis11;service=1570;database=sysmaster;protocol=onsoctcp;server=psupg
SQLSTATE=28000, SQLDriverConnect: -951 [Informix][Informix ODBC Driver]
[Informix]Incorrect password or user info...@156.132.212.11 is not
known on the database server.
finderr reports:
-951 User username is not known on the database server.
The database server that you tried to access does not accept either
your user ID, the login name that is specified for the desired server
host in your ~/.netrc file, or the user name that is specified in the
USER clause of a CONNECT statement. If you are explicitly specifying
your user name in the ~/.netrc file or in a CONNECT statement, check
that the name is correct. If you do not have a valid user ID on the
server computer, see your system administrator. This message appears
with Version 6.0 and later.
I didn't understand why my PC's IP address was getting appended to the
informix username in the original error output.
After much googling, I found reference to this cryptic (and, I
suspect, erroneous) passage in IDS 11.50's documentation notes:
"Domain Connections that Do Not Specify a Domain Name
On Windows, if you specify a user identifier but no domain name for a
connection to a machine that expects both a domain name and a user
name (domain\user), the connection checks only the local machine and
the primary domain for the user account. If you explicitly specify a
domain name, that domain is used to search for the user account. The
attempted connection fails with error -951 if no matching domain\user
account is found on the local machine."
This precisely described the observed phenomenon -- except that my
informixserver isn't running on Windows! And, no, even if I prepended
the domain, including the wrong-slanting backslash, the error still
occurred since there is no user 'informix' in my Windows domain or a
local 'informix' account on my PC. Moreover, in further connection
tests of the CSDK 3.50 driver using Windows's Data Sources (ODBC)
applet to define the connections, I was able to connect to IDS 9.40
instances, but not IDS 10.00. Something had changed with the CSDK --
so I logged a tech support ticket.
The reported workaround was to set (undocumented) onconfig parameter
CHECKALLDOMAINSFORUSER to zero, which is the default. But if the
default is to NOT check that a user is part of a Windows domain, and
IDS is running on a non-Windows machine anyway, why do I still get the
error? If this problem analysis is correct, how many thousands of
applications has it broken?
I now need to test further by 1) adding user 'informix' to my Windows
domain; or 2) editing my informixserver onconfig file to include
"CHECKALLDOMAINSFORUSER 0". It strikes me as ludicrous -- and a
potential security risk -- to require the connection account to exist
on the client. What if I need to login as anyone of 100 different
users, say, for product test purposes?
Maybe nobody's using ODBC to connect anymore? All've gone to ADO, or
Java? Or maybe it's just my own belly button that's full of lint.
Anybody else run into this problem (hopefully everybody who's tried
using OAT)?
Fernando Nunes
I'm confused...
You upgraded an instance in HPUX? If yes, and if it's to that instance that
you're trying to connect, than the question about DOMAIN user is not relevant...
Also you mention OAT, but that apparently you're connecting using CSDK. OAT has
nothing to do with ODBC...
And since you mention HPUX and 11.50... You should check the server online.log
for errors. If you're getting there a password error (952) then check if you
have trusted security active. If yes, then check if your informix password is
longer than 8 characters, and finally, if all yes up to now, check to see if
you're using 11.50.xC3 or less... If yes, you need to change to a shorter (<=8
characters) password, or upgrade to 11.50.xc4.
HP-UX with trusted security activated uses different functions for password
encryption depending on the length of the password... Not a very smart option
from my point of view...
If you had a "no" answer above please clarify my initial doubts.
Regards.
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
red_valsen
> red_val...@yahoo.com wrote:
> > My group is upgrading IDS from 9.40 to 11.50 on HPUX 11.23. All's
> > gone smoothly so far (just remember to drop distributions when
> > updating statistics). I downloaded and installed Open Admin Tool on
> > my WinXP PC to maintain the newly upgraded instance, using the CSDK
> > 3.50 I'd already loaded. When I attempted to connect as user
> > 'informix', I consistently received this error:
>
> > Connection Failed:
> > DSN:informix:host=hrmis11;service=1570;database=sysmaster;protocol=onsoctcp;server=psupg
> > SQLSTATE=28000, SQLDriverConnect: -951 [Informix][Informix ODBC Driver]
I checked the server online log and saw this error:
18:41:36 Password Validation for user [informix] failed!
18:41:36 Check for password aging/account lock-out.
18:41:36 listener-thread: err = -952: oserr = 0: errstr =
info...@156.132.212.11: User (inform
i...@156.132.212.11)'s password is not correct for the database server.
-- so the connection is being attempted, but rejected because of
incorrect password, not because the user isn't found. But I'm able to
su to informix from the command line using the same password, and,
from the Unix command line, connect to and query the database as user
informix. But we _are_ using IDS 11.50.FC3 with HPUX, so, following
Fernando's advice, I shortened the 9-character password to 8. No
problem logging in. Maybe I should tell my IBM tech rep about this?
But how did you find out about this glitch, Fernando? Thanks alot.
Also, if OAT doesn't use ODBC, then why is "[Informix ODBC Driver]" in
the original error message (see first post)?
Fernando Nunes
good...
> -- so the connection is being attempted, but rejected because of
> incorrect password, not because the user isn't found. But I'm able to
> su to informix from the command line using the same password, and,
> from the Unix command line, connect to and query the database as user
> informix. But we _are_ using IDS 11.50.FC3 with HPUX, so, following
> Fernando's advice, I shortened the 9-character password to 8. No
> problem logging in. Maybe I should tell my IBM tech rep about this?
You don't need to do it... He can find out about it with a simple search (now
that you know what is is simple)
> But how did you find out about this glitch, Fernando? Thanks alot.
Some weeks ago while helping a customer move from 10.00.FC8 on Tru64 into 11.50
on HP-UX.
http://www-01.ibm.com/support/docview.wss?uid=swg1IC59669
This should be the APAR describing it. As of now it's giving an unknown
document error.
The defect is fixed in xC4.
>
> Also, if OAT doesn't use ODBC, then why is "[Informix ODBC Driver]" in
> the original error message (see first post)?
I may have gone completely wrong here... I think OAT uses PDO. Not sure it PDO
uses ODBC... Nevermind that.
You should consider 11.50.xC4 or a later PID (later than FC3W2) for FC3.
Of course, being so "fresh" I recommend you test it in your environment.
As a workaround you may opt for using passwords no longer than 8 chars...
I really can't understand why they decided to change the encryption function
depending on the pwd length... They could have kept the function and change the
algorithm inside...
Regards