If you’ve configured the Server Authentication Certificate Template GPO option, which determines the certificate that the machine uses for Remote Desktop connections, and applied it to 2008 R2 or older servers then you may find that you’re getting a lot of duplicate certificates being issued. It’s a problem with an easy solution but it’s not an obvious one.

You see, if you read the documentation for the setting (something which is helpfully not included in the GPO explanation text in the GPMC) you’ll soon discover that:

Important
You must set the certificate template’s attributes Template display name and Template name to the same value.

Due to a disparity in the way the API checks to see if a certificate already exists on the machine for this purpose if the Template Name is not the same as the Template Display name it fails to identify that it already has a matching certificate and so requests a new one.

This problem is resolved in Server 2012 R2. It’s possibly resolved in Server 2012 as well but I don’t have a box to hand I can test with.

As far as I can tell the “Do not automatically reenroll if a duplicate certificate exists in Active Directory” option has no impact on this issue.



I’m amazed that I haven’t previously had a need for something like this, but I was looking for some way to visualise AD group memberships, specifically to take into account fairly deeply nested groups. After a fair bit of searching, a lot of dead-ends and some products that seriously over-sold themselves, I came across this little beauty:

https://gallery.technet.microsoft.com/scriptcenter/Graph-Nested-AD-Security-eaa01644

It’s a Powershell module which extracts group memberships for a User, Group or OU (well, everything in that OU anyway) and creates a Graphviz file that gives a functional, if not very pretty, visualisation of the group membership hierarchy. The output looks something like this:

Draw-ADSecurityGroupNesting
Sample output

Extremely handy if you’re trying to get a better idea of how your group nesting shakes out or where you may have circular memberships or redundant groups.



I saw this in someone’s signature on one of the Technet forums and though it was a really clever idea; nobody wants to put their email address in plaintext on the internet because it’ll just get hoovered up by spammers and most common obfuscation techniques are easily worked around by spambots, so how about…

[string](0..21|%{[char][int](23+("74778682874174878091987477868287237688239484").substring(($_*2),2))})-replace " "

Clever, isn’t it.

You can generate your own with the following code:

$out = $null
$email = "user@example.com"
foreach($char in $($email.tochararray())){$out += @([System.Convert]::ToUInt32($char)-23)}
$string = [string]$out -replace " "
"Your code is: [string](0..$($($out.length)-1)|%{[char][int](23+(`"$string`").substring((`$_*2),2))})-replace `" `""

Which should give an output that looks something like:

[string](0..15|%{[char][int](23+("94927891417897748689857823768886").substring(($_*2),2))})-replace " "

Email addresses with certain symbol characters may not encode properly.



In light of today’s news that OpenSSL has been pretty broken for the best part of a year (see: here, amongst others), I decided to revisit the SSL configuration on my Forefront TMG servers with regard to their published websites. Digging around the internet I came across several useful pieces of information that I thought I’d share.

First up is Qualys’ SSL Server Test tool @ https://www.ssllabs.com/ssltest/index.html, which will give you a report on the state of your SSL setup, mine had some issues mostly due to oversights on my part.

Next, is this article on ISAServer.org which runs you through some non-obvious-but-crucial security tweaks you can make to your TMG server to improve its protocol support and avoid a couple of renegotiation issues.

Finally, I was directed to the IIS Crypto tool from Nartac Software, which doesn’t do anything you couldn’t do by hand (and does go back over a couple of protocol tweaks from the previous link), but does make it one hell of a lot easier. Don’t be fooled by the name, the windows crypto settings it changes are server-wide and don’t just affect IIS.

So, with a couple of hours of work I went from an F (Oops, that’ll teach me to forget about disabling SSLv2) to an A and now properly implement PFS for clients that support it.



Update: Please note that the up-to-date version of this blocklist is maintained here, this post will not be updated with any future changes to the Nobis ranges.

Just when you think you’ve finally blocked all of the Nobis Technology Group’s (aka Ubiquity Server Solutions) IP ranges they go and take over another range and carry on merrily spamming your comments section.

So, I’ve taken the nuclear option and blacklisted every IP range associated with AS15003 (which is their AS) as per the very helpful http://bgp.he.net/AS15003#_prefixes – yes, they really do have 867 IPv4 netblocks allocated to them.

I’ve collapsed the ranges down to a slightly more manageable 119 (there are a lot of contiguous blocks in there) and added it to my blocklist page, it’s also reproduced below, so help yourselves.

