Hello, I have some questions related to authentication when trying to access network shares on domain computers when logged on as a local administrator. Our IT staff will log onto domain computers using the computer's local administrator account for troubleshooting. If they decide they need to access a network share on a domain server to retrieve some files, they will type in \\servername\sharename and will be prompted after a second or two with an authentication dialog box requesting their username and password. At this point, if I look at the Security Event log on the server they are trying to connect to, I see the following two events getting logged between 8-15 times: Event Type: Failure Audit Event Source: Security Event Category: Account Logon Event ID: 680 Date: 8/6/2010 Time: 9:18:41 AM User: NT AUTHORITY\SYSTEM Computer: SERVERNAME Description: Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Logon account: Administrator Source Workstation: WORKSTATION-NAME Error Code: 0xC0000064 Event Type: Failure Audit Event Source: Security Event Category: Logon/Logoff Event ID: 529 Date: 8/6/2010 Time: 9:18:41 AM User: NT AUTHORITY\SYSTEM Computer: SERVERNAME Description: Logon Failure: Reason: Unknown user name or bad password User Name: Administrator Domain: WORKSTATION-NAME Logon Type: 3 Logon Process: NtLmSsp Authentication Package: NTLM Workstation Name: WORKSTATION-NAME Caller User Name: - Caller Domain: - Caller Logon ID: - Caller Process ID: - Transited Services: - Source Network Address: WORKSTATION-IP Source Port: 0 So here are my questions: 1) Is this behavior normal? 2) Why does the server try to authenticate the local account so many times before it finally prompts for different credentials? 3) Can you reduce the number of times the authentication tries to take place before prompting for different credentials? Thanks.

1- This behavior is normal. 2- See this link, it is about the SYSTEM account: http://support.microsoft.com/kb/120929 It will explain to you why the server try to authenticate the local account so many times before it finally prompts for different credentials (It is about the SYSTEM account which is user account used in your case) 3- You can not reduce the number of times the authentication tries to take place before prompting for different credentials

1- This behavior is normal. 2- See this link, it is about the SYSTEM account: http://support.microsoft.com/kb/120929 It will explain to you why the server try to authenticate the local account so many times before it finally prompts for different credentials (It is about the SYSTEM account which is user account used in your case) 3- You can not reduce the number of times the authentication tries to take place before prompting for different credentials Thank you. I went to the link you provided, which provides a description of what the System account is. However, I guess I'm not sure what the System account has to do with the issue. Can you clarify?

The system account use its privileges to launch programs,utilities and services. It is for that it often try to logon when it needs its privileges and logon failure sometimes happen and this is perfectly normal. In your case system account privileges may be needed to allow you to access your shared folder. Without it you will be unable to access it.

Seems like I just answered similar question in http://stackoverflow.com/questions/2638862/security-warning-when-opening-file-from-network-share

I would appreciate some clarification as I feel I'm still not clear on the answer. 1) Is it normal for the event log entries I listed above to occur EVERY time I connect to a network share on a domain server using a local account (such as the local administrator)? Again, these entries above occur regardless of which server and network share I connect to or which machine I'm connecting from. 2) Why does the authentication fail so many times before I'm finally prompted for different credentials?

1- It is normal for event log entries you listed above to occur every time you connect to a network share on a domain using a local account. In fact, there is some services and utilities that are launched in the background that needs the SYSTEM account administrative permissions. 2- I don't know the real reasons for authentication failure but I think it is a problem of password synchronization. Don't worry, the SYSTEM will finish by authenticating itself.

