Trust Relationship Problems

One of the workstations in a domain was displaying "Trust Relationship Between Workstation and Domain has Failed" or something similar whenever a user tried to logon. I was able to logon via the local admin and access the network. This problem is caused by the shared secret or password used by Kerberos that had gotten out of sync with the domain controller. This particular machine has had some problem with hibernating in the past and is not used on a daily basis so that kind of makes sense. Googling the problem results in many hits that advise you to remove the machine from the domain and then rejoin it. This sounds a little heavy handed and at least one person agrees with me. I attempted the solution using netdom.exe and ran into a few issues and then making a command decision I figured it would take less time to leave and rejoin the domain then to mess with anything else. I can learn something new another day. After the reboots, the problem was solved and users could login normally. I should look at that hibernate problem while I am here....

Disable SSTP Certificate Revocation Check

Windows 7 supports a number of different types of VPN protocols. PPTP and IKE can be problematic when attempting to connect through a router that is conducting NAT. SSTP gets around that problem by tunneling over an SSL session. In order to enable SSTP, the server must have a certificate with a hostname that matches the certificate and the CRL URL must be reachable by the client. These are not always easy to accomplish when using a self signed certificate. In my case I had everything working except for the CRL URL. The client was unable to check the CRL so it rejected the connection. An interesting form of Denial of Service could be implemented by denying access to CRLs, but that is a bit of a digression. On the client computer, create a DWORD value NoCertRevocationCheck under HKLM\System\CurrentControlSet\Services\Sstpsvc\Parameters Set the value = 1. This will disable the certificate revocation check and enable the connection to proceed.

Smoothwall Enhanced Firewall Log Module

I really love my Smoothwall firewall. It offers good security using an older computer and it is infinitely customizable. One of the big strengths of Smoothwall is that with a little bit of Perl you can make it do almost whatever you want. There is a large ecosystem of third party modules that allow you to customize the functionality of your Smoothwall box.

One of the modules that I use is the enhanced firewall log. It is currently at version 1.4.3 and it enhances the normal log viewer and allows you to sort on different values and adds color coding to the entries.

This module has worked fine for me up until today. I was having some issues reaching some sites on the Internet and it appeared the firewall was the issue. I logged into the Smoothwall and it was slow to respond. The box had an uptime of a little over 9 months so I decided to reboot it. After the reboot was complete the firewall log was giving me an HTTP 500 error. Every other page was fine.

The error log showed:

Premature end of script headers: firewalllog.dat,
 at /httpd/cgi-bin/logs.cgi/firewalllog.dat line 409

After some Internet searching I found the following link in the Smoothwall communities.

Copy and paste of relevant information that fixed my problem.

he enhanced firewall logs mod with the CIDR capabilities assumes that all of the data the first field of the ipblock file will be numeric but it doesn't test it... my fix adds two lines and gets us around this problem... at least at the stage of reading the data from the ipblock file

 in /httpd/cgi-bin/logs.cgi/firewalllog.dat, near line 57, you should find

# Added by fwlogmod

use Socket;

use Net::CIDR;

# END added by fwlogmod

right after that, add

use Scalar::Util qw(looks_like_number);

so the block looks like this (until the maintainer possibly adds this to their released code)

# Added by fwlogmod

use Socket;

use Net::CIDR;

# END added by fwlogmod

use Scalar::Util qw(looks_like_number);

then down near line 217 you should find

open (ACTIVEBLOCKFILE, "/var/smoothwall/ipblock/config");

@ll=;
close(ACTIVEBLOCKFILE);
foreach $lll (@ll) {
            chomp($lll);
            @ittt=split(/,/,$lll);
            $cidrstr= $ittt[0];

between those last two lines, add

next if !looks_like_number($ittt[0]);  ## make sure it is a number!

so the whole block now looks like this

open (ACTIVEBLOCKFILE, "/var/smoothwall/ipblock/config");

@ll=;
close(ACTIVEBLOCKFILE);
foreach $lll (@ll) {
            chomp($lll);
            @ittt=split(/,/,$lll);
            next if !looks_like_number($ittt[0]);  ## make sure it is a number!
            $cidrstr= $ittt[0];

save and done... now if the first field of the ipblock file is not numeric, your firewall log viewer won't blow up on you.

Windows Update Error 800B0109

This Windows update error 800B0109 means that the WSUS signing certificate is not trusted. Windows 7 64 bit will not install the update if the certificate is not trusted. If this happens to a regular home user who gets updates via Microsoft you should check really hard to make sure you do not have some malware that has hijacked you WSUS process.

However is my case I used System Center Updates Publisher to push out Adobe updates and I created my own self signed certificate which is not trusted by the clients. I either need to add that certificate to the trusted store on each computer or create a new cert using my CA that is already trusted by the clients.

Because the root goal of this exercise was to eliminate visiting each client for Adobe updates, I will try the CA route and see how it goes.