Changing Password on Administrator Accounts - Performing an Audit

This article addresses a common task which many administrators have to address within their career as as an IT professional - changing the password on a core administrator account.

Scenario

It is well known that Administrators should always create dedicated service accounts with appropriate access to be used by network applications on a Microsoft network.  However there is always a case of a lazy administrator in the past who could not be bothered to create dedicated service accounts so they use the default domain admin account "Domain\Administrator" for applications and services to use.  So what happens in the event when there are applications and services across the network using a default domain account, everyone including previous employees, current employees and end users know the password to this account and you don't know exactly applications are using the account?  This article addresses exactly this situation.

Solution

The only way to identify all applications using an account for authentication is to revert to audit logs on domain controllers and identify the IP addresses in which the authentication attempts have been initiated from.  Once you have the IP addresses as an administrator your able to dig down into the servers configuration and identify what applications are installed and figure out what is making the authentication attempts from the account.  No application will be able to tell you exactly what program is performing the authentication request because all applications are different.  For example some applications may store the domain administrator credentials in a text configuration file, others might store the credentials in some type of database table and others might simply store it in a service or scheduled task.  No audit application understand the inter workings of every single application made, at best they can only look for where applications "usually" store credentials and return results based on that.

Another thing to note is each domain controller stores audit logs for authentication requests made against the individual DC.  There is no place where you can look at all authentication requests against domain controllers on a domain wide level without using additional software.  To gain inside into what authentication requests are being made on your network I recommend a product such as Snare Server.  Snare is seen by many as the industry standard for capturing and filtering audit and event log data.  Snare Server will pull audit logs from all domain controllers in your organisation and allow you to quickly identify exactly what servers in your organisation are using a specific account.

After ringing them for pricing, they are very cost effective compared to other audit collection tools on the market.  Its priced based on geographical region, so you will need to contact them to get pricing for your country.

Check out the following video which goes through Snare Server in detail:

http://www.intersectalliance.com/Contact.html?Video=SnareServer

Discovery VBS Script

As mentioned above the only way to perform a thorough audit of what applications in your environment are using a specific account is to revert to audit logs.  However below I will show you a handy VBS script which is able scan through all computer accounts in your domain and check if they are using an administrator account for a service or scheduled task.  This script can be downloaded from the following location, just rename it to *.vbs.

https://sites.google.com/site/cbblogspotfiles/ScanForUserID.txt

This script requires you to modify two fields:

• The strSearchFor field is the account in which you want to find.  For example, Administrator.
• The strExclude field are computers or locations within Active Directory in which you want to exclude.  If you want to exclude nothing you can leave this field as ""

strSearchFor = "Administrator"
strExclude = "dx-iren,dx-iren2,OU=Computers"

When you run the script it will display output in a webpage.  It pings each machine before performing the scan to ensure it is online so ensure ICMP is enabled on your windows firewall.  This can be done with group policy.

Ensure you launch it using cscript from a command prompt running as Administrator "Run As Administrator" to get around User Account Control (UAC) restrictions.

The audit results get pushed out to a CSV file under C:\results.csv and can be opened in Excel.

 Hope this post has been helpful and goodluck.

Identify number of items in folder Outlook Cached Exchange Mode and Exchange

This blog post shows you how to identify if a folder within your Outlook OST file has become out of sync with your Exchange server for Outlook clients which are running under cached Exchange mode.  To do this we will look at the item count both of the cached outlook client and the Exchange server.

To get the item count of a folder in Outlook, this can be done in two ways.  The first method is by using a VBS script such as the one from David Lee's blog:

http://techniclee.wordpress.com/2012/02/29/exporting-outlook-message-counts-to-excel/

A copy of this script can be found below.

'Declare some variables
Dim olkApp, olkSes

'Connect to Outlook
Set olkApp = CreateObject("Outlook.Application")
Set olkSes = olkApp.GetNamespace("MAPI")
olkSes.Logon olkApp.DefaultProfileName

'Call the export process once for each folder count to be exported
'Format is ExportMessageCountToExcel <Path to Outlook Folder>, <Path and filename of the Excel file to export to>, <Number of the sheet the count goes on>
'The following lines are examples.  Edit them as needed.  Add additional lines as desired.
ExportMessageCountToExcel "Mailbox - Doe, John\Inbox", "C:\Message_Counts.xlsx", 1
ExportMessageCountToExcel "Personal Folders\Projects", "C:\Message_Counts.xlsx", 2

'Disconnect from Outlook
olkSes.Logoff
Set olkSes = Nothing
Set olkApp = Nothing
WScript.Quit

Sub ExportMessageCountToExcel(strFolder, strWorkbook, intSheet)
    Const EXCEL_COL = 1
    Dim olkFld, excApp, excWkb, excWks, lngRow
    Set olkFld = OpenOutlookFolder(strFolder)
    Set excApp = CreateObject("Excel.Application")
    Set excWkb = excApp.Workbooks.Open(strWorkbook)
    Set excWks = excWkb.Worksheets(intSheet)
    lngRow = excWks.UsedRange.Rows.Count
    If lngRow = 1 Then 
        If excWks.Cells(lngRow,1) <> "" Then
            lngRow = lngRow + 1
        End If
    Else
        lngRow = lngRow + 1
    End If
    excWks.Cells(lngRow, EXCEL_COL) = olkFld.Items.Count
    Set excWks = Nothing
    excWkb.Close True
    Set excWkb = Nothing
    excApp.Quit
    Set excApp = Nothing
    Set olkFld = Nothing
