Re: RDP Printing by station

Hey TP;

yes, that assumption is correct, my apologies for not being clearer
about that. Some stations can print, others can not. Additionally,
some users can print and others can not. Basically, the most
restrictive of the combo 'wins' and the user can either print or not
print. IP addresses will more often than not be dynamic addresses.

1) It's "possible" that we could force all non-printing computers to
use a static address. That and/or the clientname could be used in much
the same way as I'd thought about for the MAC address. Is it possible
to obtain either the client name or ip address (ip address would work
better, but I'll have to go over the ramifications of both) from within
the session through an API call?

2) I'll have to do some research into the Virtual Channel option. You
kind lost me there... I'm guessing here, but are you referring to
something similar to a VPN tunnel where if a TS client session
authenticates to a 3rd party software then this virtual session is
created and you can print through it?

Using option 1 and writing the requirement for a static IP and/or
clientname for printing machines as part of the contract when a client
buys the software sounds easier!

Cheers, Jef

On Dec 13, 10:05 am, "TP" <tperson.knowsp...@xxxxxxxxxxxxxxx> wrote:
Okay, I was hoping that *all* of the stations that you wanted
to *allow* printing from would be from static ips, that way
we could use a combo of ipsec and different listener settings to
accomplish your goal. My understanding now is that you may
have some stations at given site that allow printing, and some
that do not, and that these stations may or may not be coming
from different public ips, and may or may not have static ips.

Regarding WTSClientHardware, it is not used for RDP
connections, it will always return 0. MAC addresses are
usually unique, but do not forget that the end user can manually
set the MAC address if they want.

The fact that you have control over the application code gives
us lots of options. For example:

1.) You could use client name, but that is not guaranteed to be
unique (although it is likely to be unique at a given physical
location). Like the MAC address, the name is configurable by
the PC admin, so that may not meet your security requirements.
Clientname is exposed as an environment variable, making it
easier to access by novice programmers.

2.) You could "roll your own" method using virtual channels. This
would allow you to check the MAC address, or maybe a combination
of things like MAC address, HD serial number, etc. Your application
on the server could first check for your virtual channel, if it doesn't
exist disable printing. If the channel does exist obtain the unique id from
the client, check if printing is permitted, and enable/disable printing
accordingly.

The downside of this approach is that you will have to deploy additional
software (besides the TS client) to machines that will print. Machines
that will be denied printing capability would not need the additional
software piece. If you are using TSWeb you could deploy your client
software piece that way.

Please let me know if you have any questions and what your thoughts
are.

Thanks.

-TP

flippergonzo wrote:
Hey TP,

the stations that are to be denied printing at not going to typically
have static IPs. In some cases we will be able to give them statics,
but overall it's not something that I can count on being able to
control at every customer site.

I'm planning on using both auto created printers (redirected) and
network printers configured on the terminal server(s) with the
printers physically located at the customer site.

A more specific idea of the customers and reasons for this might help.
The scenario is actually for medical software and regulations
stipulate that you must be able to deny certain computers (in a exam
room for instance) from printing from that application.

The application used generally is a custom application so it could
definitely be changed. The best way that I can think of would be to
allow/deny based upon the MAC address since they will be unique (in
theory at least!) and we can add those addresses to an approve/deny
list within the application. So the application would have to be
changed to obtain the MAC address of the Terminal client for that
session and compare it to the predefined list.

If my way of thinking is correct, then my question is how would one
request the MAC address of the terminal client session? (This is why
I'd also inquired if the WTSClientHardwareId references the MAC
address of the client.)

One last question...if the
WTSQuerySessionInformation/WTSClientHardwareId is the solution, does
anyone know if these queries work when pointing at a Mac OS X RDP
client?

Thanks again!

.

Relevant Pages

  • Re: RDP Printing by station
    ... Okay, I was hoping that *all* of the stations that you wanted to *allow* printing from would be from static ips, that way we could use a combo of ipsec and different listener settings to accomplish your goal. ... MAC addresses are usually unique, but do not forget that the end user can manually set the MAC address if they want. ... If the channel does exist obtain the unique id from the client, check if printing is permitted, and enable/disable printing accordingly. ...
    (microsoft.public.windows.terminal_services)
  • RE: Mac file names too long??
    ... Thank you for posting in SBS newsgroup. ... Generally speaking, for the SBS 2003 domain with MAC clients, some ... You can check the white paper and ensure both the server and the clients ... and client correctly: [note: please notice the ISA section of the bottom of ...
    (microsoft.public.windows.server.sbs)
  • Re: Mac file names too long??
    ... > Thank you for posting in SBS newsgroup. ... > networking settings on the MAC; modify the directory service options; ... > some settings on the SBS server need to be changed. ... > I. Check the TCP/IP properties of the MAC client. ...
    (microsoft.public.windows.server.sbs)
  • RE: MAC client cannot access web site via ISA 2004
    ... I understand the issue to be: MAC client cannot ... browse the web site on web server which you have published. ... Generally speaking, for the SBS 2003 domain with MAC clients, some ...
    (microsoft.public.windows.server.sbs)
  • SonicWall Officially drops support for Macintosh
    ... SonicWall is being officially dropped from my preferred ... another VPN client does not constitute a recommendation of that product. ... gateway or a client installed on a PC, Mac, etc.) will be coming from. ...
    (comp.security.firewalls)
Loading