#Nobis/Ubiquity Ranges - http://bgp.he.net/AS15003#_prefixes
Deny from 23.19.0.0/16
Deny from 23.80.0.0/16
Deny from 23.81.0.0/17
Deny from 23.81.128.0/18
Deny from 23.81.192.0/20
Deny from 23.81.216.0/21
Deny from 23.81.224.0/19
Deny from 23.82.0.0/16
Deny from 23.83.0.0/17
Deny from 23.83.128.0/18
Deny from 23.83.192.0/20
Deny from 23.104.0.0/14
Deny from 23.108.0.0/15
Deny from 23.110.0.0/16
Deny from 23.111.251.0/24
Deny from 23.224.0.0/15
Deny from 23.226.48.0/20
Deny from 23.235.128.0/18
Deny from 23.248.192.0/18
Deny from 64.120.1.0/24
Deny from 64.120.2.0/23
Deny from 64.120.4.0/22
Deny from 64.120.8.0/21
Deny from 64.120.16.0/20
Deny from 64.120.32.0/19
Deny from 64.120.64.0/19
Deny from 64.120.96.0/20
Deny from 64.120.112.0/21
Deny from 64.120.122.0/23
Deny from 64.120.124.0/22
Deny from 67.201.0.0/21
Deny from 67.201.48.0/23
Deny from 69.31.107.0/24
Deny from 69.147.224.0/23
Deny from 69.147.227.0/24
Deny from 69.147.228.0/22
Deny from 69.147.232.0/21
Deny from 69.147.240.0/22
Deny from 69.147.244.0/24
Deny from 69.147.246.0/23
Deny from 69.147.248.0/21
Deny from 69.174.60.0/22
Deny from 70.32.32.0/20
Deny from 72.37.204.0/24
Deny from 72.37.221.0/24
Deny from 72.37.222.0/23
Deny from 72.37.224.0/21
Deny from 72.37.237.0/24
Deny from 72.37.242.0/23
Deny from 72.37.246.0/23
Deny from 74.113.144.0/22
Deny from 108.62.0.0/16
Deny from 108.171.33.0/24
Deny from 108.171.34.0/23
Deny from 108.171.36.0/23
Deny from 108.171.38.0/24
Deny from 108.171.43.0/24
Deny from 108.171.44.0/22
Deny from 108.171.53.0/24
Deny from 108.171.54.0/23
Deny from 108.171.56.0/24
Deny from 108.171.59.0/24
Deny from 108.171.60.0/23
Deny from 108.171.63.0/24
Deny from 108.177.128.0/17
Deny from 108.187.0.0/16
Deny from 142.91.0.0/16
Deny from 142.234.0.0/16
Deny from 147.255.0.0/16
Deny from 162.209.128.0/17
Deny from 162.222.68.0/22
Deny from 172.240.0.0/15
Deny from 172.247.0.0/16
Deny from 172.255.0.0/16
Deny from 173.208.0.0/18
Deny from 173.208.64.0/19
Deny from 173.208.96.0/21
Deny from 173.208.104.0/24
Deny from 173.208.106.0/23
Deny from 173.208.108.0/22
Deny from 173.208.112.0/20
Deny from 173.234.0.0/18
Deny from 173.234.64.0/20
Deny from 173.234.80.0/21
Deny from 173.234.88.0/23
Deny from 173.234.90.0/24
Deny from 173.234.92.0/22
Deny from 173.234.96.0/21
Deny from 173.234.105.0/24
Deny from 173.234.109.0/24
Deny from 173.234.110.0/23
Deny from 173.234.112.0/20
Deny from 173.234.128.0/19
Deny from 173.234.160.0/20
Deny from 173.234.176.0/21
Deny from 173.234.184.0/22
Deny from 173.234.188.0/24
Deny from 173.234.190.0/23
Deny from 173.234.192.0/18
Deny from 174.34.128.0/19
Deny from 174.34.160.0/20
Deny from 174.34.176.0/21
Deny from 174.34.184.0/22
Deny from 174.34.188.0/23
Deny from 174.34.190.0/24
Deny from 192.151.224.0/20
Deny from 192.151.248.0/21
Deny from 192.161.80.0/20
Deny from 192.163.160.0/19
Deny from 192.229.64.0/18
Deny from 192.238.128.0/17
Deny from 192.253.240.0/21
Deny from 196.45.112.0/22
Deny from 198.48.96.0/20
Deny from 198.48.112.0/22
Deny from 216.6.224.0/20
Deny from 216.151.31.0/24
Deny from 216.152.224.0/20
Deny from 216.193.237.0/24
#End of Nobis/Ubiquity Ranges

