Archive

Archive for February, 2007

DST Issues

February 21st, 2007

If you don’t know, the coming change in the start of daylight savings time (DST) may pose quite a problem for some. Because the date of the change has moved up by four weeks this year, Windows doesn’t know the correct date to shift without patching. Microsoft has released a patch for Windows 2003 and Windows XP, but there is no public patch for Windows 2000 because it has passed the end of its support life.

Now, what does this mean for YOU?

Well, if you deploy no patches to any systems, it means things will work but that for four weeks your clocks will be off by an hour. Sort of a pain, but not a show stopper.

What if you do deploy patches but may not be reliably reaching 100% of your systems? That is a problem. If you are like some small businesses I deal with, the servers are updated regularly (if not immediately), but the clients may or may not be. In this scenario, your servers will shift DST on March 11th like they should. Any unpatched workstations will not shift, and those stations will not be able to login to an Active Directory domain because of the embedded time stamps in Kerberos authentication. Uh oh. Problem. This is further compounded by the fact that there is no official Microsoft update for Windows 2000.

So, what are you to do? Here are some thoughts on how to handle this:

  • Patch! – Any Windows 2003 or XP machines should be getting Microsoft patches via Automatic Update. In this way, they should get patched to know about the change.
  • WSUS – Now, given the advice to patch, I will confess that I don’t like to allow an entire network of clients to go to Microsoft for updates. I would recommend the deployment of Microsoft’s WSUS (Windows Server Update Services). This will give you positive control over what patches are deployed, when they are deployed, and how they are deployed. Even better, it gives you a picture of which systems have received which patches.
  • Manual patching – For Windows 2000 it seems you have two options that I know of: pay Microsoft for the Windows 2000 patch (since it’s outside its support life) or roll your own. Without going off on a rant, let’s just say I would prefer to solve this myself rather than pay Mr. Bill any more $$.

I spent a few minutes of research and a few more of script development and have gotten what should be a working solution for patching Windows 2000 (and XP too). Now bear in mind the standard disclaimers: This is barely tested code. Your mileage may vary. Actual use of this code may cause abdominal pains and other unpleasant side effects. In other words, like any code you get off the internet, test the snot out of this before using it. That being said, this solution has both a .reg registry file and a .vbs script for deployment. This is specific to the Eastern time zone, although it would be trivial to change the one registry entry to apply to a different time zone.

Here is the .reg file contents:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Eastern Standard Time]
“TZI”=hex:2c,01,00,00,00,00,00,00,c4,ff,ff,ff,00,00,0b,00,00,00,01,00,02,00,00,\
00,00,00,00,00,00,00,03,00,00,00,02,00,02,00,00,00,00,00,00,00

[HKEY_LOCAL_MACHINE\SOFTWARE\ServerGuys\Patches\DST2007]
@=”True”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
“StandardStart”=hex:00,00,0b,00,01,00,02,00,00,00,00,00,00,00,00,00
“DaylightStart”=hex:00,00,03,00,02,00,02,00,00,00,00,00,00,00,00,00

As with any .reg file you could deploy this in a number of ways. One of my favorite ways to reach out and touch my clients is via a login script. Here is a script that will deploy this patch. Two notes: Obviously you don’t need the HKLM\Software\ServerGuys key in the .reg file for the DST patch; it’s used in the following code. Also, I know this is poor code, but it was quick to write and seems to work.

‘=============================
‘ Domain Login.vbs
‘=============================
On Error Resume Next

‘Get a reference to the WSH Network object
set WSHNetwork = CreateObject(“WScript.Network”)

‘Get a reference to the WSH Shell object
set WSHShell = CreateObject(“WScript.Shell”)

‘Windows DST 2007 Patch
‘======================
if fn_RegKeyExists(“HKLM\Software\SII\Patches\DST2007″) then
if WshShell.RegRead(“HKLM\Software\SII\Patches\DST2007\”) <> “True” then
WSHShell.Run “regedit /s \\SERVER\SHARE\DST-2007.reg”
end if
else
WSHShell.Run “regedit /s \\SERVER\SHARE\DST-2007.reg”
end if

‘=============================
‘ Functions
‘=============================
Function fn_RegKeyExists(ByVal sRegKey)
fn_RegKeyExists = True
sRegKey = Trim (sRegKey)
If Not Right(sRegKey, 1) = “\” Then
sRegKey = sRegKey & “\”
End If

On Error Resume Next
WSHShell.RegRead “HKEYNotAKey\”
sDescription = Replace(Err.Description, “HKEYNotAKey\”, “”)

Err.Clear
WSHShell.RegRead sRegKey
fn_RegKeyExists = sDescription <> Replace(Err.Description, sRegKey, “”)
On Error Goto 0
End Function

This script is just a slicing out of the relevant pieces from a rather large login script I use, but it should point you in the right direction.

See a problem? Have a beef? Feeling abdominal pains? Shoot me an email and tell me what you think: charles@serverguys.com.

Security, Windows

Caracolillo Coffee

February 21st, 2007

Espresso double shot

Just to give credit where credit is due: I love the coffee from Caracolillo Coffee down in Tampa.

I did my own home roasting from green for a couple years, but the coffee from Caracolillo is really good and very inexpensive such that I couldn’t keep justifying the time to roast my own. The first time I stopped in, Julian (the owner) gave me a tour of their roasting facility and all of their stock. It’s truly nice to deal with them. I buy a 5lb bag of espresso roast every five weeks or so. At $17.50 for the five pound bag, it’s an especially good deal too.

As a matter of fact, think I’ll go fire up a doppio now.

Coffee

FieldNotes – Login Script Basics

February 20th, 2007

FieldNotes

Today let’s start at the foundation of login scripts. Login scripts represent one of the easiest ways you can reach out and touch your users when they get on your network.

The login scripts that I have dealt with started with KiXtart (thankfully I managed to skip most of Netware). Using KiXtart we did simple automation of drive mappings and similar items. Over time I began to use KiXtart for more elaborate automation. Then in 2000 I began working with the then relatively new Windows Script Host. Since then WSH has been the basis of my login scripts for Windows clients. Using WSH you can access a wealth of external sources to draw a lot of power into your scripts.

Today my basic login script utilizes:

  • Windows Script Host: WSH is the core provider for the scripting environment
  • VBScript: I have written most login scripts in VBScript, although WSH can run other languages such as javascript.
  • ADSI: The Active Directory Services Interface (ADSI) provides access to user and group information that drives many of the decisions within the script logic.
  • WMI: The Windows Management Instrumentation (WMI) is the Microsoft flavor of WBEM which provides access to system level information about Windows hosts.

“So…” you may be saying to yourself “that’s all well and good, but how do I put this to use?” Well, for this installment, I’m going to lay out the basic setup for the scripts I use. This won’t do much, but it does set the stage for all other pieces. In later entries, we’ll look at useful things to do with it.

‘===========================
‘ Domain Login.vbs
‘ Simple Windows Script Host login script
‘===========================
On Error Resume Next

‘Get a reference to the WSH Network object
set WSHNetwork = CreateObject(“WScript.Network”)

‘Get a reference to the WSH Shell object
set WSHShell = CreateObject(“WScript.Shell”)

‘Get a reference to the FileSystemObject
Set fso = CreateObject(“Scripting.FileSystemObject”)

‘Get the user’s network ID
Username = WSHNetwork.UserName

‘Get the computer’s name
Computername = WSHNetwork.Computername

