Remote administration is a subject that's open to a lot of interpretation because one way could work for one environment and just not fit in for the next. It's pretty easy to setup a client to have a secure remote shell or remote desktop viewing software but a lot of my environments are not setup ideally so you're forced to use the tools that are on the system and free tools that you can download. Also add to the picture that you don't want to disrupt an employee working and answer may be at the command line.

In this example I'm investigating a report from the antivirus protection on a machine that its process is attempting to be disabled by a certain PID. I want to know what process is associated to that PID and why that's happening. My computer name is WORKSTATION and the PID in question is 1055.

tasklist /s WORKSTATION /FI "PID eq 1055"

You'll see that PID 1055 is a certain executable. In my case it was winlogon.exe and because the event was happening at 3:00AM, I knew that it was caused by Windows Updates being installed.

But if you noticed that a process named something like virus_hack_death.exe was running under this PID and it was trying to access your antivirus, you can use tasklist's cousin, taskkill.

taskkill /s workstation /PID 1055
OR
taskkill /s workstation /IM virus_hack_death.exe

Obviously this is a pretty weak example because whatever process you killed will most likely start again but you could also help those machines that are hung up and not accessible from the keyboard or through RDP. Connect in and kill the frozen process.

These directions will create a printer in Windows that will receive print jobs and then automatically delete them. This is probably only going to be useful for one in a million situations but I thought it was an interesting exercise none the less. If anyone does find this useful, I'd be interested to hear about it.

The reason I did this was because a program was hard coded that when you press the print icon, it would print. Then it would ask you if you wanted to print and select a which printer to print to. It would cause pages to be printed twice, and no matter where you wanted to print, they would go to your default. So I changed the default to just dump them using the Windows NUL function which works the same as /dev/null in Linux.

1. Open up your printers and go to "Add Printer"
2. Add it as a local printer and uncheck "Automatically Detect"
3. Click on "Create a new port:"
4. Choose "Local Port"
5. The port name is "nul" (yes one "l")
6. Name the printer Printer of Death (or whatever you want)

Test it by printing something out. A better test to believe that "nul" works is to run this from command line:

echo this is a test > nul

Normally this would print out to a file named "nul" if the concept of nul didn't work

If you haven't found out, the Windows Server 2003 Admin Pack does not work on Vista. This can be annoying for sys admins that aren't lucky enough to have Server 2008 installed everywhere. Luckily, there's a quick fix

1. Download and install the Server 2003 Admin Pack
2. Copy and and paste the following code into notepad and save it as "Adminpackfix.cmd" or something like that
   @echo off REM RegisterAdminPak.cmd REM (c) 2006 Microsoft Corporation. All rights reserved. set filelist=adprop.dll azroles.dll azroleui.dll ccfg95.dll set filelist=%filelist% certadm.dll certmmc.dll certpdef.dll certtmpl.dll set filelist=%filelist% certxds.dll cladmwiz.dll clcfgsrv.dll clnetrex.dll set filelist=%filelist% cluadmex.dll cluadmmc.dll cmproxy.dll cmroute.dll set filelist=%filelist% cmutoa.dll cnet16.dll debugex.dll dfscore.dll set filelist=%filelist% dfsgui.dll dhcpsnap.dll dnsmgr.dll domadmin.dll set filelist=%filelist% dsadmin.dll dsuiwiz.dll imadmui.dll lrwizdll.dll set filelist=%filelist% mprsnap.dll msclus.dll mstsmhst.dll mstsmmc.dll set filelist=%filelist% nntpadm.dll nntpapi.dll nntpsnap.dll ntdsbsrv.dll set filelist=%filelist% ntfrsapi.dll rasuser.dll rigpsnap.dll rsadmin.dll set filelist=%filelist% rscommon.dll rsconn.dll rsengps.dll rsjob.dll set filelist=%filelist% rsservps.dll rsshell.dll rssubps.dll rtrfiltr.dll set filelist=%filelist% schmmgmt.dll tapisnap.dll tsuserex.dll vsstskex.dll set filelist=%filelist% w95inf16.dll w95inf32.dll winsevnt.dll winsmon.dll set filelist=%filelist% winsrpc.dll winssnap.dll ws03res.dll for %%i in (%filelist%) do ( echo Registering %%i ... regsvr32 /s %%i ) echo. Echo Command Completed
3. Run the script as administrator and you're set

External Links

http://support.microsoft.com/kb/930056 - KB article about this subject. Gives you more specifics than I go into.
http://www.microsoft.com/downloads/details.aspx?familyid=e487f885-f0c7-436a-a392-25793a25bad7&displaylang=en - Server 2003 SP1 Admin Pack

