Above this is a thread "NWGINA, DLU only at console. RDP gets MSGINA, no
DLU!" where Alan Adams responded:
> What you've described is indeed the default behavior. Similar to how
> setting up a Windows AutoAdminLogon results in a Windows-only logon
> either with or without the Novell Client installed, pre-supplying
> Windows credentials on a terminal session will by default create a
> Windows-only logon in the terminal session, with or without the Novell
> Client present.
>
> To pre-supply Windows account credentials in the terminal connection
> /and/ have an eDirectory login attempted with those credentials in
> addition to the otherwise Windows-only logon that is going to occur,
> you can establish the Novell-specific "TSClientAutoAdminLogon" policy.
>
> The reason the original poster here would have expected credentials
> passed from the terminal client to have performed an eDirectory login
> (and thereby also engaged any applicable DLU policy) is because the
> "TSClientAutoAdminLogon" policy is configured, as confirmed in the
> registry configuration that was posted.
>
> Alan Adams
> Novell Client CPR Group
> alan....@novell.com
> The strange thing is, I tried the TSClientAutoAdminLogon setting and
> it's not working for me.
>
> I have the following set up:
>
> HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Login
> TSClientAutoAdminLogon = 1
> DefaultLoginProfile = Default
>
> Now, when I log on from computers running Windows XP/2003 using the
> older RDp client v5, it opens the remote desktop to a Novell login
> screen. So that's working.
>
> But when I log on using the RDP client v6 on Vista/Win7, it brings up
> the credentials pop-up prior to actually opening the remote desktop, and
> then proceeds to do a Windows-only login. I was under the impression
> that the TSClientAutoAdminLogon was supposed to deal with this very
> situation, where the credentials sent by the RDP client would be used to
> attempt a Novell login. But in my case, it's not doing that. It's only
> working for older RDP clients that don't send the credential information
> themselves.
Your expectations are sounding correct on most points, but to put
couple specific confirmations out there:
If you have the Novell Client for Windows Vista/2008 installed on the
terminal server machine, the default login UI expected to be seen in
the terminal session (i.e. when the terminal client did not already
collect or pre-supply a set of Windows credentials, such that you're
presented with interactive logon UI in the terminal session) is the
Novell Client's logon UI.
That part is not contingent on TSClientAutoAdminLogon; seeing the
Novell Client's credential provider in the terminal session, if you're
actually getting an interactive logon UI in the terminal session at
all, is expected to be true whether TSClientAutoAdminLogon is
configured or not.
TSClientAutoAdminLogon is, as you understood, is supposed to be what
interrupts what would have otherwise been an successful Windows-only
logon using Windows credentials pre-supplied from the terminal client.
And will attempt to login to eDirectory with that same username and
password before the Windows account logon, using the eDirectory tree
name and context from the Novell Client login profile named by
"DefaultLoginProfile".
The things that come to mind for "when credentials are pre-supplied
from the terminal client, I still get a Windows-only logon even though
"TSClientAutoAdminLogon" policy is set":
- Make sure your "TSClientAutoAdminLogon" value in the registry is
defined as a REG_SZ string value of "1", as opposed to a DWORD numeric
value of 1. Otherwise the reality is that the
"TSClientAutoAdminLogon" policy is being ignored, which can explain
the outcome described.
- Does this happen to actually be Windows Server 2008 R2? (The NT 6.1
operating system currently in beta at Microsoft, and is the server
version of what's called "Windows 7" as the desktop version.) If so,
there are known issues between the Novell Client 2 for Windows
Vista/2008 and the NT 6.1 platforms ("Windows 7", and "Windows Server
2008 R2") that would cause the eDirectory connections to not "stick"
/if/ you're logging on as an Administrators member Windows user
account.
- Not that I expect this should really be the cause, but try switching
the "Computer Only Logon Default" setting under "Advanced Login" in
the Novell Client Properties to "Never", just to ensure that when the
Novell Client logon UI comes up in the terminal connection, its for
sure coming up in "Novell Logon" mode instead of "Computer Only Logon"
mode.
Alan Adams
Novell Client CPR Group
alan....@novell.com
Novell
Making IT Work As One
www.novell.com
> An update:
>
> When logging into a domain account, the credentials supplied by the RDP
> client are being used to verify the existence of an equivalent
> eDirectory account. If the account exists on the domain, but not in
> eDirectory, then I will be blocked from logging in. Same happens if the
> account exists in eDirectory but is disabled. However, if the account
> exists and is enabled in both the domain and eDirectory, I can get to
> the desktop, but the login script is never run and I don't have any
> permissions to view network resources.
>
> If logging into a local account, and an equivalent account exists in
> eDirectory, the login script is run.
>
> If I set the RDP connection in the Terminal Services Configuration to
> ignore the credentials supplied by the client, when I connect to the
> terminal server, I'm confronted by the Novell login screen. Whether I
> log in to a domain account, or a local account, the script is run and
> I'm properly logged in.
>
> So it looks like TSClientAutoAdminLogon is working in most cases. The
> only issue is with RDP client-supplied credentials when logging in to
> domain accounts--the domain account username/password is checked against
> eDirectory, and if a match exists, I can proceed to the desktop but I am
> not logged in.
Thanks for the additional confirmations; I'm not aware of any known
issue fitting that description; I'll see if I can't independently
duplicate that outcome and ensure it gets reported.