05- Windows Logging and File Sharing

Windows Logs

Windows 2008 Server
The primary tool for log viewing in Server 2008 is the Event Viewer. To start event viewer, choose either

• Start → Administrative Tools
• Server Manager → Diagnostics → Event Viewer
• Run the command eventvwr.msc

Documentation on Event Viewer is available in Help (Contents: Event Viewer)

To get a handle on the value of the Windows logs, start by determining the number and names of the various Windows logs.

Take a look at the security log; you are likely to see a number of 4624 Logon events as well as a number of 4634 Logoff events. Microsoft has provided a description of the various security events in KB 947226. I will leave it to you to decide how valuable that reference may be.

Rather than work our way through the documentation, let’s see what happens in the domain controller log when we do something relatively common. Select a workstation other than your domain controller(s) and log in to that machine as a domain user. Now let’s go back to the security log and see what we find. (Be sure to refresh your log view!) Find the event that corresponds to your account login; be sure to identify the EventID. You may wish to use the Find entry in the action pane.

Once you have found the log on entry, go ahead and log out of the workstation. Can you find a corresponding logoff entry in the domain controller logs? Are you sure you have the right event? Take a very close look at the time stamps of the logon event and the logoff event, and be sure to compare them to the actual time you logged off. Do you notice anything?

The question of exactly how Windows keeps track of account logons and logon/logoff events is more complex than would appear. Fortunately, Randy Franklin Smith has a nice article available on the EventTracker blog that explains some of these points. Unfortunately, we do not have sufficient class time to delve into these issues in detail.

You may wish to compare the log on and log off process noted above with what occurs when you log on from a Linux machine that you have connected to the domain.

Windows Vista
Even if a system is not a domain controller, it will still contain a set of logs; the primary tool for log viewing is still Event Viewer. In Windows Vista, navigate My Computer (right-click) → Properties → Event Viewer, or simply run eventvwr.msc.

What are the differences between event viewer for Windows Vista and Windows Server 2008?

Windows 7
The primary tool for log viewing is still Event Viewer. Navigate My Computer (right-click) → Properties → Event Viewer, or simply run eventvwr.msc.

What are the differences between event viewer for Windows 7 and Windows Server 2008?

Remote viewing of logs
It is possible to view use event viewer on one computer to view the logs on another windows computer. From Event Viewer, select Action → Connect to Another Computer. Be sure that you have selected Event Viewer (Local) in the navigation pane, or the option to connect to another computer will not appear in the Action menu. Enter the name, and the account details (if different) for the other machine.

In general, this process will fail.

Did you say fail?

What could the problem be?

If you said “Firewall” pat yourself on the back.

To enable these connections, you must adjust the firewall on the remote computer.

In Windows Server 2008, navigate Start → Administrative Tools → Windows Firewall with Advanced Security. Select Inbound Rules. There are three inbound rules for Remote Event Log Management. Enable them. You may wish to configure these rules as well- Right-click, select properties.

In Windows 7, navigate Start → Control Panel → System and Security → Allow a program through windows firewall → Change Settings → Remote Event Log Management. You can specify that this is allowed from other domain members, from computers connecting through a private network (home/work) or through a public network.

In Windows Vista, navigate Start → Control Panel → Allow a program through Windows firewall → UAC → Remote Event Log Management.

Auditing Policies

Windows machines have an auditing policy that is set locally, as well as policies that they can inherit from GPOs, including domain policies as we have already seen.

To find the local auditing policy in Windows Vista / Windows 7 / Server 2008, navigate Control Panel → Administrative Tools → Local Security Policy
→ Security Settings → Local Policies → Audit Policy.

What is the default Local audit policy in Vista? In 7? In Server 2008?

By default, significant auditing policies are set at the domain controller OU level. [Which override the local policies!]

On Windows Server 2008, navigate Start → Administrative Tools → Group Policy Management. What are the default doman level OU group policy settings for auditing?

With Windows Server 2008 and Windows Vista, Microsoft introduced a a new hierarchy for organizing audit policies. Rather than the nine broad categories we have seen so far, we can instead manage policies on a much finer level. Unfortunately, they did not update the GUI tools in these OSes to view these setting. The way to get at these settings is directly from the command line. Indeed, run the command

C:\Windows\system32>auditpol /get /category:*

What? “A required privilege is not held by the client”? Remember that, by default command prompts, even command prompts started by an administrator are not command prompts with administrator privileges. You must right-click on the entry in the start menu, and select “Run as Administrator” and pass through UAC first.

Examine the standard audit policy for your server; repeat the process for a Vista and/or a 7 box. Are the policies the same?

To manage the policies on a box with the command-line tool, start by running

C:\Windows\system32>auditpol /?
Usage: AuditPol command [<sub-command><options>]


