Today, I had the lovely experience in trying to troubleshoot why a users account was locking out of the domain every 30 seconds. Inside of event viewer, I could see the account failing to login, but I had the most generic, useless, log to help track down what was going on.

Authentication Package: Always 'MICROSOFTAUTHENTICATIONPACKAGEV10' Logon Account: name of the account Source Workstation: computer name where logon attempt originated. Free Security Log Resources by Randy. Free Security Log Quick Reference Chart; Windows Event Collection: Supercharger Free Edtion; Free Active Directory Change Auditing Solution. In Event Viewer the 4624 events are showing Authentication Package: MICROSOFTAUTHENTICATIONPACKAGEV10 What authentication is being used. It is not Kerberos, I believe. Good day dears, This case was asked from vendors' support teams twice, with no adequate outcomes (no ms or ise related issue;). The last hope is for community. I perform an investigation of the following event from domain controller(##### data has been obfuscated ####): Security4776Microsoft. I'm trying to trackdown the Computer/Device that has a bad password for one of our Domain Admin accounts that gets used as a shared/service account. The only details I have is a recurring event in.

The computer attempted to validate the credentials for an account.

Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account: username
Source Workstation:
Error Code: 0xc000006a

Scrolling through my logs, the only other thing I was was the error code switching from from a 0xc000006a to a 0xc000234. Even though this is beyond the scope of this document, here are what those codes mean:

What Is Microsoft Authentication Package V1 0

0xc000006a – An invalid attempt to login has been made by the following user.

0xc0000234 – The user account has been automatically locked because too many invalid logon attempts or password change attempts have been requested.

Anyways, after scrolling through event viewer on my domain controllers, trying LockoutStatus.exe, and asking the user to power off their mobile devices, workstations, etc, in a desperate act, the error still peristed. Finally I came across the holy grail of Microsoft articles: http://support.microsoft.com/kb/109626/en-us

Solution: We had to put the domain controller in verbose logging for the netlogon service to actually find out where the logon attempt was coming from.

First, open up command prompt as an administrator and execute the following command:

nltest /dbflag:0x2080ffff

Once done, execute the following command to turn off the debugging:

nltest /dbflag:0x0

This logs every transaction made to the file: %windir%debugnetlogon.log (note, you need to run notepad as an administrator to read this file).

Inside of there, find the logon attempt made by the user and it should list the workstation it came from. In this case, the logon attempt was coming from our NPS server, which then was coming from an old laptop he had logged into and left alone for a few months.

Authentication packages are contained in dynamic-link libraries. The Local Security Authority (LSA) loads authentication packages by using configuration information stored in the registry. Loading multiple authentication packages permits the LSA to support multiple logon processes and multiple security protocols.

Logon processes use authentication packages to analyze logon data. New logon processes are added to a system by adding a GINA to collect the required logon data and, if needed, by adding a new authentication package to analyze the data.

Security protocols are implemented by authentication packages. An authentication package analyzes logon data by following the rules and procedures set forth in a security protocol.

Authentication packages are responsible for the following tasks:

• Analyzing logon data to determine whether a security principal is allowed to log on to a system.
• Establishing a new logon session and creating a unique logon identifier for the successfully authenticated principal.
• Passing security information to the LSA for the principal's security token.

When a user attempts an interactive logon, the LSA calls an authentication package to determine whether to permit the user to log on. MSV1_0, for example, is an authentication package installed with the Microsoft Windows operating system. The MSV1_0 package accepts a user name and a hashed password. It looks up the user name and hashed password combination in the Security Accounts Manager (SAM) database. If the logon data matches the stored credentials, the authentication package permits the logon to succeed.

After successfully authenticating a security principal's credentials, an authentication package is responsible for creating a new LSA logon session for the principal and allocating the logon identifier that uniquely identifies the logon session. The authentication package may associate credential information with the logon session for subsequent authentication requests. For example, the MSV1_0 authentication package (provided by Microsoft) associates the user account name and a hash of the user's password with each logon session.

Microsoft_authentication_package_v1_0 Source Workstation Blank

The authentication package also provides a set of security identifiers (SIDs) and other information appropriate for inclusion in the security token created by the LSA. This token will represent the principal's security context for access to Windows operations.

After a logon session is created and associated with a principal, subsequent authentication requests made on behalf of the principal are handled differently than the initial logon. The authentication package does not create a new logon session nor return information for creating a token. The authentication package can, however, associate supplemental credentials obtained during a subsequent authentication with the principal's existing logon session. Supplemental credentials are obtained when access to a requested resource requires information beyond the credentials established by the initial logon. For example, when a logged-on user requests a Novell network logon, a Novell-specific authentication package can be called and Novell-specific credentials can be authenticated and associated with the logon session. These credentials can be referenced by a Novell redirector (by way of the Novell authentication package) when the user accesses the Novell network.

Microsoft_authentication_package_v1_0 Account Lockout

The following topics discuss the various types of Authentication packages: