Re: Can't connect to database - Unknown error message 84

Manoj Mohan <manojm@us.ibm.com> schrieb: >AFAIK, IDS does not cache any password information.. so there should be >another reason for this weird behavior.. Can you paste your sqlhosts for reference? Ok, this is my sqlhosts file ($INFORMIXDIR/etc/sqlhosts). There is no $INFORMIXSQLHOSTS environment variable set: opserver onipcshm <hostname> opserver_shm opserver_tcp onsoctcp <hostname> sqlexec # opserver_pam onsoctcp <hostname> sqlpam s=4,pam_serv=(informix),pamauth=(password) dbpers onipcshm <hostname> dbpers_shm dbpers_tcp onsoctcp <hostname> sqlpers As you can see, the PAM entry is commented out. There are a couple of other users with AD accounts who use ODBC and JDBC to connect to the DB server, none of them reports any of these problems. There is definitely no local user account of the same name as my AD account. I'd like to avoid having to change my password again, it's always a hassle with some other, not IDS related issues. Any other ideas how I could trace this problem? Regards, Richard

Richard Spitz wrote: > Manoj Mohan <manojm@us.ibm.com> schrieb: > >> AFAIK, IDS does not cache any password information.. so there should be >> another reason for this weird behavior.. Can you paste your sqlhosts for reference? > > Ok, this is my sqlhosts file ($INFORMIXDIR/etc/sqlhosts). There is no $INFORMIXSQLHOSTS environment variable set: > > opserver onipcshm <hostname> opserver_shm > opserver_tcp onsoctcp <hostname> sqlexec > # opserver_pam onsoctcp <hostname> sqlpam s=4,pam_serv=(informix),pamauth=(password) > dbpers onipcshm <hostname> dbpers_shm > dbpers_tcp onsoctcp <hostname> sqlpers> > As you can see, the PAM entry is commented out. But are you sure the IDS has been restarted since that comment was inserted? Just shot in the dark.... -- Clive

Clive Eisen <clive@serendipita.com> schrieb: >> As you can see, the PAM entry is commented out. > >But are you sure the IDS has been restarted since that comment was inserted? Yes, definitely. I rebooted the server after discovering the password problem, also to make sure that all caches where reset. Still puzzled, Richard

> From: Richard.Spitz@med.uni-muenchen.de > Yes, definitely. I rebooted the server after discovering the password problem, > also to make sure that all caches where reset. > > Still puzzled, > > Richard Rather than focus the problem on IDS, perhaps its a problem with your AD? Look at the problem from this angle... You're the only one who is having issues, right? I mean you just said that there are others who have changed their passwords and they are not having an issue. It could be that there is some sort of corruption in the AD server/cache. This is why I suggested changing just your password again. I'm not sure as to why this is a pain unless you've run out of pet names? ex-girlfriends? ex-wives? favorite foods? ;-) If you were to change your password and you still had trouble, then I'd get worried. While this confusing, I think you have to start to focus on the AD server. -G _________________________________________________________________ Hotmail® has ever-growing storage! Don’t worry about storage limits. http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009

Richard Spitz wrote: > Clive Eisen <clive@serendipita.com> schrieb: >>> As you can see, the PAM entry is commented out. >> But are you sure the IDS has been restarted since that comment was inserted? > > Yes, definitely. I rebooted the server after discovering the password problem, > also to make sure that all caches where reset. > > Still puzzled, > > Richard The AD can be configured to keep the old password active for some time. It's perfectly possible in a theoretical scenario to have a user authenticated with two passwords. This is possible to reproduce. BUT, it's very weird that after so long it still happens, and that it happens only to your user. In any case it would be worth to check/recheck your user properties and password policies on the AD side. Since you have restarted the IDS instance, it's impossible that the "caching" is being done by IDS. I'm not sure exactly what is sitting between IDS and AD, but you should also check that... Even if the above all makes sense there is one thing weird: Why the new password doesn't work... Can you confirm any different characteristics between the password that works and the one that doesn't? Specially the size... Maybe the special characters?... The issue with IDS "relaying" the authentication in the OS is that this isn't that simple... Usually (correct me if I'm wrong) the OS doesn't have a system function that receives a text plain password and a user and returns 0 or 1 for success or failure... IDS has to obtain the encrypted password from the OS (tipically with getpwnam()), the user and the palin password. Than it call the OS encryption function and compares the returned encrypted password with the stored password... Now... What can happen? Things like "for less than 8 characters use this() function and for more than 8 use that()". This is not an hypothetical example. It's a recently fixed issue in one specific platform. It's not IDS decision to choose which encrypted mechanism was used, but it has to use the same... if the OS changes the rules, IDS will go into problems. That's why I suggest you check for differences (besides the obvious) in your working and non working password. And than of course there's still the possible caching issue. Hope this can give you some clues... -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...