Commands (only one command permitted per execution)
  /?               Help (context-sensitive)
  /get             Displays the current audit policy.
  /set             Sets the audit policy.
  /list            Displays selectable policy elements.
  /backup          Saves the audit policy to a file.
  /restore         Restores the audit policy from a file.
  /clear           Clears the audit policy.
  /remove          Removes the per-user audit policy for a user account.
  /resourceSACL    Configure global resource SACLs


Use AuditPol  /? for details on each command

to see the command lne options. See also
http://technet.microsoft.com/en-us/library/cc836528.aspx

If we want to see the policies in the logon/logoff category, we ran run

C:\Windows\system32>auditpol /get /category:Logon/Logoff
System audit policy
Category/Subcategory                      Setting
Logon/Logoff
  Logon                                   Success and Failure
  Logoff                                  Success
  Account Lockout                         Success
  IPsec Main Mode                         No Auditing
  IPsec Quick Mode                        No Auditing
  IPsec Extended Mode                     No Auditing
  Special Logon                           Success
  Other Logon/Logoff Events               No Auditing
  Network Policy Server                   Success and Failure

and if want to see only the logoff subcategory, we run

C:\Windows\system32>auditpol /get /subcategory:logoff
System audit policy
Category/Subcategory                      Setting
Logon/Logoff
  Logoff                                  Success

If we want to change the settings so that we record both successful and failed attempts to logoff, we run

C:\Windows\system32>auditpol /set /subcategory:logoff /failure:enable
The command was successfully executed.

A subsequent check of the policies will show the change:

C:\Windows\system32>auditpol /get /subcategory:logoff
System audit policy
Category/Subcategory                      Setting
Logon/Logoff
  Logoff                                  Success and Failure

Suppose that you want to modify the audit policy on the different machines in your domain. You can’t use Group Policy, as the GUI does not aupport this new audit policy heirarchy.

[Although interestingly, if you set the policies using auditpol and then join a domain, apparently the group policies will overwrite the auditpol created settings- at least according to some of the texts I have read.] There is a way to do this- by first writing a custom script that uses the auditpol tool, then by using a netlogon share you can have computers that log onto the domain run that script, and so set the policies to your preferred values. See http://support.microsoft.com/kb/921469 for the details.

Auditing File Access
Unlike the generic linux logging system, Windows can also generate log entries when particular files are accessed / modified / changed. To illustrate the process, create a file- say on the Desktop named test.txt. Navigate test.txt (right-click) → Properties → Security → Advanced → Auditing → UAC

The window shows the user(s) and the privilege(s) that will be audited. In general you want to be broad here. If you specify that you will only audit file access from the user “Bill”, then if the user “Ted” accesses the file, then no log entry will be generated.

To illustrate, let us audit any attempt to access / modify / delete our file, from anyone. Select the Add button; for the object name, select “Everyone”. For the auditing entry, select Full Control both successful and failed. This means that an audit entry will be generated whenever any of the checked privliges are used by a user- either successfully or not. Apply your changes. Examine the security log- note that there are no entries about your file.

Open your file, modify it, and save the result. Once again examine the security log. Huh? Why are there no entries here- did we do something wrong? Although you set the auditing policy for that file, Windows does not actually pay attention to those settings unless you turn on file level auditing in your audit policy. Run the command

C:\Windows\system32>auditpol /set /subcategory:"file system" /success:enable 
/failure:enable
The command was successfully executed.

Open Your file. Open your security log. [You may need to refresh your view if you still have the log open from above.][Use the F5 key to refresh your view.] At this point, you should see Audit Success entries for the File System related to your auditied file.

Splunk

To install Splunk on a Windows system, select the appropriate installer and launch. Because Splunk runs services, you will be prompted to choose the user that will be used to run those services. If you use a domain member, then your Splunk install can access information about other domain members through Windows methods like WMI. However, last year’s class found that process somewhat problematic. This year, we will use local system users for our installation. This means that we will need to use forwarders to collect data from other Windows hosts in the same fashion that they are necessary to collect data from other Linux hosts.

After installation, proceed to the Splunk Manager web interface as before; be sure to change your license to the Free License. You can do that by navigating through Manager → Licensing &rarr Change License Group. Simply select the Free License, and restart Splunk.

Note also that you may need an updated version of Flash Player, depending on the particular Windows image you are using. They are available on the labshare as well as online.

Once installed, one very valuable data source would be the Windows event logs. Note that, since we installed Splunk as a local user, we will not be able to use WMI to collect Windows event logs from other machines in the domain.

Experiment with the Windows Management Splunk application, available on the labshare or online at splunkbase.

You can set up Splunk to collect data from multiple machines in the same fashion as we did with Linux machines, by using forwarders. Start by configuring your receiver by navigating Manager → Forwarding and receiving &rarr Configure receiving → New then select a port e.g. 9997. Be sure to open that port in your firewall.

