Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

How exactly do you specify the FQP (Fully Qualified Path)?

Status
Not open for further replies.

Xolotl

Technical User
Jul 18, 2003
39
US
How exactly do you specify the FQP (Fully Qualified Path)?

I am already running a Windows 2003 Server with Terminal Services in it to access a 3rd party utility in another server. The clients (all Win XP pro) do not have any problem accessing the Terminal Server to access the application. However, clients are able to see the Desktop every time they logon to the Terminal server. I found out from MS knowledge base that there is a way to prevent this from happening. Once this is setup right the terminal server will only run the application needed.

Supposedly all I have to do is to go to either Group Policies or TS configuration and enter the Fully Qualified Path of the application, but this is not happening. I am getting an error every time I try to access the Terminal Server with a client workstation.

This is what exactly I am entering as the path of the application.

Program path and file name:
C:\Program Files\3rdPartyApp\Subdirectory\App.exe

Working Directory:
C:\Program Files\3rdPartyApp\Subdirectory\

I am not sure if this has to do with the way I am entering the path of the application, but I am not sure what I am missing here. How exactly do you enter a FQP?

On the other hand, we are running a Workgroup network and not a Domain network. I do not think this has anything to do with it. Otherwise it seems to me that the application would not work at all, right?

Thnks.
 
I don't think I've heard of this term. Is it analogous to UNC? I would refer to that location by \\servername\c$\Program Files\3rdpartyapp\subdirectory\app.exe

 
If your workstations are not part of domain, then GPO settings will not matter, because GPOs apply to computers, and user accounts that are part of a domain environment.

I took have never heard of a fully qualified path. I've heard of the UNC path, or even the fully qualified domain name, which I don't think your referring to.

Could you send us the link to the article you pulled from the knowledge base ?
 
Thanks for your help on this one guys. The link to the article I was referring to is:


The term “Fully Qualified Path” is actually mentioned in the explanation of the ‘Start a program on connection’ setting, and I copied and pasted it in the following lines. It seems, like you said, that it is analogous to UNC.

///////////////////////////////////////////////////////////

Configures Terminal Services to run a specified program automatically upon connection.

You can use this setting to specify a program to run automatically when a user logs on to a remote computer.

By default, Terminal Services sessions provide access to the full Windows desktop, unless otherwise specified with this setting, by the server administrator, or by the user in configuring the client connection. Enabling this setting overrides the "Start Program" settings set by the server administrator or user. The Start menu and Windows Desktop are not displayed, and when the user exits the program the session is automatically logged off.

To use this setting, in Program path and file name, type the fully qualified path and file name of the executable file to be run when the user logs on. If necessary, in Working Directory, type the fully qualified path to the starting directory for the program. If you leave Working Directory blank, the program runs with its default working directory. If the specified program path, file name, or working directory is not the name of a valid directory, the terminal server connection fails with an error message.

If the status is set to Enabled, Terminal Services sessions automatically run the specified program and use the specified Working Directory (or the program default directory, if Working Directory is not specified) as the working directory for the program.

If the status is set to Disabled or Not Configured, Terminal Services sessions start with the full desktop, unless the server administrator or user specify otherwise. (See Computer Config\Administrative templates\Windows Components\System\Logon\"Run these programs at user logon" setting.)

Note: This setting appears in both Computer Configuration and User Configuration. If both settings are configured, the Computer Configuration setting overrides.

///////////////////////////////////////////////////////////

I also found out that the application I ma running is not an ‘exe’ extension. Instead the application (?) is a ‘hta’ extension. This may be the real problem.

I tried with an actual ‘exe’ application (Windows Media Player) and when I log on to the Terminal Server with one of the clients it goes directly into it with out any problem.
C:\Program Files\Windows Media Player\wmplayer.exe

Now I just need to figure out the ‘hta’ extension, which It seems it is related to html.
 
HTA applications although they looklike they are launched in IE are not. They are launched with MSHTA.EXE.

You might try configuring your published app to launch MSHTA.EXE and pass it the argument of your HTA application.

I have reservations as to whether or not this will work. HTA applications are a client side application and I'm not sure how the TS environment will affect that.

I hope you find this post helpful.

Regards,

Mark
 
Thanks for your input Mark. Correct me if I’m wrong, but it seems that Windows 2003 Server comes by default with some extensions, such as ‘hta’, disabled for automatic TS client connections. This might be for security reasons, right?

I am already able to get into the hta application as a client as long as I am clicking on the icon of the desktop of the Terminal Server. But when I configure it to automatically start the application then it fails.

I will try, as you suggested, to configure the publish app to launch MSHTA.EXE and hopefully this will take care of the problem. I never done this, but I imagine there is plenty of info on the web about it.
 
I would be very careful about the HTAs and MSHTA... There've been numerous vulnerabilities surrounding them. I'm just curious what 'utility' is a HTA.

I'm glad MS can standardize on a term such as UNC or FQP.
 
It works!

I used the MSHTA.EXE as Markdmac suggested. I created a batch file that calls the HTA app. It looks like this:

START "" C:\WINDOWS\system32\mshta.exe "C:\Program Files\3rdPartyApp\Subdirectory\App.hta"


Then I just went into Group Policies / 'Start a program on connection' and entered the path to the batch file and enable the policy.

Now I am concern about this MSHTA service. Apparently there are some security issues.
 
I'm just curious what 'utility' is a HTA.

HTA = Hyper Text Application

You can rename any HTM file into an HTA to have it execute locally. the cool trick with them is you can have them include vbscript.

Xolotl, you don't have security vulnerability so long as you trust where you got the HTA application from. With a published application users can't execute their own HTAs so there is no risk.

I hope you find this post helpful.

Regards,

Mark
 

Well, my paranoia is about giving untrusted users access to a trusted app on a machine. If the HTA apps (from untrusted sources) can be that much of a security vulnerability, then what potential is there for one of these untrusted users to pass malicious information to the HTA in a style resembling SQL injection.

Potential problems range from crashing a machine that's being used by however number of folks you expect to be RDPing into this thing simultaneously, to someone getting elevated rights, something much easier once a person's got console access to a machine.

It is usually a magnitude more difficult to get rights on a machine where you have none. It sounds like it is usually pretty trivial to elevate your rights once access is established. (Not that I would know where to start) But for this reason giving anyone rights on a machine through terminal services logins is something that needs to be done carefully, whether it is access to HTA files or notepad.
 
what potential is there for one of these untrusted users to pass malicious information to the HTA in a style resembling SQL injection.

Not knowing the application I could not say for certain, however I have never seen an HTA that took any form of arguments.

You need to bear in mind that the steps recommended above actually create a more secure environment. This is a published application on Terminal Services. You need to log on to access the application and then you only get the application with no access to the desktop. Close out the application and the session is ended.

Since HTAs are all inclusive, they typically utilize drop downs and radio buttons for available selections. I think you would specifically need to DESIGN an application to be the security risk you are suggesting.

I hope you find this post helpful.

Regards,

Mark
 
Hi,

Bit late, but 'fully qualified' simply means that the full path & filename.extension is included to get to that file (as in UNC, except UNC refers to 'shares' on a network).

e.g.

"c:\my docs\them docs\myfile.doc"

is fully qualified, i.e. there is no further information that you can give regarding this files' name and location.

"myfile.doc" is not, even if you are 'in' the 'them docs' folder at time of program execution.

ATB

Darrylle

Never argue with an idiot, he'll bring you down to his level - then beat you with experience. darrylles@yahoo.co.uk
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top