Access Denied: Determining Which Programs Access Files

We need to know when and how authorized users access sensitive files. We audit successful object access, and we audit the sensitive folders for successful reads and writes by Everyone. But the event log doesn't show through which application a user accessed a file or whether the application read or copied the file. How can we get that information?

Your security provides enough information to determine which program accesses a file, but the client/server nature of file sharing reduces the value of the information. When someone accesses a file on your server, Windows 2000 logs event ID 560 (success audit: object open) to the Security log, as Figure 1 shows. Event ID 560 informs you that EXAMPLE\tom opened C:\junk\junk.txt for Read access at 4:22:20 p.m. on June 10. Event ID 560 also identifies the executable that Tom used to open the file and the logon session the access occurred in. You just need to do a little translation.

Note Process ID 1896 in Figure 1. Whenever a user starts an executable, a new process is created. After you enable Audit process tracking, Win2K records event ID 592 (success audit: a new process has been created) whenever a user starts a new process. Event ID 592 in Figure 2 informs you that Tom started notepad.exe shortly before opening junk.txt. Notice that event ID 592 includes a New Process ID. Theoretically, you should be able to link event ID 560 to event ID 592 by process ID and thereby determine which program opened the file. This method works in Windows NT, but because of a bug, Win2K doesn't log the same process ID between event IDs 560 and 592. Event ID 592 logs a 10-digit process ID, but event ID 560 logs a number of no more than 4 digits. Consequently, you can't use a process ID to link event IDs 560 and 592 in Win2K. (Microsoft has fixed this bug in Windows XP—and presumably in Windows .NET Server—Win.NET Server. In XP, event ID 560 includes the executable's Image File Name, as Web Figure 1 shows, so you don't need to track down the corresponding event ID 592.)

You can work around this problem somewhat in Win2K. Whenever a user logs on interactively to a workstation or over the network to a server, Win2K creates a new logon session and assigns it a logon ID. That logon ID appears as the Primary Logon ID in event ID 560 and as Logon ID in event ID 592. The logon ID lets you at least determine which executables the user started (event ID 592) during the logon session specified in an object access event (event ID 560). Each event ID 592 that occurs after a particular event ID 560 and has the same logon ID shows an executable that the user might have used to open that object.

Win2K object auditing and process tracking work well together when Tom accesses a file on his local computer. In that case, Tom's application (e.g., Microsoft Word) opens the file (e.g., memo.doc) directly. However, auditing gets a bit more complicated when Tom starts Word on his local workstation, then uses Word to open a file on a file server. This scenario raises some questions: Where does Win2K record the process tracking and object access events? And what program does Win2K log as opening the file?

If you've enabled Audit process tracking for Success events on Tom's workstation, his workstation records event ID 592. A corresponding event ID 560 is recorded on the server, but that event's process ID won't match the process ID for the event ID 592 that was recorded on Tom's workstation. These process IDs don't match because of the interaction between the Workstation service on Tom's computer and the Server service on the file server. When you open a file on a remote computer, your Workstation service sends that request to the Server service on the remote computer. The Server service opens the file and processes reads and writes on your behalf, so event ID 560 points to the Server service.

Notice that event ID 560 includes the primary and client usernames, domain names, and logon IDs. The Process ID and the various Primary fields identify the user and logon session that actually opened the file. The Client fields indicate the username, domain, and logon ID of the client, if any, on whose behalf the primary user opened the file. When you open a file on your local computer, Win2K fills in only the Primary fields, as Figure 1 shows. When Tom opens a file on the server, Win2K logs event ID 560 and records the Server service's logon information in the Primary fields and Tom's logon information in the Client fields.

On Win2K, determining which application a user used to access a given file on a remote computer is difficult. However, you can compile a list of possible applications by looking at every workstation event ID 592 that the OS logs after logging a given event ID 560 on a server. Of course, you need to know which workstation Tom is logged on to. To find that information, scan workstation Security logs for event ID 528 (logon) or domain controller (DC) Security logs for event ID 680 (successful authentication) and event ID 672 (authentication ticket granted). DCs log event ID 680 whenever someone logs on in the domain through NT LAN Manager (NTLM), which identifies a pre-Win2K computer. In event ID 680, the Workstation field identifies the computer name of the user's workstation. DCs log event ID 672 when someone logs on at a workstation that uses Kerberos; in this event, the Client Address indicates the IP address of the user's workstation.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.