In Windows 7, navigate Control Panel → Windows Firewall → Advanced Settings → UAC.

Once there, select New Rule from the action pane; choose the port, the action, the network profiles, and the name of the subsequent rule.

Essentially the same actions are taken in Windows 2008, save that you navigate Start → Administrative Tools → Windows Firewall with Advanced Security.

In Vista, navigate Control Panel & rarr; Security → Windows Firewall → Change Settings → Exceptions → Add port.

With the receiver correctly configured, go to the Splunk Manager web interface on the hosts you want to forward data. Navigate Manager → Forwarding and receiving → Configure forwarding → New; then provide the information for your receiver.

By correctly configuring forwarders throughout your network, you can have all of the log data for all of your hosts forwarded to a central location for subsequent correlation and analysis.

It is possible to forward data from linux splunk instances to windows ones and vice versa. Try it!

Remember- splunk can forward to multiple machines, and receive from multiple machines- so you can contruct a distributed / redundant splunk network.

Note also that it will take some time after forwarding and receiving is set up for all of the information from the forwarder to be sent to the receiver. My experience with my virtual machines suggest that the process can be very resource intensive, and may slow the virtual machines until the transfers complete.

Other options- Snare

Snare for Windows is a tool that can be used to convert Windows log entries into syslog format and then send them to other hosts via either the syslog protocol or the Snare protocol.

Installation of Snare for Windows proceeds in the usual fashion. I recommend that you install Snare as a local system user, and recommend that you enable web access, at least for your localhost, to allow you to more easily configure the tool.

When the installation is complete, use your browser and visit localhost, TCP port 6161. If you specified a password, remember that the user name will be “snare”.

To configure Snare to forward its log messages to another host using the syslog protocol, navigate to Network configuration and enter the host name and the (UDP) port number to receive the logs. You also need to manually tell Snare to use syslog headers (instead of Snare native); you also choose the facility and priority for all of the syslog messages your system will dispatch.

We can also collect Snare and syslog messages on a host, this time using Snare Backlog. It too is installed in the usual fashion. Once running it listens on both the standard syslog (UDP 514) and the Snare native (UDP 6161) ports for messages. You can then configure either Linux machines (via syslog) or Windows machines (via syslog or Snare native) to send their results to this central server. Be sure you open the proper ports in the firewall!

Here you can see Snare backlog receiving messages from the host on which it is running, as well as syslog messages sent by a Linux machine and Snare messages sent by a Windows machine.

SSH

The best client for SSH from a Windows System in PuTTY. It is available on the lab share and online.

PuTTY supports password based logons; it also supports PKI. Read the section in the PuTTY help manual on PKI; use PKI to log on to one of your linux servers. Save the session variables in your PuTTY configuration so that they do not need to be specified each time a connection is made.

There are some SSH servers available for Windows- see FreeSSHd, OpenSSH Server, and CopSSH.

File Sharing

Microsoft Windows operating systems are designed to allow users to share files and folders.

Creating a (SMB) file share (Windows 7 / Vista)
Create a folder; navigate Folder (right click) → Sharing → Advanced Sharing. Specify the Share name, and the permissions of the users allowed to access the share. The default is everyone can read, no one can write. Note that two sets of permissions apply to the share- the NTFS (file system) and the SMB (sharing). Be sure that both are set appropriately.

Setting up a file server (Windows 2008)
We can also use a Windows 2008 R2 server as a file server. In this example, we will create a new server to act as the file server for our network separate from our domain controller and DNS architecture.

Follow the existing notes; set up the IP address and networking of the new
server. Set up the name of the host and join it to our domain. Be sure that the
appropriate entries exist in the DNS server.

With the basics covered, go to initial configuration tasks, select Add Roles → File Services. In this example, we install both the File Server and the File Server Resource Manager.

With the role installed, now we need to create the shared directory that the approved domain users can use. Navigate Server Manager → Roles → File Services → Share and Storage Management. In the action pane, choose Provision Share.

The first task when provisioning a share is to select the location of the directory to be shared. In this example, we will create the directory C:\ShareData\CommonData and will share that directory.

With the folder created, we modify permissions for the folder in the usual fashion so that all domain users have full control over that directory.

We will use SMB as our file sharing protocol; this is the preferred method for Windows systems. We have not discussed NFS, nor have we even installed the necessary services for NFS component on the server.

When the wizard asks for the SMB permissions to be used, we specify that Administrators have Full Control while all other users have Read and Write permissions. Remember- the enforced permission set is the more restrictive of the SMB permissions and the NTFS permissions.

For simplicity in this example, we will not apply a quota policy, nor will we set up a file screen.