End Sub

Function OpenOutlookFolder(strFolderPath)
    Dim arrFolders, varFolder, bolBeyondRoot
    On Error Resume Next
    If strFolderPath = "" Then
        Set OpenOutlookFolder = Nothing
    Else
        Do While Left(strFolderPath, 1) = "\"
            strFolderPath = Right(strFolderPath, Len(strFolderPath) - 1)
        Loop
        arrFolders = Split(strFolderPath, "\")
        For Each varFolder In arrFolders
            Select Case bolBeyondRoot
                Case False
                    Set OpenOutlookFolder = olkApp.Session.Folders(varFolder)
                    bolBeyondRoot = True
                Case True
                    Set OpenOutlookFolder = OpenOutlookFolder.Folders(varFolder)
            End Select
            If Err.Number <> 0 Then
                Set OpenOutlookFolder = Nothing
                Exit For
            End If
        Next
    End If
    On Error GoTo 0
End Function

This script will output the results to an Excel spreadsheet as shown in the following screenshot:

The second method is by selecting all items within the Outlook folder by pressing "CTRL + A" then pressing "ENTER".  Make sure you select NO!

Now to check the number of items in my Sent Items on the Exchange server.  This is done with the following PowerShell command:

Get-MailboxFolderStatistics -Identity "clint" -FolderScope "SentItems"

This shows the number of items on my Exchange server matches my Outlook client meaning my Outlook Cached Copy is indeed in sync!

Exchange ActiveSync Error (500) Internal Server Error

One of my customers had an issue on their Exchange 2010 server regarding Exchange ActiveSync.  The mobile device would Autodiscover the settings however it would fail to synchronise email.  After investigating the issue I quickly isolated the issue to the users Active Directory user account.  This was determined after I recreated the users mailbox by exporting to PST, disabling the mailbox, creating a new mailbox then reimporting the mailbox content.

I used the following command in PowerShell to test the users ActiveSync configuration status.

Test-ActiveSyncConnectivity -MailboxCredential (Get-Credential domain\username) -UseAutodiscoverForClientAccessServer

The command failed.

I then piped the output to a format list function to provide more details about the error received.

The error received was as follows:

"[System.Net.WebException]: The remote server returned an error: (500) Internal Server Error."

As I knew the problem was not to do with the mailbox contents as I had recently recreated the users mailbox, and this user was the only user effected by the issue, it had to be a problem with the Active Directory user account itself.

After investigating the user account I noticed the account was no longer inheriting permissions in Active Directory.  After re-enabling inheritable permissions, this resolved the problem.

Troubleshooting Fun with the Test-ActiveSyncConnectivity cmdlet

The Test-ActiveSyncConnectivity cmdlet is a great command for testing Active Sync connectivity with a device.  This can be used to test Active Sync connectivity with any user in your domain.  You may have issues using this command however and the example commands provided in the Get-Help in powershell are wrong.  For example the powershell help instructs administrators to enter the users UPN or DomainNetBIOS\Username format for the MailboxCredential parameter.

Test-ActiveSyncConnectivity -UseAutodiscoverForClientAccessServer $true -URL "http://contoso.com/mail" -MailboxCredential pauls@contoso.com

However the MailboxCredential parameter requires the full credentials including username and password of the user account in which your attempting to test.  Not doing so will result in the following error.

Cannot process argument transformation on parameter 'MailboxCredential'. Cannot convert the "jag" value of type "System.String" to type "System.Management.Automation.PSCredential".
    + CategoryInfo          : InvalidData: (:) [Test-ActiveSyncConnectivity], ParameterBindin...mationException
    + FullyQualifiedErrorId : ParameterArgumentTransformationError,Test-ActiveSyncConnectivity

To specify both the username and password along with the Test-ActiveSyncConnectivity cmdlet you can use the Get-Credential cmdlet, for example:

Test-ActiveSyncConnectivity -MailboxCredential (Get-Credential domain\username) -UseAutodiscoverForClientAccessServer

This command above will work.  What I also noticed is in the powershell help it mentions to use the $true switch for the UseAutodiscoverForClientAccessServer parameter.  You must not use the $true switch when running the command, if you do the command does not process correctly and you will receive this error:

Cannot bind positional parameters because no names were given.
    + CategoryInfo          : InvalidArgument: (:) [Test-ActiveSyncConnectivity], ParameterBindingException
    + FullyQualifiedErrorId : AmbiguousPositionalParameterNoName,Test-ActiveSyncConnectivity

So in summary, whenever you need to test Active Sync for an individual user within your domain, this is the command you need.

Test-ActiveSyncConnectivity -MailboxCredential (Get-Credential domain\username) -UseAutodiscoverForClientAccessServer