Problems upgrading 4.2 -> 5.0 with remote SQL. Login failed for user '(null)'

[Jonas Back_2]

We have had SIM 4.2 running for a couple of months now and it works perfect. It's running on a Win2003 SP1 server and the DB is a remote SQL2000 server also running Windows 2003.

We want to upgrade to SIM 5.0 but are running into problems when upgrading. I've read Installation and User Guide.pdf Chapter 7. Upgrading HP Systems Insight Manager 4.0, 4.0.1, 4.1 and 4.2 to HP Systems Insight Manager 5.0

First I made the domain user running the SIM-services System Administrator on the remote SQL2000 server. This user is also local Administrator on the server running SIM. This to make sure it had all the rights on the SQL server it needed to create new databases etc.

Ran setup.exe and chosed Custom and left everything as default on the "Software Selection" screen. First it installs OpenSSH Services successfully.

Then it moves on the HP Systems Insight Manager Setup Wizard. It asks for "Service Account Credentials" and Username: is greyed out and automtically filled with the username running the SIM services. I make sure I enter the correct password.

After that I get a screen asking for "Database configuration". Here's Username automatically filled with the correct username. I enter the correct password. Domain is already filled with the correct domain, host the correct remote SQL server. Database however is filled with "master" and grayed out so I can't change it. Port is set tp 1433 and Jar File: .\jtds-1.0.2.jar. When I press Next> all I get is an error: "The specified credentials are invalid". I'm very sure I've entered everything correctly and since 4.2 has been working for months now - it shouldn't be something wrong there.

If I check the SQL logs on the remote SQL server I can see an error in the Event Log every time I try to connect:
Event Type: Information
Event Source: MSSQLSERVER
Event Category: (4)
Event ID: 17055
Date: 2005-09-14
Time: 17:13:44
User: N/A
Computer: SQLSERVER1
Description:
18452 :
Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection.


What could be wrong?

[Joel Rubenstein]

One of the causes for this error is a password with special characters in it.

[Jonas Back_2]

You don't know which characters those are? We're using big and small letters and numbers.

I guess I could try to change the password but then I have to make sure SIM 4.2 works again. If I change the password of the users - is the only thing I need to change the password for the user on the services or are there any other special commands that I have to run to inform SIM that I have changed the password for the user in 4.2?

[Joel Rubenstein]

The special characters that give the installer problems are */\;:

[Jonas Back_2]

Thanks for that info. We don't have those letters in the password. If someone have any other ideas - let me know.

[Joel Rubenstein]

Please check your Local Security Policy --> Local Policies --> Security Options

Network Security: LAN Manager authentication level

Network security: minimum security for NTLM SSP based (including secure RPC) servers

Neither setting should be configured for NTLMv2 only or the installer credentials check will fail.

[Jonas Back_2]

Thank you very much for that info. That is exactly what we have configured since we don't want any NTLMv1/LM hashes going over our network.

Does this has to be changed on the SIM server OR SQL server or both?

Only during installation or have to remain that way?

[Joel Rubenstein]

I would try first on the SIM server and then on the SQL server. I believe you can reset the security after the upgrade.

[Jonas Back_2]

I changed the GPO on BOTH servers to "Send LM & NTLM - use NTLMv2 session security if negotiated". I did a gpupdate /force and verified in the Local Security Policy that it had changed.

Tried installing again but same problem.

Also tried rebooting the SIM server with no luck. I cannot reboot the SQL server right now since it's used in production.

[Chris Palagano]

I had the same problem....and it appears to be the SQL Server that needs to have its security changed. I pulled the SQL Server out of the locked down OU and allowed the default security options and I was able to connect.

Once I am done with the install, I am going to lock it down again and see if it causes a problem

[Jonas Back_2]

I will try that. I tried to "unsecure" those settings mentioned above but it didn't work but maybe there are some other policies that fails the SIM installation. Thanks for the tip!

[Chris Palagano · Accepted solution]

This is what I have..
Windows 2003 SP1 latest patches with SIM 5.0 installed. A seperate SQL 2000 Server running Windows 2003 SP1 latest patches.
I was unable to connect to the SQL Server, I got invalid credentials on the DB Config Page

OK...this is what I found out. When I remove the servers from my lockdown OU I was able to install fine (SIM 5.0). No invalid credentials when attaching to my SQL Server.
Once I got it up and running I dropped the servers back in the locked down OU and broke the application. By broke, I mean when I typed http://:280 I got page could not be displayed.

If I pulled only my SQL Server out of the locked down OU everything worked. I had to make the following changes to my security policies to get things working on the SQL Server

Network Security: Lan Manager Authentication Level: Send NTLM Response

Settings was Send NTLMv2 response only/refuse LM

Network Security: minimum session security for NTLM SSP based Clients and Servers

require message integrity [checked]
require message confidentiality [checked]
require NTLMv2 session security [unchecked]*
require 128 bit encryption [checked]

I set the same settings on both servers and client entries. What I had was all checked.
I am unsure if checking NTLMv2 for either clients or servers would also have worked.

As you can see, it appears to be an issue with NTLMv2. Is this a SQL Issue or a SIM app issue. I find it hard to believe it is a SQL issue since I have SQL Servers running in the locked down OU and they appear to be working...

Any further comments or verification on my comments would be appreciated.

[Aravindh Rajaram]

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=948745

In the above mentioned thread check out the document that is attached to the 71 st post (total 73) by Darrin Rawls...there are different scenarios (including the NTLM stuff) that causes the problem and the workaround for the same.

Hope this helps!

[Aravindh Rajaram]

Attaching the doc. for you...

[Jonas Back_2]

Thank you very much for that detailed response! I will look into this next week.

This is not the first time I've had this problem with HP software. We have the same problem with HP OpenView Operations that breaks when we lock down the OS with security guidelines supplied and verified by Microsoft.

I think it's real *BAD* of HP not to incestigate such problems. The only answer we got from HP regarding OVO was: "We don't support that locked down settings.". When I asked why and asked if HP don't consider security a top priority they just said "Not enough customers have asked for this feature".

So I would suggest anyone with these kind of problems with locked down OS and application to fails - open up a case with HP so they see that people actually have these problems and are really locking down the OS:es nowadays.

Again - thanks for all your help. I'll keep you posted on my progress!

[Darrin Rawls]

It's actually not that cut and dried. It turns out that if you enable certain policies in AD (or local security policies) suggested by Microsoft, you can 'lock' your server down, and render it "completely locked down". You end up telling it to 'not allow remote access' and such (just using that one as an example). It is the same as a firewall in some circumstances, you aren't getting around it...

When this is done at the OS, there's not much you can do; the OS won't allow it. Now, not all policies fall into this category, granted, and we should (and do/will) do more to see how we can peacefully co-exist with as many policies as possible. The NTLMv2 is an example... For some things that render communications 'useless' we are going to try and catch those as meaningful error messages so that it doesn't take a 70+ forum trail to discuss. :)

Definitely, log bugs with HP Support as you find stuff like this. It actually doesn't fall on deaf ears.

[Jonas Back_2]

Thanks for the info! I think it's very good HP keeps an eye on these forums since major problems probably will end up here :)

Of course you can completely lock out any user from a server and such but when you start doing these locked down OS'es you have to know what you're doing.

But what I'm talking about are those "locked down" features like LAN Manager authentication level (NTLMv2) and Minimum session security. They shouldn't break an application. Okay if you have any application 5+ years old - then I would understand but not an application that was released in 2005.

But hopefully, as you say, you will by now have noticed the problem with SIM 5.0 and those settings and fix it and probably have that in mind in future releases. Let's just hope the other HP divisions will follow and keep these settings in mind.

[Jonas Back_2]

Just want to let you all know that I reported this to HP and they confirmed it's a bug and will be fixed in a future release. But they couldn't say when it will be released.