Anonymous_User Absent Member.
Absent Member.
2060 views

Windows 10 Lockscreen user prompt

Hi everyone,

I have a single Windows 10 workstation that is behaving oddly
after installing the creators update.

All our workstations are set up to autologon a generic windows
user in the background. On the Windows lock screen (not the
initial login!) this single workstation prompts for the windows
user instead of prompting for the Novell/OES password of the
logged in Novell user.
To unlock the workstation it is necessary to click the icon
for the logged in Novell user.
This is annoying to the user as this is a workstation that handles
management information and hence is set to automatically lock
after a few minutes.

Resetting the autologon via autolog.exe and userpasswords2 has not
helped, nor has uninstalling and reinstalling the OES-Client.

This behavior started after Windows 10 Creators Update (Version 1703)
was installed on the Workstation. All other Workstations do not
Display the Windows user on the unlock screen at all, only the
current Novell user and the "other" option for different Novell
credentials.

Client Information:
Client for Open Enterprise Server 2 SP4 (IR6)
Prompt for Network login -> On
File Caching -> Off
File-Commit -> On

Autologon: E-Dir promt, autologon to Workstation.

Network Connection Provider Order -> Netware Services at the top
of the list.

I've also checked the Registry Keys in HKLM\Software\Novell\Login
to match the workstations behaving normally.

The Workstation was upgraded from Windows 7 to Windows 10. However
other workstations with identical configuration do not show this
behavior.

Thanks for any insight,
Mike.



---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

Labels (1)
0 Likes
8 Replies
Knowledge Partner
Knowledge Partner

Re: Windows 10 Lockscreen user prompt

Michael Mehnert;2466003 wrote:
Hi everyone,

I have a single Windows 10 workstation that is behaving oddly
after installing the creators update.

All our workstations are set up to autologon a generic windows
user in the background. On the Windows lock screen (not the
initial login!) this single workstation prompts for the windows
user instead of prompting for the Novell/OES password of the
logged in Novell user.
To unlock the workstation it is necessary to click the icon
for the logged in Novell user.
This is annoying to the user as this is a workstation that handles
management information and hence is set to automatically lock
after a few minutes.

Resetting the autologon via autolog.exe and userpasswords2 has not
helped, nor has uninstalling and reinstalling the OES-Client.

This behavior started after Windows 10 Creators Update (Version 1703)
was installed on the Workstation. All other Workstations do not
Display the Windows user on the unlock screen at all, only the
current Novell user and the "other" option for different Novell
credentials.

Client Information:
Client for Open Enterprise Server 2 SP4 (IR6)
Prompt for Network login -> On
File Caching -> Off
File-Commit -> On

Autologon: E-Dir promt, autologon to Workstation.

Network Connection Provider Order -> Netware Services at the top
of the list.

I've also checked the Registry Keys in HKLM\Software\Novell\Login
to match the workstations behaving normally.

The Workstation was upgraded from Windows 7 to Windows 10. However
other workstations with identical configuration do not show this
behavior.

Thanks for any insight,
Mike.



---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


Take a look at a couple threads back: https://forums.novell.com/showthread.php/503236-Windows-10-1703-%28-Creators-Update-RS2-%29-upgrade
Maybe that is what you are seeing...

Thomas
0 Likes
Micro Focus Contributor
Micro Focus Contributor

Re: Windows 10 Lockscreen user prompt

Michael Mehnert <michael.mehnert@bbsm-brandenburg.de> wrote:

> All our workstations are set up to autologon a generic windows
> user in the background. On the Windows lock screen (not the
> initial login!) this single workstation prompts for the windows
> user instead of prompting for the Novell/OES password of the
> logged in Novell user.


I'm not already aware of any Windows 10 1703 / Creators Update
specific behavior that would cause that, although I wouldn't rule that
possibility out.

In addition to the Windows AutoAdminLogon, what else is happening in
order to get logged into eDirectory as well? e.g. Do you also have
eDirectory AutoAdminLogon enabled, such that by the time the
workstation reaches the Windows user's desktop, they're already logged
into both eDirectory and Windows?

Or does the workstation use "Prompt for eDirectory login during
Windows AutoAdminLogon", such that the otherwise immediate Windows
AutoAdminLogon processing is interrupted to prompt for unique
eDirectory credentials prior to allowing the Windows AutoAdminLogon to
proceed?

