locked
UAC Consent Elevation Prompt Causing Account Lockouts RRS feed

  • Question

  • Looking for some explainataion here. I've have through local (yes local not domain) group policy configured the allowed bad logon attempts to 3, requiring an administrator to unlock.  But i have noticed that when i trigger the UAC elevation prompt for consent, it triggers a bad logon attempt (evt id 4625) on all user accounts. potentially leading to locking out all acounts if its three times within the period.

    Could someone enlightment me on the interworkings of UAC and why it attempts logons on all accounts? and if i'm lucky, how to make it stop?


    Update: the events don't seem to get created for elevating a cmd prompt with "run as administrator" or opening up the event viewer. They do get created with add/remove user accounts and setup parental controls.
    • Edited by ethosunum Wednesday, June 20, 2012 6:10 PM updated info
    Wednesday, June 20, 2012 5:38 PM

Answers

  • HI,

    Our Dev team has considered this issue to be worthy of getting fixed in windows8 and it has already been filed for windows 8.

    To fix this issue in windows 7 ,  I am not sure whether it will be considered or not for windows 7.  hope you are understanding.


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    • Marked as answer by ethosunum Monday, July 9, 2012 8:32 PM
    Wednesday, July 4, 2012 10:43 AM

All replies

  • Hi ,

    From your description, I know that a bad logon attempt will be triggered once you trigger the UAC elevation prompt for consent.

    Does the issue only occur when you enable this group policy?

    Have you tried to disable UAC?

    Did you enable Account Lockout Threshold policy?

    Generally, UAC will not cause this issue. Please test it on another computer and see the result.  


    Tracy Cai

    TechNet Community Support

    Monday, June 25, 2012 7:29 AM
  • From your description, I know that a bad logon attempt will be triggered once you trigger the UAC elevation prompt for consent.

    Are you confirming that by design, UAC will trigger a bad logon attempt on all accounts when the elevation prompt for consent comes up?

    I'm sure disabling UAC altogether would probably make it this go away, but that is not a solution for me.

    In the following test i did not modify the default UAC settings. I left them to the default of "Prompt for consent for non-windows binaries".

    1) Clean install of Windows 7 Pro into a hyper-v vm.

    2) Created 3 additional users. User, User2,User3,User4.  User and User2 are admins. Gave them all passwords.

    3) Edit Local Group Policy: Enable Auditing Sucess and Failure on all  items in ComputerConfiguration->Windows Settings->Security Settings->Local Policies->Audit Policy

    4) Rebooted

    5) Log in as User.

    6) Open Event Viewer, Windows Logs -> Security. Filter on Event ID 4625

    7) Click on Control Panel -> Add or Remove user accounts

    8) Back in Event Viewer, Refresh. There are now additional audit failure for each account failing to log on, one for each username.

    Now adding in the lockout policies.

    9) Edit Local Group Policy: Enabling the Account Lockout Policies as follows ComputerConfiguration->Windows Settings->Security Settings->Account Policies -> Account Lockout Policy

        Account Lockout Duration: 0  (Requires Administrator)

        Account lockout threshold: 3 invalid attempts

        Reset account lockout counter after: 60 minutes

    10) shutdown/restart

    11) log on as user

    12) open "Computer Management" (to be able to unlock accounts later on)

    13) Open Event Viewer, Windows Logs -> Security. Filter on Event ID 4625

    14) Click on Control Panel -> Add or Remove user accounts

    15) Back in Event Viewer, Refresh. There are now additional audit failure for each account failing to log on, one for each username. (#1)

    16) Close Control Panel -> Manage User acccounts

    17) Click on Control Panel -> Add or Remove user accounts

    18) Back in Event Viewer, Refresh. There are now additional audit failure for each account failing to log on, one for each username.(#2)

    19) Close Control Panel -> Manage User acccounts

    20) Click on Control Panel -> Add or Remove user accounts

    21) Back in Event Viewer, Refresh. There are now additional audit failure for each account failing to log on, one for each username.(#3)

    22) Close Control Panel -> Manage User acccounts

    23) In Computer Management that was opened earlier, navigate to Local Users and Groups -> Users. 

    24) Right click on all Users and examine properties. User, User2, User3, and User4 all have "[X] Account is locked out". The Accounts are all locked out.



    • Edited by ethosunum Monday, June 25, 2012 12:53 PM
    Monday, June 25, 2012 12:43 PM
  • HI ,

    UAC is a new feature for WinVista and latest version OS. In WinVista, When an administrator logs on, the user is granted two access tokens: a full administrator access token and a "filtered" standard user access token. By default, when a member of the local Administrators group logs on, the administrative Windows privileges are disabled and elevated user rights are removed, resulting in the standard user access token

      Understanding and Configuring User Account Control in Windows Vista: http://technet.microsoft.com/en-us/library/cc709628(WS.10).aspx

    Anyway, i will made a test as yours for and will update with you soon .

    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Tuesday, June 26, 2012 11:55 AM
  • HI,

    i cannot reproduce this symptom as yours, so UAC cannot caused such issue as yours. Anyway, please send me the event 4625 for the further troubleshooting.


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Wednesday, June 27, 2012 11:10 AM
  • Jason,

      I am quite surprised that you were not able to reproduce the issue. I followed the steps again and had no problem reproducing it. I followed it a third time recording the hyper-v window and reproduced it a third time.  See the run through at http://www.youtube.com/watch?v=WA1j1Q2JHyM

    as Requested here is the last events that record the lockout

    Keywords Date and Time Source Event ID Task Category
    Audit Failure 6/27/2012 10:33:55 AM Microsoft-Windows-Security-Auditing 4625 Account Lockout "An account failed to log on.

    Subject:
     Security ID:  user-PC\user
     Account Name:  user
     Account Domain:  user-PC
     Logon ID:  0x1d2c4

    Logon Type:   2

    Account For Which Logon Failed:
     Security ID:  NULL SID
     Account Name:  user4
     Account Domain:  

    Failure Information:
     Failure Reason:  Account locked out.
     Status:   0xc0000234
     Sub Status:  0x0

    Process Information:
     Caller Process ID: 0x694
     Caller Process Name: C:\Windows\System32\dllhost.exe

    Network Information:
     Workstation Name: USER-PC
     Source Network Address: -
     Source Port:  -

    Detailed Authentication Information:
     Logon Process:  Advapi 
     Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
     Transited Services: -
     Package Name (NTLM only): -
     Key Length:  0

    This event is generated when a logon request fails. It is generated on the computer where access was attempted.

    The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

    The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

    The Process Information fields indicate which account and process on the system requested the logon.

    The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

    The authentication information fields provide detailed information about this specific logon request.
     - Transited services indicate which intermediate services have participated in this logon request.
     - Package name indicates which sub-protocol was used among the NTLM protocols.
     - Key length indicates the length of the generated session key. This will be 0 if no session key was requested."
    Audit Failure 6/27/2012 10:33:55 AM Microsoft-Windows-Security-Auditing 4625 Account Lockout "An account failed to log on.

    Subject:
     Security ID:  user-PC\user
     Account Name:  user
     Account Domain:  user-PC
     Logon ID:  0x1d2c4

    Logon Type:   2

    Account For Which Logon Failed:
     Security ID:  NULL SID
     Account Name:  user3
     Account Domain:  

    Failure Information:
     Failure Reason:  Account locked out.
     Status:   0xc0000234
     Sub Status:  0x0

    Process Information:
     Caller Process ID: 0x694
     Caller Process Name: C:\Windows\System32\dllhost.exe

    Network Information:
     Workstation Name: USER-PC
     Source Network Address: -
     Source Port:  -

    Detailed Authentication Information:
     Logon Process:  Advapi 
     Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
     Transited Services: -
     Package Name (NTLM only): -
     Key Length:  0

    This event is generated when a logon request fails. It is generated on the computer where access was attempted.

    The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

    The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

    The Process Information fields indicate which account and process on the system requested the logon.

    The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

    The authentication information fields provide detailed information about this specific logon request.
     - Transited services indicate which intermediate services have participated in this logon request.
     - Package name indicates which sub-protocol was used among the NTLM protocols.
     - Key length indicates the length of the generated session key. This will be 0 if no session key was requested."
    Audit Failure 6/27/2012 10:33:55 AM Microsoft-Windows-Security-Auditing 4625 Account Lockout "An account failed to log on.

    Subject:
     Security ID:  user-PC\user
     Account Name:  user
     Account Domain:  user-PC
     Logon ID:  0x1d2c4

    Logon Type:   2

    Account For Which Logon Failed:
     Security ID:  NULL SID
     Account Name:  user2
     Account Domain:  

    Failure Information:
     Failure Reason:  Account locked out.
     Status:   0xc0000234
     Sub Status:  0x0

    Process Information:
     Caller Process ID: 0x694
     Caller Process Name: C:\Windows\System32\dllhost.exe

    Network Information:
     Workstation Name: USER-PC
     Source Network Address: -
     Source Port:  -

    Detailed Authentication Information:
     Logon Process:  Advapi 
     Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
     Transited Services: -
     Package Name (NTLM only): -
     Key Length:  0

    This event is generated when a logon request fails. It is generated on the computer where access was attempted.

    The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

    The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

    The Process Information fields indicate which account and process on the system requested the logon.

    The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

    The authentication information fields provide detailed information about this specific logon request.
     - Transited services indicate which intermediate services have participated in this logon request.
     - Package name indicates which sub-protocol was used among the NTLM protocols.
     - Key length indicates the length of the generated session key. This will be 0 if no session key was requested."
    Audit Failure 6/27/2012 10:33:55 AM Microsoft-Windows-Security-Auditing 4625 Logon "An account failed to log on.

    Subject:
     Security ID:  user-PC\user
     Account Name:  user
     Account Domain:  user-PC
     Logon ID:  0x1d2c4

    Logon Type:   2

    Account For Which Logon Failed:
     Security ID:  NULL SID
     Account Name:  user
     Account Domain:  

    Failure Information:
     Failure Reason:  Unknown user name or bad password.
     Status:   0xc000006d
     Sub Status:  0xc000006a

    Process Information:
     Caller Process ID: 0x694
     Caller Process Name: C:\Windows\System32\dllhost.exe

    Network Information:
     Workstation Name: USER-PC
     Source Network Address: -
     Source Port:  -

    Detailed Authentication Information:
     Logon Process:  Advapi 
     Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
     Transited Services: -
     Package Name (NTLM only): -
     Key Length:  0

    This event is generated when a logon request fails. It is generated on the computer where access was attempted.

    The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

    The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

    The Process Information fields indicate which account and process on the system requested the logon.

    The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

    The authentication information fields provide detailed information about this specific logon request.
     - Transited services indicate which intermediate services have participated in this logon request.
     - Package name indicates which sub-protocol was used among the NTLM protocols.
     - Key length indicates the length of the generated session key. This will be 0 if no session key was requested."


    • Edited by ethosunum Thursday, June 28, 2012 2:18 PM adjusted some grammar
    Wednesday, June 27, 2012 3:13 PM
  • Hi,

    I have reproduced the issue in my lab and it seems an known issue. below is a workaround:

    Open Applet->Click “manage another account”->Choose an account->Click “manage another account”->Choose an account->etc…

    Do not use "back" and don’t click on "Go to main User Account page".


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Tuesday, July 3, 2012 5:37 AM
  • Jason,

      Thank you for acknowledging and taking the time to reproduce the issue. Since you said that is is a known issue, would you be able to point me to a kb article number or some other reference that i could continue to track this issue as well as reference in my own documentation. I don't consider the work around to be an actual solution so i'd like to continue to track the issue. An all accounts lockout should never be the result of a valid and successful UAC elevation.

    Tuesday, July 3, 2012 12:59 PM
  • HI,

    Our Dev team has considered this issue to be worthy of getting fixed in windows8 and it has already been filed for windows 8.

    To fix this issue in windows 7 ,  I am not sure whether it will be considered or not for windows 7.  hope you are understanding.


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    • Marked as answer by ethosunum Monday, July 9, 2012 8:32 PM
    Wednesday, July 4, 2012 10:43 AM
  • Jason,

      Will this issue be listed anywhere in public documentation other than this page as a Known Issue? If so can i get that reference?

    Thursday, July 5, 2012 4:02 PM
  • HI,

    Based on my research, it seems there is no public documentation described this issue. Hope you are understanding! Thanks !


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, July 6, 2012 9:39 AM
  • Hi,

    I have the same issue - all accounts get the 'audit failure event 4625' triggered. And no, "I am not understanding" why there is no public reference nor why "it is not considered for windows 7". Hope you are understanding that I am not understanding.

    Tuesday, August 28, 2012 3:01 PM
  • wow, you honestly cant cut and paste into this forum?

    Anyhow, this is logged elsewhere on server 2008, why doesnt this issue have a KB article?

    Tuesday, December 18, 2012 11:44 AM
  • http://blog.terranspot.com/2012/07/all-accounts-locked-due-to-accessing.html
    Looks like this is also an issue on Server 2008.......any chance of Microsoft issuing a KB article now?



    Just faced with interesting problem few days back. All user accounts on our Windows Server 2008 Standard Edition suddenly locked. After browsing through the Event Viewer Security logs, we noticed multiple Audit Failure entry for all user accounts with the following details:
    - Event ID : 4625
    - Caller Process Name : dllhost.exe
    - Happened within the same seconds for all users
    Tuesday, December 18, 2012 11:50 AM
  • wow, you honestly cant cut and paste into this forum?

    Anyhow, this is logged elsewhere on server 2008, why doesnt this issue have a KB article?

    I wish it was, especially since when i asked about it first they said they couldn't reproduce it. Then it was reproduced but a "known" issue. And that really peeved me as i had been searching for months for the cause and finally tracked it down to that. It was way too much work for a 'known issue'
    • Proposed as answer by chambo1 Tuesday, August 20, 2013 5:17 PM
    • Unproposed as answer by chambo1 Tuesday, August 20, 2013 5:17 PM
    Wednesday, December 19, 2012 1:39 AM
  • I just came across similar issues on Windows 7 Enterprise.  Initially it seemed to manifest itself as locking all accounts when any user logged in successfully 3 times in a row.   This was a real puzzler.  The previous administrator had been using both UAC and Parental Controls for security reasons, but I was not familiar with the specific configuration.    Account Lockout policies were in use.

    In my case I came to discover that when using the Parental Controls interface to query settings for the accounts listed - the sheer act of "touching" the user accounts listed would lock all the accounts on the system.  I presume now that Parental Controls uses a backdoor to User Account Manager  since the results are similar to that described here and in the cited 2008 Server article.


    Interestingly enough setting the Parental Controls Service to start automatically and rebooting caused everything to behave appropriately in my case -  strange.

    Maybe it is related, certainly the symptoms are similar enough.

    • Edited by chambo1 Tuesday, August 20, 2013 5:59 PM
    Tuesday, August 20, 2013 5:36 PM
  • Any public documentation about this issue yet?
    Thursday, October 12, 2017 6:45 AM