It took a while, but after having lost my previous Raspberry Pi to the Gods Of SD Card Failures, I finally got around to setting pi-hole up again on the new one (backups, dude, backups! Yes, I hear ya...)

First things first: what's a Pie Hole? It's a bit of software actually called pi-hole meant to keep network clients (and users, family members, pets, stray aliens, etc) from getting overwhelmed with the ads and trackers the Daemons of Internet try to bestow upon us on a continuous basis.

To do so it acts as DNS server in your network and compares each DNS-request to a list of known ad/spam/malicious sites. If the DNS address requested is on there it disappears into pi-hole's Black Hole of Doom. Furthermore, it includes a DHCP, so you can use pi-hole as your one-stop shop for your basic networking needs. 

It's easy to install. The project's home is at https://pi-hole.net and their GitHub at https://github.com/pi-hole/pi-hole/#one-step-automated-install tells you how to proceed. 

Then why, dear writer, are you writing this blog post? Glad you asked, esteemed reader...  Pi-Hole sets up its own webserver. Just like most other projects which sport a webinterface for easy administration. That's great - but it's yet another service running on my pi. I'd rather re-use what I have. Since my energy-use tracking system (DSMR, blog post to come!) uses Nginx that's what I want pi-hole to use, too. And it does - now.

Interested in getting Pi-Hole running with Nginx ? Read on.

Good news - Ubiquity has released version 6 of the Unify controller software in september 2020.

If you're running Unify on a Raspberry Pi (on raspbian) then you're likely to be greeted by a message that UBNT's repository has changed when you try to run apt-get update. 

Something like:

E: Repository 'http://dl.ubnt.com/unifi/debian stable InRelease' changed its 'Codename' value from 'unifi-5.13' to 'unifi-6.0'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

So - what to do?

Simple: Run  apt-get update --allow-releaseinfo-change

Details? Read on!

Microsoft and IBM technology won't mix. Right?

I recently had a client who wanted to use Azure Active Directory for Single Sign On with an IBM Domino web application (which was hosted elsewhere) - and after some initial confusion it works like a charm!

Let me quickly walk you through the concept - and then get down to the nitty gritty details of configuring it for those of you who are in the same bind.

IBM Domino and Active Directory... Normally, we'd use ADFS to link those two. But in this case there WAS no on premises Active Directory to talk to. All identities were migrated to Office 365 (and therefore AzureAD). What to do? Basically the same as before: Use SAML. Simply replace ADFS by AzureAD.

Or at least, that's the idea. While this DOES work, the word "simply" was key here: it took quite some figuring out. To save you this trouble, here are our (high level) findings: 

• The "Sign On URL (optional)" field in AzureAD should be left empty
• The "Reply URL" (also called "Assertion Consumer Service", or ACS) has to be https://<domainname>/names.nsf?SAMLLogin (not the application’s path - but "names.nsf" followed by "?SAMLLogin")
• When importing the FederationMetadata.xml into IBM Domino, the "encryption certificate" stays empty. This is not an error.
• The script importing the XML file replaces the last part of the "Single Sign On URL" with "IdpInitiatedSignOn.aspx". This needs to be undone manually to read "/saml2" again

Okay, ready for giving this a roll? Then read on!

One of the challenges I had recently when migrating users from Exchange 2007 to Exchange Online (who had been migrated over from Lotus Notes before that) was that they had loads (and loads!) of proxyAddress entries. Every domain the company we integrated had ever owned was stuck onto those mailboxes - but we'd decided to only use a handful in Exchange Online.

When migrating the mailbox from on premise to Exchange Online, the migration failed with the message that the domains on the mailbox were not part of the list of Accepted Domains configured for Exchange Online. Obvously, we could do 2 things: Add all the domains to the Accepted Domains - or clean up the mailboxes. While it did seem like a daunting task, I opted for the latter.

In retrospect, it didn't turn out to be much work: I just wrote a Powershell script that does it for me. If you want to use it, just copy/paste the script below to a text file on your Exchange server, adjust the domain names and the mailbox database in which you want to search for mailboxes, save it with a PS1 extension and run it (NB: it will NOT run on Exchange 2013 without some tweaking as I needed it for Exchange 2007)

$MSOnline = "domain1,com,domain2.net,domain3.org"

Get-MailboxDatabase -Identity "<YOUR MAILBOX DB>" | Get-Mailbox | foreach {

#write-output $_.EmailAddresses.count
for ($i=0;$i -lt $_.EmailAddresses.Count; $i++)
{
$address = $_.EmailAddresses[$i]
$domain = $address.AddressString.toString().Split("@")[1]

if (!$MSOnline.Contains($domain) -AND $address.PrefixString -eq "SMTP" ) {
write-host "removing $address"
$_.EmailAddresses.RemoveAt($i)
$i = $i – 1
}
}
Set-Mailbox -Instance $_
#write-output $_.EmailAddresses.count
#Write-output "remaining: " $_.EmailAddresses
}