Or is the user simply logging to eDirectory "manually" from the
desktop after an otherwise Windows-only AutoAdminLogon, and then later
locking the workstation? (i.e. They did originally login with only
Windows credentials, and then may or may not have authenticated to
eDirectory by the time the workstation lock is invoked. But when they
do happen to be logged into eDirectory from the user's desktop, they
are expecting eDirectory credentials are required for unlock.)

Alan Adams
Client for Open Enterprise Server
Micro Focus
alan.adams@microfocus.com
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Windows 10 Lockscreen user prompt

Am 14.09.2017 um 15:18 schrieb Alan Adams:
> Or does the workstation use "Prompt for eDirectory login during
> Windows AutoAdminLogon", such that the otherwise immediate Windows
> AutoAdminLogon processing is interrupted to prompt for unique
> eDirectory credentials prior to allowing the Windows AutoAdminLogon to
> proceed?


Yes, this is how all our workstations are set up.

The User is Prompted for his eDirectory login as usual. Windows
then does an AutoAdminLogon with the local Windows user.
This is all as expected.

The only problem is the Windows Lock screen. Both the Windows user
and the eDirectory user remain logged in when the workstation is
locked.
However, unlike all other workstations, this one prompts for the
Windows user when you try to unlock the workstation. This is also
the only workstation that shows the icon for the windows user
on the unlock screen at all.

There are no obvious differences in configuration from the other
workstations and the behavior only started after the creators update
was applied.

I don't really want to reinstall it from scratch over such a
minor issue.

- Michael

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

0 Likes
Micro Focus Contributor
Micro Focus Contributor

Re: Windows 10 Lockscreen user prompt

Michael Mehnert <michael.mehnert@bbsm-brandenburg.de> wrote:

> Am 14.09.2017 um 15:18 schrieb Alan Adams:
> > Or does the workstation use "Prompt for eDirectory login during
> > Windows AutoAdminLogon", such that the otherwise immediate Windows
> > AutoAdminLogon processing is interrupted to prompt for unique
> > eDirectory credentials prior to allowing the Windows AutoAdminLogon to
> > proceed?

>
> Yes, this is how all our workstations are set up.
>
> However, unlike all other workstations, this one prompts for the
> Windows user when you try to unlock the workstation. This is also
> the only workstation that shows the icon for the windows user
> on the unlock screen at all.
>
> There are no obvious differences in configuration from the other
> workstations and the behavior only started after the creators update
> was applied.


We hadn't already seen any fundamental issue on the unlock, in an
AutoAdminLogon and "Prompt for network login during Windows
AutoAdminLogon" configuration, but I double checked just to make sure
I couldn't demonstrate any fundamental issue on Windows 10 1703.

Since it survived an uninstall and re-install of the Client for Open
Enterprise Server (which should have addressed any of things we /have/
seen go wrong during a Windows 10 1703 upgrade), the next most logical
suspicion in my mind is that "an extra credential appears on the
workstation unlock screen" is either some other third-party credential
provider that exists on that one machine, or maybe even one of the
Microsoft in-box credential providers that has found its criteria for
displaying a credential to be met.

For example, the Microsoft Smart Card credential provider can cause
such a credential to appear, as described in TID 7018433.
https://www.novell.com/support/kb/doc.php?id=7018433

It's technically possible this Windows credential is coming from the
Microsoft Password-based credential provider. Client for Open
Enterprise Server normally filters out the Microsoft Password
credential provider, so that the credential provider experience is
more "like a Domain-joined workstation" rather than showing
credentials for all the local workstation accounts, etc.

But if some third-party credential provider is present which /wraps/
the Microsoft in-box Password credential provider, although we're
attempting to filter out the GUID of Microsoft's credential provider,
it's actually the third-party credential provider that is presenting
(via wrapping) the Microsoft credential provider behavior.