‘Bind to the user’s account on the network
Set UserObj = GetObject(“WinNT://DOMAINNAME/” & username & “,user”)

‘Build a list of all groups the user is a member of
for each grp in UserObj.Groups
GroupList = GroupList & grp.name & vbCrLf
next

‘Get local profile paths
Set WSHEnvProcess = WshShell.Environment(“Process”)
ProfileUserPath = WSHEnvProcess(“USERPROFILE”)
ProfileAllUsersPath = WSHEnvProcess(“ALLUSERSPROFILE”)

‘Login Message
‘=============
sLoginMessage = “Welcome to the network.” & vbCRLF
sLoginMessage = sLoginMessage & “—————————————” & vbCRLF
sLoginMessage = sLoginMessage & “Click OK to continue to login to your computer.” & vbCRLF
wscript.echo sLoginMessage

‘===============
‘ Script content
‘ goes here.
‘===============

This shell creates references to items we’ll need later, fetches the user name and computer name, and then connects to AD (or NT4 domain) to retrieve the user’s group membership. The paths for some local profile directories is discovered and a welcome message is displayed to the user.

That’s it so far. Nothing terribly interesting, but we’ll have much more fun with this as we go along.

FieldNotes

FieldNotes – An Intro

February 17th, 2007

FieldNotesOver the past decade plus, Todd and I have both accumulated significant experience in everything from enterprise networks to Mom & Pop shops. While we each have our own independent consulting companies, over the past few years we have both focused on serving small business. During this time we have developed some best practices that we apply to most if not all clients. The FieldNotes series will be our way of sharing these with you.

For me (Charles), part of my background was with Microsoft SMS doing large scale control and automation. I’ve always been interested in automation, and that has spilled down into my every day operations. When Windows Script Host first appeared, I jumped at learning what could be done with WSH, ADSI, and WMI. Today I try to use login scripts whenever possible to automate routine tasks. Also, Group Policy can be an enormous asset in a Windows network. My goal is to make the PC nothing more than an appliance that provides access. At one customer network, most users can go to any system on the network, login, and work without issue. For them we’ve gotten past the PC and on to work. Other sites are not quite as far along as that, but I’d like to share with you what has worked for us.

So… please be patient, please ask questions, and most of all please apply what you may find useful.

FieldNotes

PCI Perspectives Redux

February 6th, 2007

Datasecurity from PCI and Data Security Compliance was kind enough to both comment on my PCI thoughts from yesterday and pen an entry of his (her?) own. Apparently though I must not have been clear in my thoughts.

Datasecurity replied

I’m sorry to hear you feel that PCI is a tough pill to swallow.

To be accurate, I personally think PCI can have great impact in numerous ways. My question is pointedly about small business owners who may find the controls and changes needed for compliance to be a rather bitter pill.

Also Datasecurity stated

This is true, but why should a small or medium sized company be permitted to put my credit card data at risk just so they can reduce costs?

Of course no one is advocating reckless abandon with your personal credit card data. This paints a rather negative picture of those with whom you choose to do business. I think instead that for many small merchants compliance is an issue of control. Personally, as a network weenie I like the controls that compliance must introduce. Compliance encourages a more complete approach to security and processes. I like that. But what I would like to hear are how people have successfully (or not-so-successfully) introduced these controls and measures within small merchants.

Compliance for compliance sake is a good thing, but I would like to find strategies to convey that compliance can have so much more value. How can we help small merchants find the silver lining of compliance and begin to view it as a benefit rather than a burden?

PCI

PCI Compliance Perspectives

February 5th, 2007

Dealing with small businesses is a joy in many respects, but at times it can be difficult to translate some concepts to a level that feels applicable to a small business owner. PCI compliance is one such area for me.

Larger companies may already be used to compliance for SOX, GLB, HIPAA, etc. PCI just may be another area of compliance. For small business owners who may not have been working with any other compliance requirements, PCI can be a bitter pill to swallow. After all, many successful small businesses are successful because they are quick and agile in changing and evolving based on their circumstances. In many ways, PCI compliance runs counter to this attitude. Compliance requires documentation, processes, testing. This is not knee-jerk territory.

Personally I believe in many ways the requirements PCI puts forth can and should improve a small business rather than hinder it.

This article The Silver Lining of Enron over at The Security Catalyst is good reading to this end. It’s not for everyone, but I know of a couple business people who could benefit from some of this information.

Do you have any experience dealing with PCI compliance (or other compliance issues) with small businesses? I’d love to hear your stories and approaches. What works? What doesn’t? Drop me a line at charles@serverguys.com with your thoughts.

PCI