Novell Client 4.91 doesn't work through Remote Desktop Connection
Pavels Ruhmans
when we upgrade client from 4.90 SP1 to 4.91 SP1. The problem is following -
whene the user logs on on console after that any user which connects through
RDP to the same computer - there is no Novell Login instead of that display
Microsoft Login screen as it would suggest me to reconnect to the session.
But when the user logs out from the console Novell Login works ok even with
multiple users which connects through RDP.
When we are using Novell Client 4.90 SP1 - this problem doesn't appears.
Alan Adams
interaction with Remote Desktop, and I think the difference in
behavior you're describing is one of them.
The explanation I've heard as to why you're seeing "a Novell dialog
that prompts only for Windows login information" instead of "a regular
Novell login dialog" is because Remote Desktop is a Windows feature,
and Windows itself evaluates the permissions of the Windows user
account to determine whether you have enough authority to unlock/take
over the Remote Desktop session.
i.e. They could prompt for an NDS user account too, but it's not being
used for anything. Windows makes the Remote Desktop decision based
purely on the Windows account specified. You will either be allowed
to unlock the Remote Desktop session, or you will be allowed to force
an administrative logoff of the existing Remote Desktop session, or
you will be denied access -- all based on the permissions of the
Windows user account.
When there isn't an existing Windows and/or Remote Desktop session in
progress, you do see the full Novell login dialog because you're
establishing a new login (not taking over or forcing logoff of an
existing session).
4.90 had other issues with Remote Desktop that would cause the full
Novell login dialog to re-appear two and even three times when trying
to use Remote Desktop. 4.91 and later appear to have fixed these
issues, along with only prompting for "the credentials that matter" in
the situations that require them.
A previous poster here pointed out that with a ZENworks DLU policy
environment, users may not have ever been specifying their Windows
user account, and/or may not necessarily know the password for it. I
agree that seems like it would be an issue with this new Remote
Desktop handling, if the user truly doesn't know their Windows account
credentials.
"Pavels Ruhmans" <elk...@inbox.lv> wrote:
Alan Adams
alancru...@drcrumb.com
(for email, remove the crumbs)
Pavels Ruhmans
is no any option for different behaviour. We use Win XP like a terminal
server and every user which connects to the server uses its own login name.
And the user also uses the computer as workstation locally.
I suppose there should be a choice for two different usage of remote
sessions. For the way of usage you've described - it suites only for the
single user who connects from different places. I suppose that is all of
that the user on the console cannot do disconnect of the session. Any other
users can disconnect its own session and reconnect to it.
"Alan Adams" <alancru...@drcrumb.com> wrote in message
news:ovuul1p0u4kl7acar...@4ax.com...
Alan Adams
Win XP like a terminal server", but Remote Desktop is essentially a
"single user terminal server", with _all_ consoles and terminals
fighting over the same, single session.
If no one is currently using "that one session", you will see the full
Novell login dialog. Both at the physical console/workstation itself,
and in any Remote Desktop terminal clients you start. You can login
to both NDS and Windows either from the physical console or a
terminal, and start using the Windows session.
As soon as someone is logged in and is using the session (has
applications running, or is just sitting at the desktop), all
terminals or consoles except where the session is being used now
effectively show an "unlock workstation" dialog.
You do not have the ability to "start another session" like you do on
terminal server; same as unlocking the workstation, if you start or
try to take back a Remote Desktop session, you either have to provide
the credentials of the user currently using the session in order to
"unlock it" and bring the session to your terminal/console, or you can
provide an administrator's credentials to force the existing user to
logoff of the existing session (shutting down their applications,
etc., in the process).
So even if the full Novell login dialog was presented in the terminal
session, or at the physical console, nothing will ever be done with
the NDS credentials provided. Either you'll unlock the existing
session (which is already logged into NDS and doesn't need your
re-entry of the NDS credentials), or you'll force the existing session
to logout (which doesn't require or use your NDS credentials, because
ultimately the machine simply goes to a logged-out state; not a
"logged as you" state when forcing an administrative logoff).
That might not have been useful information, but I'm not sure exactly
what you're expecting would ever _happen_ differently, regardless of
whether you're seeing the full Novell login dialog or just the
Windows-only dialog presented by 4.91 and later.
"Pavels Ruhmans" <elk...@inbox.lv> wrote:
> Well I understand about what you described but I don't understand why? There
> is no any option for different behaviour. We use Win XP like a terminal
> server and every user which connects to the server uses its own login name.
> And the user also uses the computer as workstation locally.
> I suppose there should be a choice for two different usage of remote
> sessions. For the way of usage you've described - it suites only for the
> single user who connects from different places. I suppose that is all of
> that the user on the console cannot do disconnect of the session. Any other
> users can disconnect its own session and reconnect to it.
Alan Adams
alancru...@drcrumb.com
Pavels Ruhmans
to the same computer from different locations without using console
physically the Novell Logon display shows on. Even if someone already using
the session. If this user logs on to the session - another user is simply
disconnected.
But when someone connects physically to the computer from console then
anyone who connects from different locations sees only Windows Logon screen
for connecting to remote session.
We are using WinConnect Server XP which turns Win XP Prof into Terminal
Server. And before Novell Client 4.91 it worked fine with previous Novell
Client.
How will it behave on Windows 2000 or 2003 Terminal Servers? Will it behave
the same way???
Thank you for your answers
Do you have an ICQ number?
"Alan Adams" <alancru...@drcrumb.com> wrote in message
news:04kvl156qff854056...@4ax.com...
Pavels Ruhmans
the problem also happens with Novell Client 4.90 SP1 when we installing
ZDAgent on that workstation. What can cause such things?
"Alan Adams" <alancru...@drcrumb.com> wrote in message
news:04kvl156qff854056...@4ax.com...
Alan Adams
I think the WinConnect involvement clarifies what you were expecting
to see. I've never used that product before, but my guess would be
there is some kind of interoperability problem between the Novell
Client and WinConnect.
And yes, before the Novell Client actually started working more
appropriately with Remote Desktop, it might have worked better with
WinConnect. :( (Since the Novell Client seemed effectively "unaware"
of Remote Desktop previously, and didn't do anything required to
support it, it may not have been as likely to conflict with what
WinConnect is trying to achieve.)
On an actual terminal server, the Novell Client presents a full Novell
login dialog in each session (both at the console and in terminal
sessions), because each session is completely independent. It's
Windows XP, and its "single user terminal server" capabilities (at
least without WinConnect) that require special handling.
The first stop I myself would be making would be to WinConnect
support, to determine whether applications running on an XP machine
with WinConnect are supposed to see what looks like a Windows Server
2003 machine, or whether it still looks like Windows XP.
If the Windows and terminal service capabilities still detect as
Windows XP even when WinConnect is present, the Novell Client may not
be the only application having unexpected behavior here by the
presence of WinConnect on an otherwise Windows XP machine.
You can certainly also go to Novell support, asking for some way to
turn off the Remote Desktop behavior or somehow force the terminal
services-specific behavior even when terminal services isn't present.
I'm not sure I consider such a change likely, but depending how strong
your need is, it could still be worth asking in case WinConnect can't
make Windows "look like a Windows server".
"Pavels Ruhmans" <elk...@inbox.lv> wrote:
> I understand what you are saying. But I would like to say that If I connect
> to the same computer from different locations without using console
> physically the Novell Logon display shows on. Even if someone already using
> the session. If this user logs on to the session - another user is simply
> disconnected.
> But when someone connects physically to the computer from console then
> anyone who connects from different locations sees only Windows Logon screen
> for connecting to remote session.
> We are using WinConnect Server XP which turns Win XP Prof into Terminal
> Server. And before Novell Client 4.91 it worked fine with previous Novell
> Client.
> How will it behave on Windows 2000 or 2003 Terminal Servers? Will it behave
> the same way???
>
> Thank you for your answers
> Do you have an ICQ number?
Alan Adams
alancru...@drcrumb.com
Matt Riolo
I'm confused by your statement in your 10/26 post "...So even if the
full Novell login dialog was presented in the terminal session, or at
the physical console, nothing will ever be done with the NDS credentials
provided..."
We encourage our users to lock their workstation when they are away, and
to resume your existing session whether at the workstation or via
remote, is critical. Authentication and rights management is the main
function of the client/NDS. NDS administrators (limited) are the only
ones that can force logout once the workstation is locked, so this is
ideal for the average user to be able to connect.
I would simply like to option to force windows auth or force NDS auth
for users attempting to connect to a workstation that has an existing
session open.
Matt
Alan Adams
Yes, its a Remote Desktop-specific statement. For simply "unlocking a
locked workstation", the NDS credentials are indeed used if
specified/selected. They are unfortunately two very different
operations (unlocking the workstation, versus Remote Desktop taking
over an existing console session).
In the case of unlocking the workstation, Windows (WINLOGON.EXE,
specifically) asks the GINA to determine whether the unlock should be
allowed or not allowed (or whether the existing user session should be
forced to logout). So a third-party GINA like Novell's NWGINA.DLL is
free to do that based upon NDS credentials or anything the third-party
GINA deems necessary.
In the case of Remote Desktop taking over an existing session, the way
Windows implements this leaves Windows/WINLOGON.EXE itself to make the
determination of whether the user attempting the operation should be
permitted to "take over" the console session (or force the existing
session to logoff). And when Windows/WINLOGON.EXE makes this
determination, it does so based purely on the Windows account
credentials specified.
A third party GINA isn't inherently able to "pass" or "fail" this
determination due to its own criteria or credentials other than
Windows credentials, as is the case for unlocking the workstation. So
that's why I said "it wouldn't matter if you specified NDS credentials
in the Remote Desktop scenario", because regardless of what NDS
identity you might have specified, Windows/WINLOGON.EXE is making its
decision based on the Windows account information.
Unfortunately most of what it takes for a GINA to support Remote
Desktop is still undocumented, so I can't really point you to a
Microsoft resource that confirms this assertion. Keith Brown's
"Security Briefs" from June 2005 finally came close to putting most of
it on the table, but not so much that the implications for a
third-party GINA using non-Windows credentials are clear.
http://msdn.microsoft.com/msdnmag/issues/05/06/SecurityBriefs/
Matt Riolo <mr!o...@luc.edu> wrote:
Alan Adams