Connection Manager and password reset

[Marcus]

When you use the password reset function, it works ok. The password is reset.

When you close the interface and re-open it, it wil try to use the 'old' password. It looks like the new password is lost when closing the interface. So this results in a one time only password reset

Secondly, if HostMonitor runs under credentials wiht sufficient rights on the remote server, it wil not use the given account.

[KS-Soft]

When you use the password reset function, it works ok. The password is reset.

Do you mean "Password Generator"?

When you close the interface and re-open it, it wil try to use the 'old' password.

Do you mean "close Connection Manager dialog"? How do you close it? Using Ok or Cancel button?

Secondly, if HostMonitor runs under credentials wiht sufficient rights on the remote server, it wil not use the given account.

Quote from the manual:

Method
This parameter defines HostMonitor's behavior in case when the connection with specified remote system is already established but with different (than specified) account. Choose one of the options:
- Keep active connection
- Reconnect if necessary
With the 1st option selected HostMonitor will not drop current connection and will not establish another one. This method is guaranteed to not interfere with other applications or users already using the same connection. But on the other hand if an account that is used for connection does not have all required permissions the test may fail.
With 2nd option selected, Connection Manager will drop current connection and establish new one using specified account.

What method do you use?

Regards
Alex

[Marcus]

Do you mean "Password Generator"?

Yes.

Using Ok or Cancel button?

I assume I used the OK button (yes, pressing OK and re-opening the dialog wil drop the new password), but even when using the cancel button, the new (already remotely set password) should be saved.

What method do you use?

Both options give the same result.

[KS-Soft]

I assume I used the OK button (yes, pressing OK and re-opening the dialog wil drop the new password), but even when using the cancel button, the new (already remotely set password) should be saved.

I tried many times but cannot reproduce this problem. Are you selecting one or many accounts to change password? Did you edit accounts before password generation? What exactly sequence?

Secondly, if HostMonitor runs under credentials wiht sufficient rights on the remote server, it wil not use the given account.

What HostMonitor says in the log?

Regards
Alex

[Marcus]

What exactly sequence?

I log in to a TS session, stop the service and start HostMonitor with the /stop parameter.

- Open the connection manager using profiles->connection manager
- Select Password generator and generate a 14 character length password (which was defined before)
This all goes OK, the password is changed on the remote server.

- Press the OK button and again open the connection manager (nothing else between).
- Select Password generator and generate a 14 character length password. This fails! After resetting the account on the remote server to the original password, this goes OK, which concludes me to: The new password is not saved by HostMonitor

All above is done with one single resource already defined. No new settings are made during these actions. All none default settings are done at a different time, after which HostMonitor is restarted at least once (in fact a lot more, but I don't know the exact count).
We use as resource the remote server name (\\<server>) and as server or domain the name of the server (<server>), since it is a local server account, not a domain account.
The method used is: Reconnect if necessary

What HostMonitor says in the log?

There is no log for failed authentication. And the first thing I've done was enabling this option. The results of the password generator are logged and are consistent with the interface.

We did an upgrade from 4.16 to 4.40 in two steps:
1. Run the upgrade, which failed with a locked hostmonitor.exe and powerp32.dll (the service was stopped, but Windows decided different)
2. Disable the service, restart the server and performed another upgrade.

If the above could cause the failure, we could perform a upgrade from the previous version (4.16), which we saved before starting the upgrade (but this would result in loss of changes since the upgrade )

[KS-Soft]

At least I reproduced problem with passwords. There is update at www.ks-soft.net/download/hm440d.zip

There is no log for failed authentication. And the first thing I've done was enabling this option. The results of the password generator are logged and are consistent with the interface.

No, I was asked about another log. Connection Manager log, default name "ConnMgr.log"

Regards
Alex

[Marcus]

No, I was asked about another log

That's the one I meant It's configured, but just not there......

[KS-Soft]

H'm, if file is empty (or doesn't exist at all), it means HostMonitor successfully established connections. Try to setup wrong user name or password, you should see error message in the log.

