So apparently members of the Protected Users group can't edit Wired 802.1x group policy. Wireless 802.1x? Sure. Every other group policy setting? Yup. Wired 802.1x? Can't load the snapin.
Got to love the consistency there, Microsoft.
— Adam 'Election Fever' Beardwood (@the_spad) February 12, 2018
If you’ve ever looked at configuring the Exchange Availability Service to allow cross-forest free/busy lookups you’ve probably realised that the documentation surrounding it is awful.
Get-MailboxServer | Add-ADPermission -Accessrights Extendedright -Extendedrights "ms-Exch-EPI-Token-Serialization" -User "<Remote Forest Domain>\Exchange servers"
From here, doesn’t even work for a start, because Get-MailboxServer doesn’t return the correct identity objects for Add-ADPermission. Once you’ve worked out how to get that sorted and done your
Add-AvailabilityAddressSpace -Forestname ContosoForest.com -AccessMethod PerUserFB -UseServiceAccount:$true
You’re probably thinking that you’re done, but it usually isn’t that simple. For a start if the namespaces in either forest are even a little bit complicated or you’re using a custom target address space then you’re in for some autodiscover fun – just because autodiscover works in its home forest doesn’t mean it will from your trusted partner. Before you even start, make sure your Exchange certificates are trusted by the target servers; don’t assume that just because they’re from a public CA that they will be, you never know what weird stuff has been done to the servers if you didn’t build them and they’re not under your control. Obviously if you can you should export the SCP to the partner forest with
Export-AutodiscoverConfig -TargetForestDomainController "dc.contoso.com" -TargetForestCredential (Get-Credential) -MultipleExchangeDeployments $true
But even then there are a few things that aren’t clearly documented and might trip you up; for example, you need Outlook Anywhere enabled for the Availability Service to function, which isn’t a given if you’re still running Exchange 2010 or 2007 in one or both forests. Furthermore, if one or both parties are running Exchange 2013 or 2016 and you’re not using the SCP for autodiscover then you’ll probably find the free/busy lookups fail because:
the availability service sends an Autodiscover request by using an automatically generated SMTP address for the anchor mailbox. This SMTP address that is used is [email protected]Availability_Address_Space_domain.
However, the Exchange Server 2013 Client Access server in the attendee forest cannot locate a mailbox for this email address and responds with a 404 status.
That’s right, Exchange uses an essentially random (and as far as I can tell only documented in that KB article) SMTP address for it’s autodiscover query which is rejected by the target server because, obviously, it doesn’t exist. The “fix”? Slap that SMTP address onto any old mailbox so the server returns a valid autodiscover response.
Hopefully this post will be of some help to anyone struggling to get the availability service working in their environment, I spent 2 weeks dicking about with Microsoft support trying to understand how it operates so that with any luck you won’t have to.
You may remember my post a while back about issues with applying Exchange 2010 SP1 in situations where you were using Group Policy to control Powershell Execution policies. Specifically, this issue occurs because the Group Policy setting uses the WMI service to enforce the Execution Policy and as part of the Exchange install/upgrade process, the WMI service is stopped, causing the Execution Policy to revert to Restricted and the following error to pop up and the install to fail:
The following error was generated when "$error.Clear();
& $RoleBinPath\ServiceControl.ps1 EnableServices Critical
" was run: "AuthorizationManager check failed.".
Well it turns out that this still applies with Exchange 2010 SP2 in exactly the same fashion.
The (well, A) relevant KB article is here but the “workaround” is a bit half-assed to be honest and you’re much better off just disabling the associated Group Policy setting and configuring the Execution Policy locally (with
set-executionpolicy) to either AllSigned,RemoteSigned or Unrestricted for the duration of the upgrade.
Why Microsoft cannot add installer logic to check for this possibility, especially given how long it’s been a potential problem, is beyond me but then I’m not an Exchange developer.
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 188.8.131.52/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.
OK, so Adobe’s Flash Player downloads have always been crappy; half the time you can’t find the download for non-IE browsers and the other half of the time you’re forced to use the Adobe Download Manager to get it, but I think they’ve managed to outdo themselves now.
If you go to download Flash Player from the Adobe website (http://get.adobe.com/flashplayer) and you’re not running IE, you’re presented with some drop-down boxes asking you to pick your OS and Browser (IE or Other). If you pick “Windows 7 (64-bit)” – as well you might if that’s the OS you’re running – then you get given the 64-bit version of Flash Player, which won’t work for 95% of users and won’t be clear why, so you have to pick “Windows 7 (32-bit)”, obviously.
You then download the installer and run it, at the end of which, the installer deletes itself, presumably because they realise that it’s such an insecure piece of crap that by the time you come to install it on a 2nd machine 3 minutes later, there’s already a new version out.
To make matters worse, the MSI distribution points (such as http://www.adobe.com/go/full_flashplayer_win_msi) are still Flash 10.x instead of 11 and the old http://fpdownload.adobe.com/get/flashplayer/current/ links now 404.
I’m already trying to get rid of Flash Player, I’m using Youtube’s HTML5 trial and making use of alternative options where ever possible, but it’s like Adobe is actively trying to help me stop using it.
Fuck You Adobe.
Given that my blog is relatively low traffic, it’s remarkable just how many spam comments and hacking attempts I log daily. A good 50% or more of all the spam comments I get originate from the same place: Ubiquity Server Solutions/Nobis Technology Group, who share a couple of overlapping IP ranges and are somewhat notorious if my brief Googling is anything to go by. I’m a big fan of Hanlon’s Razor, but in this case I’m really not sure either way.
So, as of today, their entire ranges are blacklisted:
Deny from 184.108.40.206/22 #Ubiquity Server Solutions Deny from 220.127.116.11/16 #Nobis Technology Group
I don’t like having to block entire /16 ranges because I know there are bound to be false positives in there somewhere, but frankly it’s the only way to make things manageable right now.
I expect to see my error.log grow exponentially over the next few days.
Update: And another range of theirs that was still spamming me…
Deny from 18.104.22.168/16 #Nobis Technology Group
Update: And yet another…
Deny from 22.214.171.124/16 #Nobis Technology Group
Update: Guess who…
Deny from 126.96.36.199/17 #Nobis Technology Group
Update: Right, let’s make this simple; courtesy of ARIN’s WHOIS Database
#All Nobis/Ubiquity ARIN Netblocks Deny from 188.8.131.52/20 Deny from 184.108.40.206/23 Deny from 220.127.116.11/24 Deny from 18.104.22.168/17 Deny from 22.214.171.124/22 Deny from 126.96.36.199/18 Deny from 188.8.131.52/16 Deny from 184.108.40.206/16 Deny from 220.127.116.11/21 Deny from 18.104.22.168/16 Deny from 22.214.171.124/24 Deny from 126.96.36.199/23 Deny from 188.8.131.52/23 Deny from 184.108.40.206/24 Deny from 220.127.116.11/21 Deny from 18.104.22.168/23 Deny from 22.214.171.124/24 Deny from 126.96.36.199/23 Deny from 188.8.131.52/20 Deny from 184.108.40.206/24 Deny from 220.127.116.11/23 Deny from 18.104.22.168/17
Update: My complete comment spam blocklist is now available here.
- Who has 1,450 login scripts (For 3,500 users at that)?
- Who puts account passwords in the account’s description field? (for anyone who doesn’t know why this is appallingly bad, try this PowerShell as a regular domain user from a box with the Win7/2008R2 RSAT tools installed:
ipmo activedirectory;get-aduser -filter * -Properties description, other scripting languages are available)
- Who doesn’t use Domain Admins for their domain administrators and instead uses Account Operators, Administrators, Network Configuration Operators, Remote Desktop Users & Server Operators? (Not for granular permissions, all of them as a replacement for Domain Admins membership)
- Who leaves 5,500 computer accounts, including servers, in the Computers container in AD? (ProTip: You can’t link GPOs to the “Computers” container in AD)
- Who doesn’t have any actual DHCP servers in their Authorised DHCP Servers list? (Not even sure how you manage this one)
This isn’t just bad practice, this is years of dedicated training and substantial investment in bad practice…
I’m going to go curl up in a corner and cry for a while now.
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.
Well, the BBC iPlayer for Android has been released and I’m really disappointed.
Before the app I could go to the iPlayer website on my phone and stream recorded TV and Radio programs over 3G or Wi-Fi; no Live streaming, but otherwise pretty good.
With the app, however, I can’t stream anything unless I’m on a Wi-Fi connection and as far as I can see there’s no way to override it, so the fact that they now offer live streams is all but worthless as if I’m somewhere with Wi-Fi I’m usually somewhere with a TV or Radio. What’s even worse is that they’ve now applied the same fucking policy to the mobile version of the iPlayer website too, so I can’t even stream *that* over 3G any more.
Why have they done it? No idea, but it’s bloody stupid. By all means make it default to Wi-Fi only to stop all the idiots complaining when they stream the entire Eastenders back catalogue over 3G and run up for £3,000 phone bill, but I’m not one of those idiots; I want live 3G streaming and at the very least I want my recorded 3G streaming back. I can only imagine that the mobile networks threatened to block all iPlayer traffic if the BBC released their app with 3G support, because we all know that’s easier than actually upgrading your networks to support demand.
Oh, and it can’t run in the background either, or if your phone switches off the screen.
It’s been removed from my phone after a grand total of 8 minutes. Not happy.
Update: According to the FAQ here “[they] are working to make the service available on 3G networks in a future release of the BBC iPlayer Android App.” So that’s all OK then…
Update: This turned out to be a Nagios-related powershell script running against Exchange that was being launched by a service running as LocalSystem, which didn’t have permissions to perform various tasks within Exchange. As soon as we stopped running the script the errors went away. Still no idea why the errors were popping up on servers in the Org that weren’t referenced by the task, but that’s Exchange for you.
Right, I’m throwing this out on the tiny off-chance that anyone has come across it and knows of a solution, because so far, Microsoft support haven’t and don’t.
Frequent entries in the Application logs of all Exchange 2010 Servers as follows:
(Process w3wp.exe, PID <PID>) “RBAC authorization returns Access Denied for user <Mailbox Server Computer Account>. Reason: No role assignments associated with the specified user were found on Domain Controller <Domain Controller FQDN>”
1) Everything in <> has obviously been changed by me to remove details of my internal infrastructure, the actual errors contain real PID, account and server values. In all cases, the computer account is that of the Mailbox server, even though the error shows up on Mailbox, CAS and UM servers.
2) This is not, I repeat, not the same issue as you’ll find all over Google with a very similar error message that features a user account rather than a computer account. That one is usually caused by people not setting up permissions for their administrators properly in the ECP or broken permissions inheritance on accounts.
3) This error has survived a complete rebuild (OS and Exchange) of the Mailbox server, a re-running of the domain/forest prep tools and a couple of weeks examination by Microsoft Support. We’re currently looking at rebuilding all the other 2010 servers to see if it survives that too.
Any suggestions will be gratefully accepted.