Steffen Heil wrote:

>>Main problem is PHP sessions are being shared across all clients, because
> there is actually only one copy of the browser running.
>
> No. Every terminal server session has it's own processes. So there should
> are at least as many sessions as clients connected.

There are several COPIES running, but they share the same set of
cookies. I am going to have to get the users to log onto TS individually
and then log into the application - I think. That takes some time, but
they will just have to put up with extra minutes on serving times :)
( A 'user' will go into an interview room and call a client - currently
login and call takes seconds because the browser is left open on a
generic login )

>>Does anybody know if it is possible to identify the client machine the
> other side of Terminal Server - as I use it as part of the security checks,
> and restrict access to the data where a terminal is in a public area -
> independent of who logs in.
>
> You want to do this from an PHP script on the server? There is propably no
> way, but THIS IS secure, since you DO NOT WANT your browser to send out any
> information about your windows session, right? Browsers do not send the
> computers name at all, computer names can be reconstructed by ips though.
> The problem is, that every terminal session uses the same host ip.

The LEGAL requirement is that terminals in public areas - like interview
rooms - must not have access to back office information - so some IP
addresses have security lockouts. That is being compromised by TS and
since the customer does not know there is a problem we now have to work
round the LEGAL requirements. Browser IP lockout works perfectly, some
data can only be accessed from specific terminals in secure areas! At
least now we know why we can't do that with TS.

>>I can't believe that this simple security step is not available - or
> perhaps I can - it is Microsoft.
>
> Actually it is absolutely possible to get an unique connection identifier
> and maybe even the clients name (but I believe, that would need some hacks),
> but not though the browser and php sessions from the server. I would
> consider THIS a security lack.

As you can see from the first two points. UserId is not a sufficient
check that the information should be available at a particular location
;) Different userid's for different areas is just not practical ;(

>>So is there any way round it or do I just tell the customer that they
> can't have THAT particular security lock ;) I've already got to rebuild the
> session software to run server side rather than client and 'enable' other
> possible security leaks :)
>
> If you have control over all clients, there might be a way, using a
> self-signed ActiveX control to send client information, and you could
> register you self-signed cert on that terminal server. Inside that activex
> control, you could use terminal services API to get the connection IDs.

Forget it - the whole point of the last four years work was to get OS
independent / browser independent operation. I just don't know how to
tell the customer that I can't supply a system that meets their
requirements on a Terminals Server System. At least we did say that
making that end work would be down to them ;) but now I have to say why
it won't :(

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services