Regards
Alex

[mmonaghan]

Marcus,

Try "net use" at the command prompt. It will show you a list of mappings. There will probably be one matching the path in the test but without a drive letter assigned to it. If it is there, HM authenticated sucessfully and something else it wrong.

If it is missing. HM did not authenticate. Verify that your path is correct in the test and the connection manager. I'm betting it is right, but it never hurts to check.

Alex,

I'd like to suggest that the path be inclusive in the Connection manager. After upgrading I've had a heck of a time getting it to work. I don't believe the tests are trying the connection manager everytime the authentication fails. Here's an example:

HM 4.40, No RMAs, remote customer system over a VPN. The remote system is in a domain and I have several valid accounts to test against.

I setup a file count against \\10.2.0.35\c$\faxqueue\ and added \\10.2.0.35\c$\faxqueue (note the trailing slash) to the Connection Manager and hit the Count Files check. It works.

Next I setup several UNC tests fpr \\10.2.0.30\c$\ , \\10.2.0.30\d$\ , \\10.2.0.30\e$\. No combination of paths in Connection Manager worked. I tried \\10.2.0.30\c$ , \\10.2.0.30\ and a bunch more but it seems like the connection manager never tried to use its credentials. Nothing in the ConnMgr.Log except real failures I induced. That means the log is on, but Connection Manager never tried. A pass with the sniffer supports this. I put "user@remote.local" and password into the tests directly and it worked. I never could get connection manager to take over authentication no mater what I did on these tests.

A few suggestions:
- Paths should have the same trailing \ in tests and connection manager. Tests add the slash and Connection Manager removes it. (I know this is cosmetic)
- If I put \\10.2.0.30\ in connection manager it should cover all lower paths on the same system. Example \\10.2.0.30\c$ would "match" against \\10.2.0.30\.
- If a more specific match is found use it. Example \\10.2.0.30\ and \\10.2.0.30\c$\temp\ are listed in the Connection Manager.

It tests:
\\10.2.0.30\c$\temp\ would use the credentials for \\10.2.0.30\c$\temp\
\\10.2.0.30\c$\temp\new\ would use \\10.2.0.30\c$\temp\
\\10.2.0.30\c$\ would use \\10.2.0.30\

In other words you'd search up the tree until you hit a path match and use those credentials. This will make those of us who need to test 40+ drives on a single box a bit more sane. I can't count the number of "cut and paste" errors I've suffered.

Hope this helps on both fronts,
Mike

[Marcus]

Try "net use" at the command prompt. It will show you a list of mappings

When checking the security logs on the remote machine I only see valid connections for the account which is used to start HostMonitor as a service. There isn't a failure with another account. The Reconnect if necessary option should disconnect before connecting. So either HostMonitor performs no disconnect or uses the current credentials (I presume the last one)

it seems like the connection manager never tried to use its credentials. Nothing in the ConnMgr.Log except real failures I induced. That means the log is on, but Connection Manager never tried

So this is the same as with our situation. It looks like HostMonitor first tries to connect with it's current credentials. If HostMonitor is running under the system account, this wil always result in a failure and connection manager wil be called. (at least this is how I see it now)

Our problem is that HostMonitor is running with a user account with sufficient rights to perform the tests. It seems that the first action for a test should be a check with Connection Manager if there is a entry for the test and use it when available.

[Marcus]

Resetting passwords, using password generator now works OK.
But HostMonitor still connects using it's startup account and not the account defined in connection manager.

[mmonaghan]

Marcus,

You're correct that no matter how you set the Connection Manager that it tries to connect with the current credentials first. If it suceeds then it has not reason to try any others.

HM is running as an application for the moment under a admin flagged account. This account is meaningless to the remote subnet so authentication always fails. On short paths (rooted) on the remote systems, connection manager never tries to authenticate. I only get once pass of ntlm and then it dies.

BTW try net use on the HM machine. It will show you what it has connections to (out bound). I'n not sure there's an easy reliable way to see who is connected inbound but you might try net share and net session.

