The phrase I most often hear in the auditing world today is “continuous auditing.” The term itself brings something totally different to mind, compared to what it actually means. However, the reality is that continuous auditing is necessary, wanted, and in most cases required. When it comes to Windows networks the concept of continuous auditing is new and not that well understood. Auditors are frustrated and confused as to what they can do to meet their needs and requirements. After months of research, education, and testing I have put together an array of options that auditors can use in order to complete, at least at a minimum, the auditing of Active Directory.
Defining Security Continuous Auditing
I first must define what my interpretation of continuous auditing is. After my initial understanding of continuous auditing, I did some research to find what the industry considers to be continuous auditing. The following are my findings:
- The need to ask an administrator for a security setting in real time.
- The need to gather information without the administrator’s assistance that is, no administrator privileges are required, in real time.
- The need to gather continuous reports of specific settings, such as group membership, etc.
There are most likely other definitions that you might come across but these are some of the key instances of when an audit would need to be accomplished outside of the annual or bi-annual audit.
Using PowerShell for Continuous Auditing
PowerShell is a free and powerful tool that was developed by Microsoft for Windows XP and later versions. PowerShell now comes standard in Windows Server 2008 and Windows 7, but it needs to be installed on Windows XP and Server 2003 if you need to run the tool there.
PowerShell does require some local administrative access, as you will see, but does not require ANY domain level administrative access for the gathering of security settings that are included in this document. The biggest issue is setting up PowerShell so it can gather the required information.
There are two versions of PowerShell that you can obtain. Each version can run on certain OS platforms. Below is a list of the versions of PowerShell, where to obtain the PowerShell install bits, and which operating systems the version of PowerShell supports.
- Version 1.0 (download details)
- Windows XP
- Windows Server 2003
- Windows Vista
- Windows Server 2008
- Version 2.0 (download details)
- Windows XP with SP3
- Windows Server 2003 with SP 2
- Windows Vista with SP1
- Windows Server 2008
- Windows 7
- Windows Server 2008 R2
Setting up PowerShell
Once you get PowerShell installed, you still need to do some additional tasks to be bale to run your cmdlets (Commandlets as they are called). Since PowerShell is designed to be secure by default, you will need to loosen up security in order to run some cmdlets, such as the one listed in this article.
To loosen up security of PowerShell, you will launch PowerShell on your computer as a local administrator. (If you don’t have local Administrator privileges on your local computer, you will need to get someone that does have this privilege to perform this task. IT is the ONLY task that needs to be run as a local admin which is listed in this document).
From within the PowerShell window, run:
Then, when prompted as shown in Figure 1, type:
This can also be seen in Figure 1.
Figure 1: Setting PowerShell to run non-signed cmdlets.
Now, you can run the PowerShell cmdlets that are described below without any errors due to security restrictions.
Obtaining the PowerShell Cmdlet for AD
Now, you need to get the PowerShell cmdlet for AD that is explained in this article. At the end of this article I am going to list the contents of the cmdlet, but you can also get it from the original site where I obtained it. The original site is found here.
In order to get the cmdlet configured and saved properly, you need to perform the following steps:
- Copy the contents of the online code from the link above or the code below in this article using the standard Windows “highlight text”, then select copy.
- Insert or paste the text from step 1 into Notepad. (You can’t use Word, as this will potentially put extra characters into the code, which will cause the cmdlet to not run.)
- Save the notepad file as a .ps1 file (Be sure to not save with the standard .txt extension! This might be tricky if you have never done this. To ensure this is saved correctly, make sure you select “All Files” when saving the file and manually input the .ps1 extension.)
Now you are ready to run some cmdlets!
Running Your New PowerShell Cmdlet
In order to run the cmdlet properly, you should maneuver over to the folder where you saved the .ps1 file. PowerShell accepts standard Command Line syntax, such as:
This will move the PowerShell current position to the pscmdlets folder under the root c:\. Just change the path to where you have placed your .ps1 file.
Now, you must input the correct syntax to make the cmdlet work. The way we are PowerShell you must type .\ before the cmdlet name. To run the cmdlet type:
This should produce the output similar to what you see in the beginning of the code listed below.
Obtaining AD Info
Here are some cmdlet commands you can run to gather some pretty powerful info from AD:
.\getadinfo.ps1 -Domain yourdomain.corp -ToCsv C:\MyFolder\MyFile.csv
.\getadinfo.ps1 -Domain yourdomain.corp -OU AllOU -Property distinguishedName,l -ToCsv C:\MyFolder\MyOUFile.csv
.\getadinfo.ps1 -Domain yourdomain.corp -User administrator
.\getadinfo.ps1 -Domain yourdomain.corp -Group “Domain Admins”
PowerShell is awesome, powerful, and free. It allows administrators and auditors to gather information about Active Directory with little effort. You can get information about user accounts, group accounts, the domain, etc. PowerShell was designed to update, analyze, and modify Windows computers, so it is ideal for this task. In my next article I will cover how to use third party tools which leverage PowerShell, as well as show you how to put PowerShell cmdlets into scheduled tasks for “true continuous auditing”!