Evan Hoffman's silly writings.

Cablevision loses WABC (Channel 7)?

evan — Sun, 07 Mar 2010 14:34:51 +0000

Wow. Glad I left. I imagine this will be temporary (like the HGTV ordeal earlier this year).

On another note, I got my 3rd FiOS bill – still running a credit. That’s $43 for 3.5 months of great service. Good luck competing with that, Optimum.

Free DNS Hosting?

evan — Wed, 24 Feb 2010 07:07:41 +0000

My Bluehost renewal is coming up soon and I’m really debating cancelling it. It’s like $8/month, but with my email going directly to Gmail now, this dumb blog is the only thing of note at evanhoffman.com, and I can move that anywhere. I already copied all the content to another server but I can’t find free DNS hosting anywhere. Maybe i’ll just run my own nameserver.

MAYBE!!!

2nd FiOS connectivity problem

evan — Sat, 13 Feb 2010 14:39:06 +0000

This is the second time this has happened: All the wifi devices in my house lose their connection to the FiOS router/access point (ActionTec MI424WR-GEN2). I checked my wired desktop and it wasn’t able to get an IP from the DHCP server (the router). The “Internet” light on the router was out. I unplugged the router and plugged it back in and it came back up fine. But this happened about a month ago too – I wonder if it’s a monthly thing? Either way, it’s annoying. Other than this, the internet service is phenomenal still.

Got my second FiOS bill

evan — Fri, 12 Feb 2010 21:21:18 +0000

So I got my second FiOS bill a couple of weeks ago. After the issue with my first bill was straightened out I ended up paying about $43 for the first 6 weeks of service. Well, my second bill was about $90, but applied a $180 credit on my account, so the bill showed -$91. So basically the first 3 months of service will end up costing me about $43. Even if it comes to $90/month for the remainder of the contract, this is such a huge savings that I don’t see how Cablevision could match it.

Running MRTG cfgmaker across your entire subnet?

evan — Wed, 27 Jan 2010 17:00:30 +0000

I realized recently that I had a bunch of newly-provisioned VMs that weren’t being monitored by MRTG (one of the tools we use to monitor network usage and other fun stats). Rather than manually run cfgmaker against all the new machines, I decided to script my way out of this.

Step 1: Build a list of hosts to monitor

For this I used an nmap ping test to generate a list of “up” hosts:

nmap -sP 10.0.0.0/24 -oG 10.0.0.0-255.255.255.0

This creates a list of IPs that are up in a format like this:

Host: 10.0.0.60 () Status: Up Host: 10.0.0.61 () Status: Up Host: 10.0.0.63 () Status: Up Host: 10.0.0.64 () Status: Up Host: 10.0.0.65 () Status: Up

Step 2: Parse out the IP address and run cfgmaker

Here’s the command I ran:

$ for i in `perl -ne 'chomp; next if $_ =~ /^#/; my @a = split(/ /); print "$a[1]\n";' 10.0.0.0-255.255.255.0`; do /usr/bin/cfgmaker --global 'LogFormat: rrdtool' --global 'WorkDir: /mrtg/data/mrtg' --global 'Options[_]: growright,bits' --global 'XSize[_]: 600' --global 'YSize[_]: 400' public@$i > /etc/mrtg/mrtg-$i ; done

This parses out the IP address from the input file and for each address, runs cfgmaker and puts the output in /etc/mrtg/mrtg-[ipaddress] .

Taking this a step further, I used gethostbyaddr to resolve the IPs to hostnames, so the MRTG files have the proper hostnames in them:

$ for i in `perl -MSocket -ne 'chomp; next if $_ =~ /^#/; my @a = split(/ /); my $ip = inet_aton($a[1]); my $host = gethostbyaddr($ip, AF_INET); print "$host\n";' 10.0.0.0-255.255.255.0`; do /usr/bin/cfgmaker --global 'LogFormat: rrdtool' --global 'WorkDir: /mrtg/data/mrtg' --global 'Options[_]: growright,bits' --global 'XSize[_]: 600' --global 'YSize[_]: 400' public@$i > /etc/mrtg/mrtg-$i ; done

Then all of the mrtg .cfg config files are in /etc/mrtg/, but who wants to put in all those cron entries to run each one? Not me. Simple fix?