No doubt they’ll buy up more IP space as needed so they can continue to sell their services to spammers, malware distributors and other disgusting excuses for human beings.



From today, this site is available over HTTPS for the security-conscious amongst you.

There are a few old posts with embedded resources that load via http, so you might get the occasional warning about that, but going forward it shouldn’t be a problem.



So today I discovered that the LastLogonTimestamp attribute of an account in AD (also known as LLTS) is only updated on logon if the old value is more than 14 days in the past. That means the value can only be trusted if it is more than 14 days in the past.

This, as it turns out, is very annoying if you’re trying to do some semi-half-assed auditing. Now, you can use the LastLogon attribute, which is always up to date, but that isn’t replicated between DCs so you have to query all of them.

Note to my future self: Do not rely on LLTS for anything more recent than 14 days.



As we all know, there are certain published standards for things like Windows Security and Group Policy that companies can use as baselines for their systems; standards such as the CIS Security Configuration Benchmarks. These standards often mandate the configuration of certain GPO settings that fall under the “MSS” category which do not appear in the Security Configuration Editor or Group Policy Management Editor by default.

In order to add these settings so that you can easily configure them without screwing around in the registry or writing your own ADMX templates, you can download and import them as part of the Microsoft Security Compliance Management Toolkit. Unfortunately, getting access to this toolkit requires the installation of the Management software with its associated requirement of a SQL Express instance, which is ludicrous.

So, I am including below, the WSF script that is required to import these settings into the Group Policy Editor on a given 7/2K8R2 machine (and probably Vista/2K8 as well, but I haven’t tried it). Use cscript LocalGPO.wsf /ConfigSCE to import the settings, which will then appear under “Computer Configuration->Policies->Windows Settings->Security Settings->Local Policies->Security Options” in the Group Policy Editor (Or the appropriately reduced path in the Security Configuration Editor).

Download LocalGPO.wsf

If you’re dumb enough to download and run a VBScript from an untrusted source without doing the usual safety checks then you probably shouldn’t be using this kind of “hack” in a production environment (in fact, you probably shouldn’t be allowed near a production environment in the first place…).



My spam Blocklist has been slowly growing since I created it in order to stem the tide of comment spam coming from Nobis/Ubiquity Server-owned address blocks. Ultimately I made the choice to block all the netblocks that they had allocated from ARIN and that seemed to have worked, up until today when I started getting comment spam from some brand new Nobis/Ubiquity addresses.

It would seem that they’ve got themselves a netblock from RIPE and started using that for spamming as well; the range in question is 176.31.50.64/27 but given their apparent dedication to illegal activity, it wouldn’t surprise me if others start popping up here and there as well. Thankfully, the relative scarcity of available IPv4 blocks is making it much tougher for these spamming fuckers to evade blocking mechanisms without resorting to botnets.

That said, when you’re getting more than 10 times as many spam comments as legitimate ones, it doesn’t exactly fill you with confidence that we’ll ever get a real handle on the problem.



I have previously completed some work for a mid-sized organization and some of the things I’ve come across in the few shorts weeks I’ve had access to their systems are, frankly, astonishing. I’ve barely even scratched the surface and we’re already well into “so bad it’s not even wrong” territory here; a few examples:

  • Critical Servers not under warranty
  • Critical Servers not backed up
  • Servers backed up to disks on the same disk array as the live data
  • Backups taken to tape and then left in the tape loader indefinitely
  • Servers not patched, ever
  • Antivirus not installed on servers, or installed but disabled “for performance reasons”
  • Server hardware/software not monitored
  • Speed/Duplex on all network interfaces set manually
  • Public address ranges for internal network addressing
  • A single broadcast domain for all devices on the network
  • 120m+ Ethernet cable runs
  • Cat3 cable runs within the core infrastructure (undocumented)
  • New user credentials sent by email, via an externally hosted mail system, to user’s line manager
  • All IT Staff granted unaudited access to the entirety of the file servers
  • All IT Staff local admins on all servers

And that’s just the stuff I’ve found so far and haven’t already repressed. I honestly have no idea where to begin, if there were such a thing as a Worst Practice Guide they’d have not only followed it to the letter, but added their own extensive appendices as well.