The wizard will then ask whether we want to publish the SMB share to a DFS namespace. DFS is a system that allows one namespace to be served by multiple physical file servers and shares. Since our time is limited and our examples small, this is unnecessary for us.

Automatic Drive Mappings via Group Policy
We would like each user to have a drive letter mapped to the file share just created; this is done through Group Policy.

On a domain controller, go to group policy management and create a new group policy object- say “Common Drive Mapping”. Edit that policy: Common Drive Mapping → User Configuration → Preferences → Windows Settings → Drive Maps.

In the Drive Maps window, right click and select New → Mapped Drive. For Action, select “Create”; for Location, select the file share created previously. (You did remember the Share path in Step xii didn’t you?) Select a label for the drive share; select a drive letter- say P:. Apply the result.

Exit the group policy editor (with our policy now saved).

Return to Group Policy Management; select Group Policy Management → Forest → Domains → “YourDomainNameWhateverItIs” (Right click) → Link an existing GPO → Select your new GPO, which this example calls “Common Drive Mapping”. Apply this policy.

You do not need to apply this policy to the entire domain; you could simply apply it to one or more OUs.

Log onto a machine in your domain; verify that the drive p: is now mapped to the file share.

Individual file shares
We can also set up a directory to provide an individual file share for each domain user. We start by creating the file share itself, so we launch Share and Storage Management (Start → Administrative Tools → Share and Storage Management). Here we again Provision a Share; given that we have set up our common share at c:\ShareData\CommonData, in this example we will set up the directory c:\ShareData\UserData.

Now we will be more careful about the NTFS permission set we will apply. Select Edit Permissions, and then choose Advanced; when you do you will be presented with a dialog similar to the following:

From this we see that all users have read and execute privileges on the folder- something that we do not want, so we want to remove them. Attempting to do so however, we discover that we cannot. The reason for this is that these permissions are being inherited from the object’s parent. Thus, we start by unchecking the appropriate box. You are then given three options:

• To cancel, and not make any changes,
• To remove, and remove all inherited permissions, and
• To Add, which will convert the inherited permissions into explicit ones.

We select Add, which will keep the settings as they are, but allow us to now modify them. Remove the permissions for USERS. We now need to be sure that we can create the required subdirectories, so we require that Domain Admins have full control over the directory. Doing so, we end up with a permission set like

For the remaining settings we proceed as we did for the Commmon Share; be sure that your SMB permissions give users and groups Read and Write Access.

With the share complete, we now move to the individual users. From a domain controller, navigate to Active Directory Users and Computers (e.g. Start → Administrative Tools → Active Directory Users and Computers). Select a user, then select Properties. From the dialog box that results, choose the Profile tab. Under Home Folder, choose a drive letter and then provide the path to the file share we just created- with one additional twist. We will actually provide a link to a subdirectory based on the account user name; we can even simply specify %username in the directory name:

We repeat this process for each user.

When complete, we can simply login as a user, and verify that both drives are mapped to the correct places:

When you perform these tasks, you should also verify that you are unable to access the file shares of other users.

Accessing a (SMB) file share
Suppose that the file share is on the server “Server” with share name “fileshare”. [Note that the share name can be different from the name of the folder that is beng shared.] This can be from a file server, but does not need to be.

Windows (File explorer)
From file explorer or the equivalent, navigate to

 \\Server\fileshare

You will need sufficient permissions to access the share.

These permissions are cached, so you can run into trouble if either the settings or your credentials change during e.g. the process of setting up the share.

Windows (command line)
Run the command

c:\>net use z: "\\Server\fileshare"

to map the file share to the drive letter z:. You can also specify the user & password used to authenticate to the share on the command line; use the help command

c:\net use /?

to see the command line options. Running net use without any arguments will provide a list of all existing shares:

Z:\>net use
New connections will be remembered.


Status       Local     Remote                    Network

-------------------------------------------------------------------------------
OK           P:        \\stolat\commondata       Microsoft Windows Network
OK           Z:        \\stolat\userdata\vetinari
                                                Microsoft Windows Network
OK                     \\stolat\UserData         Microsoft Windows Network
The command completed successfully.

Windows (File explorer → Drive mapping)
From file explorer, navigate Tools → Map Network Drive. From here you can specify the drive letter, the remote share, and the user and password that will be used to authenticate to the share.

Linux (Gnome GUI- e.g. CentOS, Ubuntu)
Navigate Places → Connect to Server → Windows Share. Enter the Server name, Share, User Name, and Domain Name. Provide the password when asked.

On e.g. a Mint 11 machine, you can start navigate File → Connect to Server from the file browser.

Linux (KDE4 GUI- e.g. OpenSuSE)
Open Dolphin (the file browser); in the address bar, enter

smb://Server/fileshare

When asked for credentials, for the user name enter domain/username together with the the corresponding password.