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

  • 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-(-Creators-Update-RS2-)-upgrade
    Maybe that is what you are seeing...

    Thomas
  • 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
  • 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

  • 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
  • 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â€Tms 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

  • 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

  • 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
  • "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