How do you know when an approved and domain-joined workstation is turned on prior to someone even signing into the workstation? Or maybe, you are asking, why would I even want to know this? For those that work with network vulnerabilities scanning, such as the product by McAfee’s Foundstone division, this may be of importance. Imagine this scenario. Holiday season arises, everyone loves to take time off and you have an employee that took 2-3 weeks off. When that employee returns, there is a good chance that their computer will be out-dated. From a security standpoint, this is minimal, as it would likely begin receiving updates immediately following a successful sign-on. However, from a political standpoint, if Foundstone is used as a means of judging overall “security”, this workstation could significantly lower that score.
I already know what you are thinking…however, that does not eliminate the fact that dashboard reports are favored by CIOs, IT Directors and the like. Better have that score up to 100%!
StartupNotification
I wrote an application, StartupNotification, that helps with maintaining good scores. Keep in mind that this application only provides a means for notifying the appropriate personnel when a workstation is brought on the network that could potentially “damage”. Second, for this application to be effective in notifying, it must be added as a domain GPO or local policy startup script.
How It Works
Ran from a Windows computer startup script, StartupNotification checks a SQL database for previous records associated with the name of the workstation running StartupNotification. If no records exist, it reports an “Untracked” workstation; if record(s) exist and the latest record is (x) days old, it reports a “Tracked” workstation. After checking the status of the workstation, StartupNotification will create a new record with the workstation name and date of transaction, which will be used at the next StartupNotification check in.
The Application
Download source code (written in Visual Studio 2008).
If you are interested in this application working in your environment, then there are a few things your must do…
- Create a SQL table with the necessary fields.
- Update the application code with your connection string for the database.
- Update the email notification messages.
- Update the SMTP “from” email address.
This is simple, I’ll help you along the way if you follow the steps below carefully:
SQL Database and Table
I use Microsoft SQL Server 2005; however, this could be easily ported to MySQL, another SQL database, or even a Microsoft Access database. I created a separate database named STARTUPNOTIFICATION for the purpose of holding the table. The table layout is simple, as shown below:
| field name | data type | specifics |
| ID | int | primary key, no NULL |
| Workstation | nvarchar(50) | NULL |
| Date | datetime | no NULL |
| IPaddress | nvarchar(50) | NULL |
You must have a SQL user account that can SELECT and INSERT to this table. It is recommended that this account be a separate account and not the “sa” account or some other powerful, generic account.
Update Connection String
Locate the “mySQL.ConnectionString” property in the code, as shown the screen shot below, and update the string to match your server and database.
Update Email Notification Messages
Locate the “sendEmail” function calls, as shown in the screen shot below, and update the strings to display the text you want to be included in the email. As an example, I have another application I wrote that grabs information on the workstation and user at sign-in; I place a link to display who has signed in to that workstation in the email for quick identification of the workstation location.
Update SMTP “From” Address
The final line that needs your attention is the email address that is used as the sender for this application. In most cases you should use a “do not reply” type email address. Locate the sendEmail function near the bottom of the code and modify the msg.From property line, as shown the screen shot below.
That is all, compile and set to run as in a startup script. For GPO startup scripts, the application could reside in the NETLOGON path as permissions have not been granted by a signed in user.
Aaron Gilbert