cat /etc/mrtg/*.cfg > /etc/mrtg-all.cfg

Then you only have one cron entry.

My Apple tablet prediction.

evan — Sun, 24 Jan 2010 00:13:31 +0000

I know nobody cares, but I figured I’d hop on the hypewagon and write down my guess for the Apple tablet. I think a “big iPod Touch” would be pretty boring, and not worth making. My guess (based on nothing): the unit will be controlled by eye tracking, and it’ll be able to zoom in on whatever you’re looking at.

That is all.

Victory! Change Active Directory Password via LDAP through browser

evan — Wed, 13 Jan 2010 17:51:43 +0000

I had to give up on PHP and go to Perl, but it turned out not to be so bad. Users can now change their Active Directory passwords via a self-service web page that doesn’t require admin credentials. The Perl code is below. Authentication to the script is done via .htaccess LDAP authentication, so the REMOTE_USER env variable is assumed to contain the user’s username (sAMAccountName) by the time this script is called. There is a simple check for $ENV{HTTPS} to ensure the script is called via SSL, and AD requires password changes to be done via ldaps, so the whole thing should be encrypted end to end.

#!/usr/bin/perl
#
# Evan Hoffman (evanhoffman@evanhoffman.com)
# 13 January, 2010
#
# Base functionality from: http://search.cpan.org/~gbarr/perl-ldap/lib/Net/LDAP/FAQ.pod#..._in_MS_Active_Directory_?

print "Content-Type: text/html\n\n";

use Net::LDAP;
use Unicode::Map8;
use Unicode::String qw(utf16);
use MIME::Base64;
use CGI::Lite;

# build the conversion map from your local character set to Unicode
my $charmap = Unicode::Map8->new('latin1')  or  die;

my $host = 'ldaps://activedirectory.example.com';	

my $bind_dn = 'CN=ldapuser,OU=Utility,OU=Users,DC=example,DC=com';
my $bind_pw = 'secret';
my $base_dn = 'DC=example,DC=com';
my $search_filter = '(!(userAccountControl:1.2.840.113556.1.4.803:=2))';

my $ldap = Net::LDAP->new($host)  or  die "$@";

print 'Active Directory Password Changer $Id$';

die "REMOTE_USER not set.\n" unless $ENV{'REMOTE_USER'};

unless ( $ENV{'HTTPS'} eq 'on' ) {
	print "This script requires HTTPS.\n";
	die;

}

print "Logged in as $ENV{REMOTE_USER}.  LDAP URI is $host.
\n";

$cgi = new CGI::Lite;

%form = $cgi->parse_form_data;

if ($form{'op'} eq 'submit') {
	my $user_dn = $form{'dn'};
	my $user_pw = $form{'oldpassword'};
	my $newpw1 = $form{'newpw1'};
	my $newpw2 = $form{'newpw2'};

	die 'Password mismatch.'  unless ( $newpw1 eq $newpw2 );
	die 'No DN specified.' unless $user_dn;

	print "Attempting to bind as $user_dn ... ";

	my $mesg = $ldap->bind($user_dn,
			password => $user_pw);
	if ($mesg->is_error) {
		my $err = "Error attempting to bind as $user_dn: ". $mesg->error;
		print "$err";
		die $err;
	}

	print " OK.
\n";

	my $oldUniPW = $charmap->tou('"'.$user_pw.'"')->byteswap()->utf16();
	my $newUniPW = $charmap->tou('"'.$newpw1.'"')->byteswap()->utf16();

	print "Attempting to modify password for $user_dn ... ";

	$mesg = $ldap->modify($user_dn,
			changes => [
			delete => [ unicodePwd => $oldUniPW ],
			add    => [ unicodePwd => $newUniPW ] ]);

	print "OK
\n";

#	$mesg->is_error && die ('Modify error: '. $mesg->error);
	if ($mesg->is_error) {
		my $err = 'Modify error: '. $mesg->error;
		print "$err\n";
		die $err;
	}

	$ldap->unbind();
	print "VICTORY!! Successfully changed password for user $ENV{REMOTE_USER}, DN $user_dn, msg ID: ".$mesg->mesg_id ."\n";

} else {

# bind as dummy to lookup the user's DN
	my $mesg = $ldap->bind($bind_dn, password => $bind_pw );
	$mesg->is_error && die ('Bind error: '. $mesg->error);

	$mesg = $ldap->search(
			base => $base_dn,
			scope => 'sub',
			attrs => ['dn','cn','mail'],
			filter => "(&(samaccountname=$ENV{REMOTE_USER})$search_filter)"
			);
	$mesg->is_error && die ( 'Search failed: '. $mesg->error );

	$mesg->count || die ("Search for user '$ENV{REMOTE_USER}' returned no results.");

	my $entry = $mesg->entry( 0 );

	$ldap->unbind();

	print "LDAP DN for user '$ENV{REMOTE_USER}': ".$entry->dn.'';

	print "\n";
	print "\n";
	print "\n";

	print "\n";
	print "\n";
	print "\n";
	print "\n";
	print "\n";
	print "\n";
	print "Current password for $ENV{REMOTE_USER}: 
New password for $ENV{REMOTE_USER}: 
New password for $ENV{REMOTE_USER} again: 
\n";

}

print '';

LDAP-Active Directory authentication, Part 3

evan — Fri, 08 Jan 2010 23:12:34 +0000

So I got everything working with .htaccess and AD/LDAP authentication. Just add LDAPVerifyServerCert Off to the httpd config to let Apache authenticate against an AD server with a self-signed certificate (without dealing with the annoyance of putting the cert on each Apache server).

With that piece of the puzzle largely solved, I moved on to another: how will users change their passwords (which are all stored in Active Directory)? For users running Windows this is pretty trivial — they can do it right in Windows when they’re logged into the domain. But what about Linux users? I figured the easiest thing to do would be to make a web form to do this. The user would login (with the http/LDAP auth I previously setup) and the form would ask for their password (twice) and update it in Active Directory. Sounds pretty simple to me. I think if this were OpenLDAP it probably would be, but being AD, it’s not.

I’d already spent an hour or two writing the script (in PHP) when I was able to test its basic functionality. What I got was this:

Warning: ldap_mod_replace() [function.ldap-mod-replace]: Modify: Insufficient access in /home/evan/public_html/authtest/index.php

After some hair pulling I realized that I was binding with my “dummy” user when attempting to change the password. I figured the solution would be to re-bind as the user whose password I was attempting to change, which is what I did. I verified that the new bind worked, but I still couldn’t change the password. I decided to fall back to command line and started issuing some ldapmodify commands to see what I could and couldn’t do as the user. For whatever reason, it appears that even though the user CAN change his password in AD (the “user cannot change password” setting is NOT selected — I checked), the user cannot change his password through LDAP.

$ ldapmodify -vv -x -d8 -D "CN=Boba Fett,OU=Utility,OU=Users,DC=example,DC=com" -w secret -H ldaps://activedirectory.example.com -f bfett.ldif ldap_initialize( ldaps://activedirectory.example.com ) TLS certificate verification: Error, unable to get local issuer certificate request done: ld 0x9dd86e8 msgid 1 replace unicodePwd: " modifying entry "CN=Boba Fett,OU=Utility,OU=Users,DC=example,DC=com" modify complete request done: ld 0x9dd86e8 msgid 2 ldapmodify: Insufficient access (50) additional info: 00000005: SecErr: DSID-031A0F44, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

I Googled for the error code – DSID-031A0F44 – and found a couple of threads about people with the same problem, but no solutions.

The LDIF file I fed in looks like this:

dn: CN=Boba Fett,OU=Utility,OU=Users,DC=example,DC=com changetype: modify replace: unicodePwd unicodePwd::IgBhAGIAYwBkAGUAZgBnAGgAIgA= -

When I run the same command with my own DN/password for binding it works fine (though I did discover that you can assign multiple values to unicodePwd, meaning that, until I fixed it, the test user had two valid passwords, which seems like a bug on Microsoft’s part), I assume because I’m a domain admin. An “easy” out would be simply to have the script bind as a domain admin, but that means I’d be hardcoding a Domain Admin password in the script, which I’m against. I’ll have to put some more thought into this. Maybe Linux users will just have to log in to a Windows workstation to change their passwords. That’s not ideal, but it does already work.

Grr…

Single sign-on with Linux clients and Active Directory LDAP, Part 2

evan — Tue, 05 Jan 2010 22:45:55 +0000

Following up on my previous post, it turned out not to be as big of a deal as I’d originally expected to have Apache authenticate against AD and only allow users whose accounts weren’t disabled. In a nutshell, here’s what I did:

In your .htaccess file:

AuthBasicProvider ldap
AuthType basic
AuthName "AD LDAP Test"
AuthLDAPURL     "ldap://activedirectory.example.com/OU=Users,DC=example,DC=com?sAMAccountName?sub?(!(userAccountControl:1.2.840.113556.1.4.803:=2))"
AuthzLDAPAuthoritative On
AuthLDAPGroupAttribute member
AuthLDAPBindDN ldapuser@example.com
AuthLDAPBindPassword password
Require ldap-group CN=Sysadmins,OU=Internal Groups,OU=Groups,DC=example,DC=com

The key here is this LDAP filter: (!(userAccountControl:1.2.840.113556.1.4.803:=2)). This is the bitwise “AND” of the userAccountControl field and the decimal number 2, which is Microsoft’s value for “account is disabled.” The codes are listed here: http://support.microsoft.com/kb/305144

In httpd.conf (or some other server config file – I did it in /etc/httpd/conf.d/mod_authz_ldap.conf inside the section), add this directive:

LDAPOpCacheEntries 0

This tells Apache not to cache the results of the LDAP op. If you don’t put this in there, the server will cache the result of the user’s login for whatever the TTL is, and the user will be able to login even after you disable the account (until the cache expires). There may be other ways around this issue, but this works for me.

This works pretty well so far. Now I can create a “SVN Users” group in Active Directory, put the people I want in that group, use the above method for authentication and everyone’s SVN login will be the same as their domain login. Single sign-on one step closer. Yay!

.jobs domains – $120/year?

evan — Sun, 03 Jan 2010 23:58:58 +0000

I saw that Cablevision has www.cablevision.jobs as the link for its jobs page. Curious, I looked up how much a .jobs domain cost. GoDaddy has them for $119! That’s insane!

Current password for $ENV{REMOTE_USER}:
New password for $ENV{REMOTE_USER}:
New password for $ENV{REMOTE_USER} again: