Cached credentials for RCC - still wishing

KS-Soft · Post by **KS-Soft** » Fri Jul 14, 2006 11:54 am

I have upgraded to version 6.10 in the hope that it may have fixed this long standing problem. It still does not work.

Sure - we do not see any mistake in our code, so we changed nothing in new version.

It seems to me that he did not test cached credentials in the registry but rather just to the RCC.ini file. Otherwise why would he be having issues with a xxx.ini file.

RCC always uses ini file. If you have specified "-uniqueprofiles" option, RCC uses registry and it also uses ini file to save some options.

Anyway, Max (KS-Soft Europe) tested RCC again. There is his answer
=========
HostMonitor is running on Windows 2003 server with SP1. Terminal service is configured on that server. Client - WinXP SP2.
We have connected to Win 2003 server thru RDP client from WinXP using credentials of the user, that is only member of "Users" and "Remote Desktop Users" groups. It was really remote session, not console. RCC short cut uses the following command "D:\Program Files\HostMonitor6\rcc.exe" -uniqueprofiles -storepassword
I was not able to reproduce the problem using this configuration. Also we were trying to connect thru terminal service from Win 2000 SP4 machine and from Linux using rdesktop tool. RCC works perfectly with cached credentials in all cases.
Please note, we have not changhed default security level on windows machines. So, I assume, the problem you have faced relates to security policy in your network. Sorry, we are not able to reproduce the problem.

Regards,
Max
===========

My best quess is that it relates to the RCC program dialogue not being in focus when the credentials are retrieved from the registry and applied.

H'm.. I don't think so. Because
1) RCC reads data from the registry and from ini file on the same stage.
2) Application may change data assigned to the control element even if element is not visible. Application cannot focus this element, but it may change data without problems

Regards
Alex

terje · Post by **terje** » Sun Jul 16, 2006 3:44 pm

Thanks for the clarification, especially with regards to the earlier comment about the RCC.ini file.

It is obviously security related because it does not effect Domain Admins on our network. The problem has been in trying to locate what file, registry key or other object is getting blocked by security.

I am sorry for the trouble however without understanding what else the program needs access to I have so far been stumped by this problem. Whether you call it a bug or you call it a problem with security settings either way it is a problem that I can't resolve on my own.

On the terminal server the RCC.exe program resides in the following folder:-

C:\Program Files\Hostmonitor5

All users have full control in this director. All users have full control on RCC.exe and other program files in this directory.

Also access to the relevant registry keys appear to be unimpeded by security as the credentials get saved into the registry okay.

So it seems that the security issue relates somehow to the stage when the credentials are retrieved from the registry and populated into the opening dialogue box. However I don't know what security settings or which objects to check in this regard.

Once again I am sorry for the trouble, however any assistance would be appreciated.

Yoorix · Post by **Yoorix** » Mon Jul 17, 2006 3:26 am

Could I ask you a small question? RCC allows you to work with HostMonitor which is running on a remote system just like you work with HostMonitor. So, I do not understand, why do you use Terminal Service? You just need to copy rcc.exe and rcc.ini to certain user machine. As I understand, there are no problems with cached credentials when RCC is running locally on client machine.

Regards,
Yoorix

KS-Soft · Post by **KS-Soft** » Mon Jul 17, 2006 10:38 am

I am sorry for the trouble however without understanding what else the program needs access to I have so far been stumped by this problem.

However RCC still does not start with the creditials entered. They are all blank each time it starts

"Blank fields" means RCC has accessed registry key \Software\KS-Soft\RCC\LastConnection but then it cannot read any data from this key.
More specific: Windows API RegOpenKeyEx returns ERROR_SUCCESS (0)code.
Otherwise: If RCC cannot open this key (e.g. key does not exists), then RCC will read data from ini file and you will not see blank fields.

Regards
Alex

terje · Post by **terje** » Mon Jul 17, 2006 11:04 pm

So, I do not understand, why do you use Terminal Service? You just need to copy rcc.exe and rcc.ini to certain user machine.

Yoorix,

We have a team of engineers (about 10) that spend about 2 hours per week at their PC in the office. The rest of the week they are at customer sites (many and varied) and the machine that they are working from at any given time varies a lot. The will also log in and out several times a day depending on their schedule.

At each site they typically locate themselves at a server or workstation. In order to access resources like email, intranet knowledgebases etc they will create an RDP session across the network back to the central terminal server.

We need to install all the applications we access routinely on the terminal server because it is not practical to reinstall every application every time we move to a new site and a new PC (which can be several times a day).

Obviously RCC is great because it allows all these mobile engineers to review what is happening in hostmonitor. And hostmonitor is great because he gives them a quick visual of the health of all our clients. It lets then change the priority for the day if they spot a problem.

However because they log in and out several times a day and because most days RCC will not reveal anything out of the ordinary it is pretty easy to get sloppy and skip the login. Sure we can beat them up and say you must log in to RCC every single time you log into terminal server but that is kind of like telling smart people how to chew gum. Mostly they do the right thing but it would be good to avoid the double login because RCC is not the only resource they are accessing.

I hope this helps to set the scene a little better.

Regards,
Terje.

terje · Post by **terje** » Mon Jul 17, 2006 11:13 pm

"Blank fields" means RCC has accessed registry key \Software\KS-Soft\RCC\LastConnection but then it cannot read any data from this key.
More specific: Windows API RegOpenKeyEx returns ERROR_SUCCESS (0)code.
Otherwise: If RCC cannot open this key (e.g. key does not exists), then RCC will read data from ini file and you will not see blank fields.

Regards
Alex

Alex,

With my personal AD account on our terminal server I do not have administrator rights. I am currently logged on to the terminal server and using REGEDIT I can open the following key:-

HKEY_CURRENT_USER\Software\KS-Soft\RCC\LastConnection

If I check the permissions on this key it says that my account has full control.

If I look at the values under this key there are serveral. Amoungst them are the following:-

HOST: ssyd-app01
LOGIN: terje
PSWD: trj

If I log onto RCC using a different operator account then these details change in the registry.

However I still face the problem that when I open RCC the fields in the applications dialogue box remain blank and must be repopulated manually every time.

In other words RCC can populate the registry and RCC should have full access to the registry key but it can't seem to do anything useful with it. When we ran REGMON (results shown on page two of this discussion) it suggested that RCC was successful in retrieving the registry values. So it seems to me that it is having problems after that point.

A snippet of the earlier REGMON log is included below:-

151 83.12029266 rcc.exe:2992 QueryValue HKCU\Software\KS-Soft\RCC\LastConnection\Pswd SUCCESS "trj"

151 is an event sequence number produced by REGMON.
83.12029266 is the time of the event after REGMON started monitoring the system.
rcc.exe is the program in question (followed by the PID and registry key in question).
QueryValue shows that it is reading the key.
SUCCESS says it got the value.
"trj" shows the value it got, ie my Hostmonitor password.

I have run REGMON many times and RCC seems to store and retrieve the information correctly. It just seems unable to use it.

KS-Soft · Post by **KS-Soft** » Fri Jul 21, 2006 3:31 pm

I checked our code once more. And I still cannot explain this behavour

Regards
Alex

terje · Post by **terje** » Sun Jul 23, 2006 7:20 pm

Are there any windows files that get called at this point in the process that might be effected by permissions?

KS-Soft · Post by **KS-Soft** » Mon Jul 24, 2006 6:07 am

I uploaded test program at www.hostmonitor.biz/download/test/regtest.exe
It uses code similar to RCC but this is console application, it shows simple log on screen.
Could you start it and send log back to us (support@ks-soft.net)?

Regards
Alex

terje · Post by **terje** » Mon Jul 24, 2006 6:28 pm

I will email the data to the email address, however I have repeated it below.

Firstly here is what I get if I login to terminal server remotely using my normal account (ie non-admin) and then run the test program.

C:\temp>regtest
Reg init .. Ok
Reg open .. Ok
Host: ssyd-app01
User: terje
Port: 1054
Time: 12
Refr: 30
Conf: FALSE
Pswd: trj
Reg close .. Ok
Reg open .. Ok
tmp: FALSE
tmp: FALSE
tmp:
tmp:
Error: Failed to get data for 'SoundRepeat'
readed: TRUE

Next I went to the console (ie I was no longer remote to the terminal server) and did a login using a domain administrator account. Then I ran the test program and got this result.