This is a simple one that goes back to a conversation I had with a consultant. We were talking about adding a computer to a domain and then moving the computer to the designated OU that was dedicated to that site. I made the comment that it might be even better to precreate the computer account in the appropriate OU and then you don't need to bug a domain administrator to do the moving around. His reply was something like "Yea I haven't had good luck with that." That's one of my favorite reasons for technical problems. It's kind of like saying, I tried it once, it didn't work, so it must be broken.

Why Do This?

Anyways, the real reason that you would want to do this is if you have a team of IT staff where a few have domain administrators rights but most of them are just local admins on the workstations to provide support and install software. Adding a computer to the domain would be a normal task for these kind of support staff.

Problem

So you have a brand new computer that you want to add to your network. You assign on of the non domain admins to install necessary software and join it to the domain. When he adds it to the domain, the computer is dumped into the "computers" folder in AD where the appropriate group policies and delegated access is NOT applied. You want the new computer to go into a separate OU but you don't want to grant the user access to move or manipulate Active Directory AND you want to delegate the entire process to the admins so that you don't need to be involved in the specifics. So what do you do?

Solution

If you precreate the computer in the appropriate OU in Active Directory, when that computer is joined to the domain, it will have the group policies and permissions that it needs. As a domain admin, you can precreate the computer account yourself but you'd rather delegate access the IT support team. Here's how you do it:

Delegate Control To Non-Domain Admins

1. Open Active Directory Users and Computers
2. Right click on the OU and then click All Tasks>Delegate Control
3. Click Add and put in the appropriate user or group (IT Admins)
4. Click "create a custom task to delegate"
5. Click "only the following objects in this folder"
6. Check Computer Objects
7. Check "Create selected objects in this folder"
8. Under "Show these permissions" uncheck everything and click "Next"

You've now granted non-admins access to create computers inside of that OU.

Pre-Create New Computer

These are the tasks for the non-admin to perform using the Server 2003 Admin Pack

1. In Active Directory Users and Computers, right click the target OU the computer should go to and choose New>Computer
2. Name the computer
3. Under "The following users or group can join this computer to the domain" choose a group that has appropriate access like "IT Admins" or "Domain Users" to allow anyone do it.
   This is the step that is usually missed. If you don't do this, then by default Domain Admins are the only one that can add the computer to the domain.
4. Click Next

Now on the client you go through the normal process of adding the computer to the domain.

I was having dinner with some of the IT guys from a client I work for and I brought up the suggestion that they do MAC filtering for all of their network devices as an added security measure. The only problem was they were using Windows Server 2003 for the DHCP server which, natively, does not support MAC filtering. That's where the DHCP Server Callout DLL comes in.

This is a DLL that was created by the Microsoft DHCP team to allow access to certain parts of DHCP that were not before. In this case, MAC filtering.

Why filter MAC addresses

The idea of DHCP MAC filtering is that when a foreign system tries to connect to your network, they are not given an IP address unless their network card is on the list of allowed systems. In order for them to get on the network, they have to see a member of the IT department.

This protects a guest from accidentally spreading infections of spyware, viruses, or trojans not to mention it helps the IT department keep track of who and what goes on the network. [Please notice how I say accidentally because MAC spoofing would easily circumvent this security measure]

Install The Callout DLL

Overview:

• Install the DLL
• Create the necessary registry keys
• Populate the list of allowed or denied MAC addresses
• Restart the DHCP

Download and Install

1. Download and install the files: Download
   The MACFilterCallout.dll was installed to %SystemRoot%\system32 along with a file named SetupDHCPMacFilter.rtf.This includes very basic instructions.
2. Run the MacFilterCallout.msi and go through the steps to install it. All this does is extract the two files to your %systemroot%\system32\ folder.

Create the registry keys:

Choose one of two ways:
Option 1: Manually create the following registry keys:

Key Name	Key Type	Description
CalloutDlls	REG_MULTI_SZ	The location of the MacFilterCallout.dll
CalloutEnabled	DWORD	0 = Disable MacFilterCallout 1 = Enable MacFilterCallout
CalloutErrorLogFile	REG_MULTI_SZ	Log path. If this registry key is not specified, callout dll will output errors %WINDIR%\System32\Log.txt
CalloutInfoLogFile	REG_MULTI_SZ	Info log path. If this key is not present, no information messages will be logged.
CalloutMACAddressListFile	REG_MULTI_SZ	This is the name and location of the MAC filtering list you're going to be creating next.

Option 2: Merge the keys that I've made for you: Download

Download the file above, extract the contents, and merge the registry file that I created for you.

