Using Local Accounts to Access Network Resources on Domain Computers
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.
August 6th, 2010 7:30pm
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
Free Windows Admin Tool Kit Click here and download it now
August 6th, 2010 8:00pm
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?
August 6th, 2010 9:48pm
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.
Free Windows Admin Tool Kit Click here and download it now
August 6th, 2010 11:17pm
Seems like I just answered similar question in
http://stackoverflow.com/questions/2638862/security-warning-when-opening-file-from-network-share
August 8th, 2010 9:57pm
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?
Free Windows Admin Tool Kit Click here and download it now
August 11th, 2010 6:20pm
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.
August 11th, 2010 6:29pm
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
Free Windows Admin Tool Kit Click here and download it now
August 12th, 2010 11:47pm
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
August 13th, 2010 2:50pm
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".
Free Windows Admin Tool Kit Click here and download it now
August 13th, 2010 9:44pm
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
August 13th, 2010 11:28pm