Target Client Configuration

Target Client Configuration

 

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.

How Does Open-AudIT Work?

Open-AudIT runs an Nmap discovery on each target IP address. Open-AudIT scans the Nmap top 1000 TCP ports, as well as UDP 62078 (Apple IOS) and UDP 161 (SNMP). For Open-AudIT to consider a target IP to have a device responding, any of the Nmap Top 1000 TCP Ports must be responding or the UDP 62078. A target that responds to UDP 161 (SNMP) only and NO other ports (TCP or UDP 62078 / 161) is not considered to be responding.

Why do we not consider a UDP port 161 response enough? Because it is very common for firewalls separating network segments to respond with UDP 161 for a target IP regardless of there being an actual device present at that IP address.

Why don't we simply scan every port TCP and UDP? On local networks this is usually OK to do, but on remote subnets this can take (literally) hours PER IP ADDRESS.

UDP port 161 Workaround

OA needs to see more than just UDP port 161 open on a device to consider it a legitimate device. If OA is only seeing UDP port 161 open OA will consider it a false positive and move on. If this is your situation you can edit the /usr/local/open-audit/other/discover_subnet.sh file and set consider_161_enough to “y"


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 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 don't 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 be checked are the time between the client and the domain controller and that DNS is resolving correctly (both forwards and backward).

Some users have also stated that 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

Another good Microsoft article, https://msdn.microsoft.com/en-us/library/aa826699%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

User Credentials Requirements

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

  • To audit a remote machine that is not in a domain, you must use the Administrator account (not "an" admin account, "the" Administrator account) on the target PC. ** and #1

  • 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 the connection is made using the details of the user running the script.

  • The account must have a password; WMI does not allow blank passwords.

  • The account password must NOT contain " (double quotes). This is because cscript (and wscript) cannot parse argument values containing double quotes. They are simply stripped. No (before you ask) escaping will not work. This is a cscript limitation and nothing to do with Open-AudIT.

** 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.

#1 NOTE - You can audit a remote machine without the using the actual Administrator account by creating a registry key. Create the below key on every machine to be audited and make sure the user credentials used are in the Administrators group.

\HKEY_USERS\.DEFAULT\Software\Microsoft\Windows Script\Settings

 

Enabling the Administrator account on non-Domained machines

Open a command prompt with administrative rights (Windows key, type 'cmd' (sans quotes) right click Command Prompt and select Run as Administrator.

In the command window type

net user Administrator

You should see Active set to false. Enable it with

net user Administrator /active:yes

Then run the first command again and confirm Active is now set. Then set the password with:

net user Administrator *

And type 'exit' to close the window.

Windows 7 and 2008 R2 not submitting audit using HTTPS

We have been advised that some Windows 7 and Windows 2008 R2 machine will not submit their audit result to the Open-AudIT server when running HTTPS. If this affects you , please see the following Microsoft article - https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi

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 its 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