Here are the values the .REG file contains. Make sure they match up to your environment.

Key Name	Value
CalloutDlls	C:\windows\system32\MacFilterCallout.dll
CalloutEnabled	1
CalloutErrorLogFile	C:\windows\system32\MacFilterCallout.log
CalloutInfoLogFile	C:\windows\system32\MacFilterCalloutInfo.log
CalloutMACAddressListFile	C:\windows\system32\MAClist.txt

NOTE: If you are not using C:\windows as your windows directory, you will have to edit the registry to fit your system.

Create the MAC list

As I showed above, the key CalloutMACAddressListFile points to a location where you need to create a specially formatted text file that contacts which MAC addresses to filter.You can only choose to allow a certain set of MAC's or DENY them. Here is the format of that file:

MAC_ACTION = {ALLOW / DENY} 0cdc1c6d1266 05dc2de01023 ...

Note: You must include the { }'s around either the ALLOW or DENY action

Help Populating the MAC list

If you are going to use the ALLOW action you're most likely going to want to find all of the valid MAC addresses on the network. Here are some suggestions for ways you can do this:

• Nmap + ARP- with the command nmap -PR 192.168.0.0/24 or whatever your network is, it will do an arp scan of the network. Then doing an "arp -a > arptable.txt" gives you tab delimited file perfect for opening as a spread sheet and extracting the list of MAC addresses you need to use
• DHCP logs - use your existing DHCP server logs [usually under c:\windows\system32\dhcp\] to find all the MAC addresses in the last week.
• Switch logs - if you have a good enough switch, it will keep track of which MAC addresses are using the devices.

Note: Obviously be careful how you create this list. If the CEO of the company has a laptop that you happened to forget to put onto the allow list, he may not be happy with your new security measure.

Want to know what the MSI Installer REALLY does?

One major pet peeve of mine is when you download a program and it installs without telling you what it did. That's how this MSI works. Here's what it does:

• copies the dll to %system%/system32/
• copies the rtf to %system%/system32/
• registers BOTH the dll and the rtf as shared DLL's
• adds some interesting registry keys like on named "CompleteMacLevel" that I don't know what it does.
  

I know that may not help anything but it makes me feel a little better.

External Links

http://blogs.technet.com/teamdhcp/archive/2007/10/03/dhcp-server-callout-dll-for-mac-address-based-filtering.aspx - DHCP server team's blog with the original article

One of my clients had the problem of users being excessively prompted to update Firefox

A new version of Firefox is available:
It is strongly recommended that you upgrade Firefox as soon as possible

It then shows the "Download and Install Now" button but eventually fails when a normal users runs it because they are not local admins. This prompt repeats over and over until IT gets a phone call about how they hate Firefox and are going to go back to using IE.

It's actually as simple as you may think. If you change "C:\Program Files\Mozilla Firefox" to allow "YOURDOMAIN\Domain Users" write access, a normal user can update Firefox.

You can go around to each workstation but where is the fun in that? The builtin program "cacls" with the help of PSExec will let you update all of the computers on a site. This idea was put together by my friend with a little tweaking on my part. Basically you just create a list of computers, and then run the command remotely on each one.

Create a List of Computers

You can do this however you'd like but for me I like to export a list of computers them from ADUC. This will only help if your computers are in the same folder or OU. You could always just write down the names of the computers but that's boring.

1. Open Active Directory Users and Computers
2. From the menu bar choose View > Add / Remove Columns
3. Remove all columns that are not Name [Type, Description] and click OK
4. Open the folder or OU that contains the computers you would like to update
5. Right-click on the folder or OU and choose "Export List..."
6. Save the file as "computer_list.txt" somewhere logical to you

Create the Script

Here is the entire command all together. Hopefully it's obvious to change the YOURDOMAIN\ADMIN_ACCOUNT to an account that is a member of the Domain Admins group and change YOURDOMAIN\Domain Users to whatever your domain is.

psexec @computer_list.txt -u YOURDOMAIN\ADMIN_ACCOUNT cacls “%SYSTEMDRIVE%\Program Files\Mozilla Firefox” /E /G “YOURDOMAIN\Domain Users”:W

You will want to put this into a batch file because you'll have to run it again or on a regular basis if some of your computers are turned off or not on the network when you're running the script.

External Links

http://woodruffrc.com/allow-non-admin-users-to-update-firefox.html/trackback - link to my friend's website who actually did the testing and put everything together

I found this script from the site www.rlmueller.net which has a ton of other handy scripts that are free anyone to hack as long as you don't blame him for screwing something up.