If the machine were in front of me, I'd take a look at the credential
providers I see registered under
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential
Providers] as compared to one of the other machines where the issue
doesn't occur. Such that if one or more unique third-party credential
providers is present on that machine, you could see if removing that
specific product (or at least adding it's GUID to the "FilterList"
value, similar to what's described in TID 7018433) eliminates the
symptom.

If nothing like that stood out, my next approach would be to add the
Microsoft in-box credential providers you see registered there one by
one to the FilterList, to determine if filtering out one of the
Microsoft credential providers we're not already filtering out affects
this symptom.

Alan Adams
Client for Open Enterprise Server
Micro Focus
alan.adams@microfocus.com
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Windows 10 Lockscreen user prompt

I would challenge the premise that the client "survived" the creator update.
My experience so far has been that it is broken on every single forced
upgrade. I am currently experiencing this on all of my 1501 systems that
have reached the end of their CBB . We had about 600 of these left this
summer that we could not get to re image. Our experience, I can assure you
that the client breaks every single time. It was not a simple wipe of the
settings as first reported in the TID. For us you can't touch the tree,
context, advanced or try to login without an error. try reinstalling the
client and see what happens. that’s the only fix we have found in our
environment. Or techs log in local with an admin account and reinstall.

"Alan Adams" wrote in message
news:0cpvrcd2l3085g5dkd7q01jiet71c7i0sn@4ax.com...

Michael Mehnert <michael.mehnert@bbsm-brandenburg.de> wrote:

> Am 14.09.2017 um 15:18 schrieb Alan Adams:
> > Or does the workstation use "Prompt for eDirectory login during
> > Windows AutoAdminLogon", such that the otherwise immediate Windows
> > AutoAdminLogon processing is interrupted to prompt for unique
> > eDirectory credentials prior to allowing the Windows AutoAdminLogon to
> > proceed?

>
> Yes, this is how all our workstations are set up.
>
> However, unlike all other workstations, this one prompts for the
> Windows user when you try to unlock the workstation. This is also
> the only workstation that shows the icon for the windows user
> on the unlock screen at all.
>
> There are no obvious differences in configuration from the other
> workstations and the behavior only started after the creators update
> was applied.


We hadn't already seen any fundamental issue on the unlock, in an
AutoAdminLogon and "Prompt for network login during Windows
AutoAdminLogon" configuration, but I double checked just to make sure
I couldn't demonstrate any fundamental issue on Windows 10 1703.

Since it survived an uninstall and re-install of the Client for Open
Enterprise Server (which should have addressed any of things we /have/
seen go wrong during a Windows 10 1703 upgrade), the next most logical
suspicion in my mind is that "an extra credential appears on the
workstation unlock screen" is either some other third-party credential
provider that exists on that one machine, or maybe even one of the
Microsoft in-box credential providers that has found its criteria for
displaying a credential to be met.

For example, the Microsoft Smart Card credential provider can cause
such a credential to appear, as described in TID 7018433.
https://www.novell.com/support/kb/doc.php?id=7018433

It's technically possible this Windows credential is coming from the
Microsoft Password-based credential provider. Client for Open
Enterprise Server normally filters out the Microsoft Password
credential provider, so that the credential provider experience is
more "like a Domain-joined workstation" rather than showing
credentials for all the local workstation accounts, etc.

But if some third-party credential provider is present which /wraps/
the Microsoft in-box Password credential provider, although we're
attempting to filter out the GUID of Microsoft's credential provider,
it's actually the third-party credential provider that is presenting
(via wrapping) the Microsoft credential provider behavior.

If the machine were in front of me, I'd take a look at the credential
providers I see registered under
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential
Providers] as compared to one of the other machines where the issue
doesn't occur. Such that if one or more unique third-party credential
providers is present on that machine, you could see if removing that
specific product (or at least adding it's GUID to the "FilterList"
value, similar to what's described in TID 7018433) eliminates the
symptom.

If nothing like that stood out, my next approach would be to add the
Microsoft in-box credential providers you see registered there one by
one to the FilterList, to determine if filtering out one of the
Microsoft credential providers we're not already filtering out affects
this symptom.

Alan Adams
Client for Open Enterprise Server
Micro Focus
alan.adams@microfocus.com

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Windows 10 Lockscreen user prompt

Alan,

thank you for your insight.

I have compared the registry of the affected machine to a "normal" one
There was one additional credential provider which I have deleted from
the registry. This did not change the systems behavior (tested after
a reboot of course).

Checking the Novell/OES client registry keys against the unaffected
machine, I also added
[HKLM\SOFTWARE\Novell\Login] -> "Simple Unlock"=0x1
to the erratic machines registry.

Your suggestion made me check the rest of the Authentication structure
in the registry as well and the only notable differences I could find
are in the
[HKLM\SOFTWARE\Microsoft\CurrentVersion\Authentication\LogonUI\SessionData\1]
key. Here the value nccredprovider reads "unlock" on the affected
machine instead of "logon" as on all the others.
This looks like the obvious reflection for the behaviour I'm seeing.
Unfortunately this key only seems to be a read-only readout the
settings of the current user session (changing the value has no
noticeable effect and is reverted upon the next login.)
I could not find any obvious place in the registry that actually
provides this value for each users session.

- Mike.

Am 18.09.2017 um 17:45 schrieb Alan Adams:
> Michael Mehnert <michael.mehnert@bbsm-brandenburg.de> wrote:
>
>> Am 14.09.2017 um 15:18 schrieb Alan Adams:
>>> Or does the workstation use "Prompt for eDirectory login during
>>> Windows AutoAdminLogon", such that the otherwise immediate Windows
>>> AutoAdminLogon processing is interrupted to prompt for unique
>>> eDirectory credentials prior to allowing the Windows AutoAdminLogon to
>>> proceed?

>>
>> Yes, this is how all our workstations are set up.
>>
>> However, unlike all other workstations, this one prompts for the
>> Windows user when you try to unlock the workstation. This is also
>> the only workstation that shows the icon for the windows user
>> on the unlock screen at all.
>>
>> There are no obvious differences in configuration from the other
>> workstations and the behavior only started after the creators update
>> was applied.

>
> We hadn't already seen any fundamental issue on the unlock, in an
> AutoAdminLogon and "Prompt for network login during Windows
> AutoAdminLogon" configuration, but I double checked just to make sure
> I couldn't demonstrate any fundamental issue on Windows 10 1703.
>
> Since it survived an uninstall and re-install of the Client for Open
> Enterprise Server (which should have addressed any of things we /have/
> seen go wrong during a Windows 10 1703 upgrade), the next most logical
> suspicion in my mind is that "an extra credential appears on the
> workstation unlock screen" is either some other third-party credential
> provider that exists on that one machine, or maybe even one of the
> Microsoft in-box credential providers that has found its criteria for
> displaying a credential to be met.
>
> For example, the Microsoft Smart Card credential provider can cause
> such a credential to appear, as described in TID 7018433.
> https://www.novell.com/support/kb/doc.php?id=7018433
>
> It's technically possible this Windows credential is coming from the
> Microsoft Password-based credential provider. Client for Open
> Enterprise Server normally filters out the Microsoft Password
> credential provider, so that the credential provider experience is
> more "like a Domain-joined workstation" rather than showing
> credentials for all the local workstation accounts, etc.
>
> But if some third-party credential provider is present which /wraps/
> the Microsoft in-box Password credential provider, although we're
> attempting to filter out the GUID of Microsoft's credential provider,
> it's actually the third-party credential provider that is presenting
> (via wrapping) the Microsoft credential provider behavior.
>
> If the machine were in front of me, I'd take a look at the credential
> providers I see registered under
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential
> Providers] as compared to one of the other machines where the issue
> doesn't occur. Such that if one or more unique third-party credential
> providers is present on that machine, you could see if removing that
> specific product (or at least adding it's GUID to the "FilterList"
> value, similar to what's described in TID 7018433) eliminates the
> symptom.
>
> If nothing like that stood out, my next approach would be to add the
> Microsoft in-box credential providers you see registered there one by
> one to the FilterList, to determine if filtering out one of the
> Microsoft credential providers we're not already filtering out affects
> this symptom.
>
> Alan Adams
> Client for Open Enterprise Server
> Micro Focus
> alan.adams@microfocus.com
>



---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

0 Likes
Micro Focus Contributor
Micro Focus Contributor

Re: Windows 10 Lockscreen user prompt

Michael Mehnert <michael.mehnert@bbsm-brandenburg.de> wrote:

> Checking the Novell/OES client registry keys against the unaffected
> machine, I also added
> [HKLM\SOFTWARE\Novell\Login] -> "Simple Unlock"=0x1
> to the erratic machines registry.


Thanks. Adding that to the Windows 10 1703 + AutoAdminLogon + Prompt
for network login during Windows AutoAdminLogon configuration I was
testing, but still haven't gotten an additional Windows-only
credential to show up on the unlock screen.

> ..the only notable differences I could find are in the
> [HKLM\SOFTWARE\Microsoft\CurrentVersion\Authentication\LogonUI\SessionData\1]
> key. Here the value nccredprovider reads "unlock" on the affected
> machine instead of "logon" as on all the others.


Is it possible that the observation was actually "the reverse" of
that? "unlock" is what I would expect to be written there on the
machines that you've successfully performed the unlock via
NCCredProvider without issue.

Seeing "logon" still there is what "makes sense" for a scenario where
I've successfully logged on to eDirectory and Windows, but when I went
to unlock there is some other Windows-only credential being presented
for unlocking the machine, and NCCredProvider isn't getting the chance
to handle the unlock for you.

You're right that this is effectively "read only", in the sense that
NCCredProvider writes that data such that NCNetProvider's
NPLogonNotify callback from the Windows Credential Manager interface
can know what type of situation NCCredProvider has been called to
handle. (Normal "logon", or "workstationonly" or "unlock".)

When this value hasn't been set to anything, this is the signal to
NPLogonNotify that we might be in a scenario where "Login with
Third-Party Credential Provider" might need to be employed, if
enabled, since NCCredProvider apparently wasn't already in control of
the credential provider-based login experience. It doesn't really
"serve any purpose" in an unlock scenario, since Windows doesn't
invoke a new NPLogonNotify in those scenarios, but we still write that
flag when NCCredProvider handles the workstation unlock nonetheless.


I think the next step is to determine whether the NCCredProvider debug
log shows any additional hits as to what might be going on. It can't
directly show us "some other credential provider's credential is being
shown", because it's a debug of NCCredProvider's behavior. If
Microsoft's LoginUI is interacting with some other credential besides
ours, the debug evidence of that would come from "whomever that other
credential provider is", which we can't really predict at this point.

Create a DWORD32 value named "Debug" set to 0x3 under the
[HKEY_LOCAL_MACHINE\Software\Novell\Authentication\NCCredProvider]
key. The debug logs themselves will be generated into
"C:\ProgramData\Novell\Client\Log". There is one per terminal session
(-0001, -0002, etc.) so be sure to collect them all, since activity on
some other session may in fact be involved.

Collecting the same from both a success case workstation and a failure
case workstation might have the best chance of showing clues. If you
have any issue or concern with attaching them here, please feel free
to attach and send them via email instead. I'll prefer to keep the
discussion public so that everyone benefits, but sending the logs via
email is fine.

Alan Adams
Client for Open Enterprise Server
Micro Focus
alan.adams@microfocus.com
0 Likes
Micro Focus Contributor
Micro Focus Contributor

Re: Windows 10 Lockscreen user prompt

"John Anvari" <net.man2@outlook.com> wrote:

> I would challenge the premise that the client "survived" the creator update.
> My experience so far has been that it is broken on every single forced
> upgrade. I am currently experiencing this on all of my 1501 systems that
> have reached the end of their CBB .


I don't disagree; I get 100% failure with the upgrade scenario on any
of the lab machines I've tested, too. But that hasn't negated the
fact that multiple customers have also reported "no issue" with
Windows 10 1703 upgrade, even with Client for Open Enterprise Server
present. As though there is still some additional factor that remains
unknown.

Not sure if that's what's happening with Microsoft's investigation of
the issue, too. They've claimed that Windows 10 1703.483 and later
solves the upgrade problem they duplicated, but the results with
testing at our end remain unchanged. Both with .483 and up to the
current .632 being pushed if you select "download updates" during the
Windows 10 upgrade.

But requesting debug code or some logging approach to demonstrate
what's still failing in the upgrade scenario has not produced any
further action out of Microsoft; at least not yet.

Something which does look promising at the moment is that the builds
Microsoft is testing in preparation for the "Fall Creators Update"
(RS3) does not demonstrate this upgrade failure, when trying to
upgrade from RS1 or earlier to RS3. (i.e. If you skipped the March
2017 RS2 update.) But I'd feel a lot better once we know Microsoft
identified the actual root cause of the upgrade failure.

Alan Adams
Client for Open Enterprise Server
Micro Focus
alan.adams@microfocus.com
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.