Hey folks, So the behavior that you see here is going to depend a lot on your client OS version as well as the application you are using to connect to a network resource. However, what's happening is that Windows is essentially trying to be helpful. In general, when you enter a path such as \\servername\sharename in Windows Explorer, Explorer will connect to the resource and attempt to negotiate an authentication method to use. In the case of a file share, we also negotiate SMB dialect and some other things as well at this stage. Once that negotiation is completed, the server will respond with an NTLM challenge. Explorer will respond to that challenge with the credentials of the logged on user. Obviously the server doesn't know about that user, because it's a local account, so that will fail. Depending on what else is loaded on the workstation, such as additional software or shell extensions, the authentication may be retried automatically 3-5 times on behalf of the user before you ever get an authentication prompt on the screen. In addition to this, depending on the auditing you have configured on the server (and the OS version of the server), you may log multiple authentication events for the same transaction as well. All of this combined will result in the large number of events in your audit logs. In your scenario where your technicians need to log in to user workstations to perform maintenance or carry out tasks, it's generally better to give them a dedicated account (that has been granted administrator access) for troubleshooting purposes. This helps you to identify which audit events are associated with the IT staff, and which ones might be related to an unauthorized access attempt, which is the real reason that you're usually doing auditing to begin with. As I mentioned above, the behavior is dependant on OS version, auditing/security settings, and installed software on the workstations. It's not an exhaustive list, but here's some things you can take a look at that might help: The Security Monitoring and Attack Detection Planning Guide http://www.microsoft.com/technet/security/topics/auditingandmonitoring/securitymonitoring/default.mspx Auditing Security Best Practices http://technet.microsoft.com/en-us/library/cc778162.aspx Windows 2000 Audit Categories and Events Reference http://www.microsoft.com/technet/security/prodtech/windows2000/w2kccscg/w2kscgcb.mspx Windows Security Logging and Other Esoterica - Windows Security Team blog http://blogs.msdn.com/ericfitz/ Monitoring logon and logoff events in Windows 2000 http://www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/monitor/logonoff.mspx 300958 How To Monitor for Unauthorized User Access in Windows 2000 http://support.microsoft.com/default.aspx?scid=kb;EN-US;300958 325898 How to set up and manage operation-based auditing for Windows Server 2003, Enterprise Edition http://support.microsoft.com/default.aspx?scid=kb;EN-US;325898 814595 HOW TO: Audit Active Directory Objects in Windows Server 2003 http://support.microsoft.com/default.aspx?scid=kb;EN-US;814595 That's just a partial list - we have a ton of resources out there. Also if you want to see more about Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2, you can check out the auditing category on the AskDS blog, located here: http://blogs.technet.com/b/askds/archive/tags/audit/ David Beach - Microsoft Online Community Support

Yhis is funny what we are discussing here without knowing Windows version, edition and other details. The behavior exactly coincides, for ex., with http://www.windowsitpro.com/article/tips/q-you-receive-access-denied-or-no-network-provider-accepted-the-given-network-path-on-windows-server-2003-sp1-service-pack-1-when-you-attempt-to-access-the-server-locally-using-servername-sharename-.aspx Update1: Here is Microsoft article http://support.microsoft.com/kb/896861 (You receive error 401.1 when you browse a Web site that uses Integrated Authentication and is hosted on IIS 5.1 or a later version) The title is misleading since it applies to accessing UNC shares also

Thanks a lot for all the helpful information and links. At least in our environment, it doesn't seem to matter what OS the client or server is running, the behavior is the same. The event log entries are slightly different depending on the server OS (2003 vs. 2008 R2), but in the end multiple failed authentication events are logged and the client is eventually asked for different credentials. The primary reason I started this thread was because we recently purchased a NetApp NAS that we are using for file storage for our users. CIFS is enabled on the NAS. When users access the NAS using a local account, it takes the NAS 30-90 seconds for it to finally prompt for different credentials, whereas our Windows servers take about 1-5 seconds. NetApp technical support is telling me the problem/issue is not with their NAS and to open a ticket with Microsoft to find out "why your clients keep retrying the same credentials even though they are being denied".

What I'd recommend for troubleshooting that problem is to get a network capture showing the issue occurring against the NetApp filer, and compare that to a network capture taken when accessing a share on a Windows server. The client doesn't know the difference, so it should follow the same process against both targets. However the process is a two-way conversation. So, if there's a delay on the netapp filer in replying to the client's requests, that could in turn produce the delay that you see on your clients. It's also possible that there could be some other issue going on when you connect with the netapp filer, like an SMB dialect problem, that may be slowing the transaction down as well. One thing you should make sure is that you have the latest firmware from NetApp on your device - here in (Microsoft) support, we routinely talk to customers who have problems with third-party storage devices, only to find that a firmware update from the device vendor has corrected the issue.David Beach - Microsoft Online Community Support