This script searches through each domain controller of whichever domain your computer is a member of and outputs the "lastlogon" attribute of the account. Very useful in finding old accounts that are unused. Just be careful because some service accounts that you may have created on the domain will not show a lastlogon event at all

' LastLogonTimeStamp.vbs ' VBScript program to determine when each user in the domain last logged ' on. Domain must be at Windows Server 2003 Functional Level. ' ' ---------------------------------------------------------------------- ' Copyright (c) 2007 Richard L. Mueller ' Hilltop Lab web site - http://www.rlmueller.net ' Version 1.0 - March 24, 2007 ' Version 1.1 - July 6, 2007 - Modify how IADsLargeInteger interface ' is invoked. ' ' The lastLogonTimeStamp attribute is Integer8, a 64-bit number ' representing the date as the number of 100 nanosecond intervals since ' 12:00 am January 1, 1601. This value is converted to a date. The last ' logon date is in UTC (Coordinated Univeral Time). It must be adjusted ' by the Time Zone bias in the machine registry to convert to local ' time. ' ' You have a royalty-free right to use, modify, reproduce, and ' distribute this script file in any way you find useful, provided that ' you agree that the copyright owner above has no warranty, obligations, ' or liability for such use. Option Explicit Dim objRootDSE, adoConnection, adoCommand, strQuery Dim adoRecordset, strDNSDomain, objShell, lngBiasKey Dim lngBias, k, strDN, dtmDate, objDate Dim strBase, strFilter, strAttributes, lngHigh, lngLow ' Obtain local Time Zone bias from machine registry. Set objShell = CreateObject("Wscript.Shell") lngBiasKey = objShell.RegRead("HKLM\System\CurrentControlSet\Control\" _ & "TimeZoneInformation\ActiveTimeBias") If (UCase(TypeName(lngBiasKey)) = "LONG") Then lngBias = lngBiasKey ElseIf (UCase(TypeName(lngBiasKey)) = "VARIANT()") Then lngBias = 0 For k = 0 To UBound(lngBiasKey) lngBias = lngBias + (lngBiasKey(k) * 256^k) Next End If Set objShell = Nothing ' Determine DNS domain from RootDSE object. Set objRootDSE = GetObject("LDAP://RootDSE") strDNSDomain = objRootDSE.Get("defaultNamingContext") Set objRootDSE = Nothing ' Use ADO to search Active Directory. Set adoCommand = CreateObject("ADODB.Command") Set adoConnection = CreateObject("ADODB.Connection") adoConnection.Provider = "ADsDSOObject" adoConnection.Open "Active Directory Provider" adoCommand.ActiveConnection = adoConnection ' Search entire domain. strBase = "<LDAP://" & strDNSDomain & ">" ' Filter on all user objects. strFilter = "(&(objectCategory=person)(objectClass=user))" ' Comma delimited list of attribute values to retrieve. strAttributes = "distinguishedName,lastLogonTimeStamp" ' Construct the LDAP syntax query. strQuery = strBase & ";" & strFilter & ";" & strAttributes & ";subtree" ' Run the query. adoCommand.CommandText = strQuery adoCommand.Properties("Page Size") = 100 adoCommand.Properties("Timeout") = 60 adoCommand.Properties("Cache Results") = False Set adoRecordset = adoCommand.Execute ' Enumerate resulting recordset. Do Until adoRecordset.EOF ' Retrieve attribute values for the user. strDN = adoRecordset.Fields("distinguishedName").Value ' Convert Integer8 value to date/time in current time zone. On Error Resume Next Set objDate = adoRecordset.Fields("lastLogonTimeStamp").Value If (Err.Number <> 0) Then On Error GoTo 0 dtmDate = #1/1/1601# Else On Error GoTo 0 lngHigh = objDate.HighPart lngLow = objDate.LowPart If (lngLow < 0) Then lngHigh = lngHigh + 1 End If If (lngHigh = 0) And (lngLow = 0 ) Then dtmDate = #1/1/1601# Else dtmDate = #1/1/1601# + (((lngHigh * (2 ^ 32)) _ + lngLow)/600000000 - lngBias)/1440 End If End If ' Display values for the user. If (dtmDate = #1/1/1601#) Then Wscript.Echo strDN & ";Never" Else Wscript.Echo strDN & ";" & dtmDate End If adoRecordset.MoveNext Loop ' Clean up. adoRecordset.Close adoConnection.Close Set adoConnection = Nothing Set adoCommand = Nothing Set adoRecordset = Nothing Set objDate = Nothing

Save this text as a .vbs file and run it something like this:
cscript LastLogon.vbs > LogonTimes.txt

External Link:
http://www.rlmueller.net/Last Logon.htm - the site which I found this script and where you should go if you like it.