Mike

[Marcus]

BTW try net use on the HM machine. It will show you what it has connections to (out bound). I'n not sure there's an easy reliable way to see who is connected inbound but you might try net share and net session.

I log all authentication actions (failures and success) on the remote machine and I only see the account used to startup the service. No connection is tried with the account specified in the Connection Manager.

What I also see is that when the password is changed, this is not done under the user credentials of the account specified in the Connection Manager, but with the account used to start HostMonitor as a service (or the logged in account, which is the same in my case so I don't exactly see the difference). This presents us with another problem: The account used by HostMonitor, must exist and have appropiete permissions on the remote machines. If this is functionality is not changed, there is no need for us to start implementing seperate accounts for remote machines.

The big advantage of a Connection Manager like piece of software is that is allows us to define an account on a remote machine, with a simple default password, and let Connection Manager take control over the password. Then the monitoring account could be changed more frequently and more difficult passwords can be implemented. Most preferable it should be the Connection Manager who can be scheduled to perform a change of the password every x days (don't forget a history, because what will happen if a machine can't be reached?).

This eventually can result in a seperation of machine accounts and real user accounts. On the moment we use 1 account for all our monitoring, using the same password on all servers. When software can take control over the password, it will allow us to change the password more frequent than we do now, use longer and more difficult passwords and with that increase the security of the remote machines.

But since this is only the first implementation of the Connection Manager, we are confident the functionality will improve

[KS-Soft]

- If I put \\10.2.0.30\ in connection manager it should cover all lower paths on the same system. Example \\10.2.0.30\c$ would "match" against \\10.2.0.30\.
- If a more specific match is found use it. Example \\10.2.0.30\ and \\10.2.0.30\c$\temp\ are listed in the Connection Manager.
It tests:
\\10.2.0.30\c$\temp\ would use the credentials for \\10.2.0.30\c$\temp\
\\10.2.0.30\c$\temp\new\ would use \\10.2.0.30\c$\temp\
\\10.2.0.30\c$\ would use \\10.2.0.30\

Its how Connection Manager works

I setup a file count against \\10.2.0.35\c$\faxqueue\ and added \\10.2.0.35\c$\faxqueue (note the trailing slash) to the Connection Manager and hit the Count Files check. It works.

Don't worry about slash, Connection Manager understands - "\\10.2.0.35\c$\faxqueue" and "\\10.2.0.35\c$\faxqueue\" is the same resource

Next I setup several UNC tests fpr \\10.2.0.30\c$\ , \\10.2.0.30\d$\ , \\10.2.0.30\e$\. No combination of paths in Connection Manager worked. I tried \\10.2.0.30\c$ , \\10.2.0.30\ and a bunch more but it seems like the connection manager never tried to use its credentials. Nothing in the ConnMgr.Log except real failures I induced. That means the log is on, but Connection Manager never tried. A pass with the sniffer supports this. I put "user@remote.local" and password into the tests directly and it worked. I never could get connection manager to take over authentication no mater what I did on these tests.

Do you mean you have UNC test that checks "\\10.2.0.30\c$\" and Connection Manager has record for "\\10.2.0.30\c$" but Connection Manager did not try to establish connection?

Regards
Alex

[KS-Soft]

The Reconnect if necessary option should disconnect before connecting.

Not exactly.
1) HostMonitor tries to connect to remote system using specified account.
2) if Windows returns ERROR_SESSION_CREDENTIAL_CONFLICT error code and "Reconnect if necessary" option is set, HostMonitor tries to drop current connection and establish new one.

You're correct that no matter how you set the Connection Manager that it tries to connect with the current credentials first. If it suceeds then it has not reason to try any others.

Not exactly. I found this problem as well and investigate it using debugger and sniffer. Connection Manager calls Windows API using account that you have specified (I am 100% sure, I checked it again and again). But in many cases WINDOWS uses current user account!!! Why? I don't have any idea.

Regards
Alex