How to lock down "Open Command Windows here" when accessing certain auto-generated printers on XenApp 6.5

Is the problem that you might give access to command prompt that should not have it?
I would assume that the command window opens with the same privilege that the user has. Is this wrong?

So I'm not sure if this is a bug to get to a super user command prompt or not.

Can you explain your concern please? Are we just talking about keeping a command prompt from users all together?

Not sure if this article is any help or not for your use. But here it is anyway: https://discussions.citrix.com/topic/387382-citrix-xenapp-7x-windows-server-lockdown-policy-via-gpo/

I can't remove command prompt access from the system all together as some of our published applications execute/launch via command prompt/batch script.

Within the same user?

Your only option is to disable CMD all together. You will always have ways to get to it

Thanks for all your input, the issue is we can't have users have the ability to access the command prompt via any application.  The exception will be admins.

My concern was if I introduce the policy to block command line access for all, will this render my published apps that use the command prompt and launch a batch script useless?

Thanks

Perhaps I can adjust the permissions on the command prompt executable to get around this?  Will try that in a bit and report back.

Ok. I was just not sure what a user might be able to do with a command prompt as a non-admin user? (I have never really had to worry about that, so I would have to investigate what a regular user could do if they had access to the command prompt, but no privileges.)

Let us know what you decide to do.

I wasn't able to adjust the permissions on the command prompt itself, so will have to do this via some sort of policy.

Still trying to figure out what you are really trying to stop?

Wondering. If there are certain commands you want to protect, perhaps a new directory can be created with admin access only, addition to path, and move the restricted commands to that directory.  Admin use of certain “functions” should still work, but non-admin users would be unable to execute those commands.

I’ve never tried this approach but maybe it can help limit commands the prompt can use for non-admin users

I have provided screen shots and what was provided as part of the finding.  As far as the concerns about the command prompt, just wanted to note that we initiate batch scripts that run to launch programs.


The audit finding came up that we need to lock down the command line option from the context menu.

(Audit Finding)
It was possible to access the save file context menu (and thus a command window) through the print menu, using the following steps.
1. Using the Citrix "Help" menu, access the print menu using the print icon (Fig 1)
2. Check the "Print to file" option
3. Click "Print", a save file context menu will open
4. Right click and click "Open a command window here" (Fig 2)
5. Through this command prompt you can now access server resources (Fig 3)
Command_SS1.jpg
Command_SS2.jpg
Command_SS3.jpg

Ah, thank you.  It is still a bit confusing to me, but I see it does create some interesting conflicting needs.

I wish I had a better answer. It looks to me you either get locking it out, or you get it.

Maybe policy is the best solution.

Good luck.

Since this is still open hope to get some fresh ideas.  We were thinking as a workaround to this issue, we could exclude the auto-generated printers that we know this is a problem for such as Microsoft Print to PDF.  Issue - see that this is using the Citrix Universal Printer. So though I am now using the Printer driver mapping and compatibility policy within XenApp, it appears that the Universal driver will cancel this out.

Checked our Universal driver settings and it is set to use Universal Drivers only if a driver is not found.

So my thought - to locate (which I am searching for - though not having much luck) the print driver for Microsoft Print to PDF itself, install so then the policy should apply as it would have the driver and not use the universal.  And I suppose I'll have to do that for the problematic ones we discover.

Or is there a better way of managing this?

We have to rectify this by end of Feb 2019 due to audit findings and resolution date, so any thoughts are appreciated.