C:\temp>regtest
Reg init .. Ok
Reg open .. Ok
Host: ssyd-app01
User: rohan
Port: 1054
Time: 12
Refr: 30
Conf: TRUE
Pswd: rs
Reg close .. Ok
Reg open .. Ok
tmp: FALSE
tmp: FALSE
tmp:
tmp:
Error: Failed to get data for 'SoundRepeat'
readed: TRUE

KS-Soft · Post by **KS-Soft** » Tue Jul 25, 2006 2:58 am

Still cannot explain your problem. But I made some changes in the code, may be it can help www.ks-soft.net/download/rcc166b.zip

Regards
Alex

terje · Post by **terje** » Tue Jul 25, 2006 5:57 am

The new program suffers the same problem. However in testing it I discovered something that may cast some light on the problem and if nothing else gives me a work around.

Originally RCC.exe had the following path that I had created manually:-

C:\Program Files\Hostmonitor5\RCC.exe

Within this path the Hostmonitor5 folder (and contents) has the NTFS permissions set such that all users have full control. And the relevent shortcut that points to this executable has the relevant command line parameters to store the password in the registry etc.

When I downloaded your new program I created a brand new path as follows:-

C:\PF\Hostmonitor5\RCC.exe

And I pointed a new shortcut to this version of the executable. It worked fine and I initially thought your new code had fixed the problem.

However I then moved the new code to the old path and the problem returned. So I tried moving the old code to the new path and the problem went away.

I have checked the NTFS permissions again on the original folder and they are definitely full control. I have also reviewed the "effective permissions" for the account I am using and they show that for both this Hostmonitor5 folder and the RCC.exe program my account has all permissions effectively enabled.

The only difference I can discern between the two paths is that the permissions on the parent folder "PF" are broader than they are on "Program Files". However on the latter my account has all the default user permissions such as traversal and read. Note that the Hostmonitor5 folder under "Program Files" has its permissions set explicitly rather than using inheritance.

So it seems that with the old code I can get it all to work so long as the program folder does not reside inside "Program Files". This is an irritation but not a show stopper.

Any clues on why the RCC.exe program might get bothered by permissions on the parent folder in this way? None of the other program I have any problem residing within the "Program Files" path.

The permissions on the "Program Files" directory seem to be just the default permissions that you get when you setup Terminal Server. So I am guessing that this problem might be repeatable on another terminal server if the same path was used. I may test that when I am next in the office (a few days from now).

KS-Soft · Post by **KS-Soft** » Tue Jul 25, 2006 11:08 am

H'm...

I assume you did not start regtest.exe (console test application) from RCC folder, right? Could you start it from "C:\Program Files\Hostmonitor5" folder?

Regards
Alex

terje · Post by **terje** » Tue Jul 25, 2006 7:29 pm

I put a copy of Regtest in the directory that I am now running RCC successfully from. As well as in the original directory (where a copy of RCC.exe still resides).

The following test was done on a remote terminal server session using my account (non-admin).

H:\>c:

C:\>cd program files

C:\Program Files>cd hostmonitor5

C:\Program Files\Hostmonitor5>regtest
Reg init .. Ok
Reg open .. Ok
Host: ssyd-app01
User: terje
Port: 1054
Time: 12
Refr: 30
Conf: FALSE
Pswd: trj
Reg close .. Ok
Reg open .. Ok
tmp: FALSE
tmp: FALSE
tmp:
tmp:
Error: Failed to get data for 'SoundRepeat'
readed: TRUE

C:\Program Files\Hostmonitor5>cd ..

C:\Program Files>cd ..

C:\>cd hostmonitor

C:\hostmonitor>regtest
Reg init .. Ok
Reg open .. Ok
Host: ssyd-app01
User: terje
Port: 1054
Time: 12
Refr: 30
Conf: FALSE
Pswd: trj
Reg close .. Ok
Reg open .. Ok
tmp: FALSE
tmp: FALSE
tmp:
tmp:
Error: Failed to get data for 'SoundRepeat'
readed: TRUE

C:\hostmonitor>

KS-Soft · Post by **KS-Soft** » Wed Jul 26, 2006 9:37 am

Looks like test program is able to read data regardless of the "work" directory while RCC works anywhere except "Program Files"? As usually I cannot explain bahavior of your system

Regards
Alex