You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

 

The audit function of Open-AudIT is designed to work "out of the box" as much as possible with the default settings of target devices. Below are the requirements for the audit to work and some hints for items to configure when things are not working as planned.

Windows

On Windows, Open-AudIT uses WMI via VBscript as it's primary method of auditing. SNMP is also supported (as detailed below). Windows has a notorious reputation where remote WMI is concerned. It's tends to either "just work" or some mystery item on the target requires changing. If you are experiencing difficulty auditing remote Windows PCs, we have created a script called test_windows_client.vbs. You can run this script LOCALLY on the machine in question, after signing on as the user that is used by Open-AudIT to perform the audit. The script makes NO CHANGES to the target system. It checks most (not all) of the items below and generates PASS, FAIL and INFO tags for various properties. NOTE - If your target system is being audited correctly, you should not change any settings. Some of the below do not exist on Windows PCs that are able to be audited and some do exist. Only change settings if yours audits on particular PCs are not working as intended.

In addition to the below, other items that should checked are the time between the client and the domain controller and that DNS is resolving correctly (both forwards and backwards).

Some users have also stated removing and then rejoining the client PC to the domain has enabled auditing to work.

Note - All commands below should be entered into an elevated command prompt. To do this click Start -> All Programs -> Accessories -> Command Prompt, right click then "Run as administrator".

Microsoft Article, Connecting to WMI Remotely Starting with Windows Vista - http://msdn.microsoft.com/en-us/library/aa822854(v=vs.85).aspx

User Credentials Requirements

To audit a machine, you must have credentials and administrator level access.

  • To audit a remote machine that is not on a domain, you must use the Administrator account (not "an" admin account, "the" Administrator account) on the target PC. **
  • To audit a remote machine on an Active Directory domain, your supplied user (or if none provided, the user running the script) must be a member of the target machines Administrators group (or subgroup).
  • To audit localhost, any supplied credentials are disregarded and connection is made using the details of the user running the script.
  • The account must have a password; WMI does not allow blank passwords.

** NOTE - To enable a remote machine (Vista or above) to be audited that is not on a domain, by an account in the Administrators group, other than the actual Administrator account see the below section on UAC.

DCOM

Run the DCOM utility and verify (or set) the below attributes. Start -> Run, Enter DCOMCNFG and press OK. This will open the DCOMCNFG window.

Browse down the tree to Console Root -> Component Services -> Computers -> My Computer

Right click on "My Computer" and select properties

Select the "Default Properties" tab

  • Enable Distributed COM on this computer - Option is checked
  • Default Authentication Level - Set to Connect
  • Default Impersonation Level - Set to Identify

Select the "COM Security" tab

Click on Access Permissions ' Edit Default

  • Add "Anonymous", "Everyone", "Interactive", "Network", "System" with Local and Remote access permissions set.

Click on Launch and Activation Permissions ' Edit Default

  • Add "Anonymous", "Everyone", "Interactive", "Network", "System" with Local and Remote access permissions set.

Click on OK and close the DCOMCNFG window.

The above changes will require a reboot to take effect.

 

UAC

If you are getting an Access Denied scan error it might be UAC blocking inbound requests on the remote device. If the remote computer you are trying to query is in a workgroup (or not joined to a domain), UAC prevents remote queries by default, even if the account being used is in the Administrators group. Completely disabling UAC on the remote device allows you to get around this, but it is preferable to disable the subcomponent of UAC instead. You can do this by adding or editing this registry key on the remote device you are scanning and setting it's value to 1:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy

Note that Windows 8 and Server 2012 do not have a way to completely disable UAC (adjusting the slider in the GUI just disables notifications). You'll need to use the registry key method.

You can use this command from a command prompt on the remote device to quickly add the registry key:

reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

Reference - https://support.microsoft.com/kb/942817

The above change will require a reboot to take effect.

 

Local Security Policies

Run one of the following three Microsoft Management Console (MMC) snap-ins:

  • the Local Security Policy snap-in (secpol.msc) for member servers, or
  • the Default Domain Security Policy snap-in (dompol.msc) if you wish to configure these settings domain-wide as a GPO, or
  • the Default Domain Controller Security Settings snap-in (dcpol.msc) if you wish to assign the rights only on domain controllers.

Expand Security Settings -> Local Policies -> User Rights Assignment.

Check the Administrators Group has at least the following rights:

  • Act as part of the operating system
  • Log on as a batch job
  • Log on as a service
  • Replace a process level token

Go to Start -> Control Panel -> Administrative Tools -> Local Security Policy

Navigate to Security\Local Policies\Security Options

  • Network Access: Let everyone permissions apply to anonymous users - Set to Enabled
  • DCOM: Machine Access Restrictions - Add Anonymous, Everyone, Interactive, Network, System with full rights options set.
  • Network Access: Let everyone permissions apply to anonymous users - Set to Enabled
  • Network Access: Sharing security model for local accounts - Set to Classic

The above changes will require a reboot to take effect.

 

Simple File Sharing (XP)

Windows XP Professional computers in a workgroup environment will need simple file sharing disabled. You can make this change through the registry by setting the following key to a value of 0.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\ForceGuest

 

If this key does not exist, you can add it using a command prompt by:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa /v ForceGuest /t REG_DWORD /d 0 /f

 

You can also do this through settings by performing the following steps:

Click Start → Control Panel → Folder Options.

Select the View tab and scroll to the bottom of the Advanced Settings: section.

Uncheck the Use simple file sharing (Recommended) to disable the option and click the OK button.

 

SSPI means Security Support Provider Interface and is the interface used by VBscript / WMI to validate the user.

  • If ForceGuest is enabled (set to 1), SSPI will always try to log on using the Guest account.
  • If the Guest account is enabled, an SSPI logon will succeed as Guest for any user credentials.
  • If the Guest account is disabled, an SSPI logon will fail even for valid credentials.
  • If ForceGuest is disabled (set to 0), SSPI will log on as the specified user.

 

The above changes will require a reboot to take effect.

 

WMI

Windows WMI (Windows Management Interface) is used by the audit script for most of it's information retrieval. WMI can (at times) become corrupted. Microsoft have released a tool to enable you to check for this corruption.

The tool is available from Microsoft, here - http://www.microsoft.com/en-au/download/details.aspx?id=7684

Using the tool is detailed here - http://blogs.technet.com/b/askperf/archive/2012/02/03/wmidiag-2-1-is-here.aspx

For Windows Core servers, ensure you allow the firewall connections as per - http://blogs.technet.com/b/brad_rutkowski/archive/2007/10/22/unable-to-remotely-manage-a-server-core-machine-mmc-wmi-device-manager.aspx

 

AntiVirus

Some antivirus programs have been known to disable DCOM and remote WMI. You might check the settings of your antivirus program and disable them for testing.

 

Windows Firewall

To enable remote PCs to be audited, either the local (on the target machines) firewall (likely the Windows Firewall) must be disabled or access allowed for the WMI service.

For Windows Vista, 7, 8, 2008 and 2012, enter the following commands:

 

netsh firewall set service type=remoteadmin mode=enable
netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes
netsh advfirewall firewall set rule group="remote administration" new enable=yes
netsh advfirewall firewall set rule name="File and Printer Sharing (Echo Request - ICMPv4-In)" new enable=yes

Linux

On Linux, Open-AudIT uses SSH as it's primary method of auditing. SNMP is also supported (and detailed below).

The user used to audit a Linux host should be root or have sudo access. Some distributions do not allow sudo over an SSH session without a terminal. On these distributions, root can be used.

Using a user account that has no sudo access (and is not root) will result in an audit without all possible attributes retrieved.

Sudo / Root is required for:

dmidecode
    (system - uuid, serial, form_factor),
    (bios - version, smversion, serial),
    (processor - socket),
    (memory - all)

netstat
    (netstat - program name where not owned by user running script)

NOTE - Running as different users will generate a different list of environment variables.

ESX

On VMware ESX, Open-AudIT uses SSH as it's primary method of auditing. SNMP is also supported (and detailed below).

 

OSX

On OSX, Open-AudIT uses SSH as it's primary method of auditing. SNMP is also supported (and detailed below).

The OSX audit script should be run by root or using sudo access.

 

AIX

On AIX, Open-AudIT uses SSH as it's primary method of auditing. SNMP is also supported (and detailed below).

The AIX audit script should be run by root.

 

SNMP

SNMP v1 and v2c are supported. Read access is required.

 

  • No labels