[UPDATED: April 14th, 2016:
Good news everyone! MSFT has released an optional update that resolves this issue:
I’ve written a quick Powershell script to get a full inventory of affected computers (deal with the output yourself).
Worth noting that this is clearly novel, but, as of this time, MSFT hasn’t released a patch, which is weird given that Bastille disclosed the vulnerabilities to them November 24th, 2015. The recommended solution (from Bastille) is to move to a wired keyboard. Nice! But aren’t those vulnerable as well?! Is Tom Cruise crawling in my ceiling tiles?!!1
Here are the details and links to attack code: https://www.bastille.net/affected-devices
Outlook caches the X500 address (aka LegacyExchangeDN attribute) of a Distribution Group object.
So, when you migrate a distribution group, remember to not only bind the SMTP address to the destination Distribution Group, but also the X500 address (available as the LegacyExchangeDN attribute value) of the old distribution group, as an additional Email address for the destination distribution group.
Forgot to grab that LegacyExchangeDN attribute value before removing the old distribution group? Don’t worry. Have someone with the cached entry in their Outlook send an email to the old distribution group, and they will get an NDR.
This NDR will contain something similar to the following:
IMCEAEX-_O=FIRST+20ORGANIZATION_OU=First+20Administrative+20Group_cn=Recipients_cnfirstname.lastname@example.org #550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##
You can create an X500 Email address from this information and add it as an Email address on the destination/new distribution group.
As described in KB2807779, simply take that string and perform the following:
- Replace any underscore character (_) with a slash character (/).
- Replace “+20” with a blank space.
- Replace “+28” with an opening parenthesis character.
- Replace “+29” with a closing parenthesis character.
- Delete the “IMCEAEX-” string.
- Delete the “@contoso.corp” string.
Note that any character is just ASCII encoded, so an underscore is +5F, etc.
In the above example’s X500 address would be:
/O=FIRST ORGANIZATION/OU=First Administrative Group/cn=Recipients/cn=olddistrogroup
You can assign this additional Email address (aka alias) to the distribution group through the distribution group properties Email Address tab in the Exchange Management Console (use Email type: “x500”, and the Email address as above), or via the `set-distributiongroup newdistrubiongroup -emailaddresses [list of email addresses]` powershell command. Note that you should use `get-distribitiongroup newdistributiongroup | select emailaddresses` to see the existing entries, then set-distributiongroup…` with the input including the existing entries.
Once the X500 address is bound to the new distribution group, re-test with the cached address and you should be good.
You’re neighborhood generic Windows Admin is here to talk about WSUS auto-approval policies.
Here is how WSUS “gets” updates:
1) a synchronization occurs in which WSUS fetches some info about available updates for the product classifications you’ve prescribed.
2) Updates are approved manually or by auto-approval policy.
3) Updates are downloaded by WSUS.
4) Updates are fetched by workstations.
When you adjust an auto-approval, but your classifications have already included a product, and the WSUS has already fetched info about the updates, your auto-approval policy will not affect these updates. As in, they will not be automatically set to “approved,” will not be downloaded by WSUS, and will not be available to your Windows Update clients. Why is this done? I have no idea. It seems like an option would be nice to retroactively approve updates according to current auto-approval policy (and I’m sure you can hack away at the WSUS SQL DB).
So, what do you do? For a few weeks, you’ll just have to slave away at manually approving updates.
I’ve yet to read it, but judging by the table of contents, it looks chock full of good stuff:
...provides the ability to explore and answer questions such as: • Who has Access to network share/ resource \\TreyResearch\Finance and what is their access type? • Who has “Read” access to C:\TreyResearch\Finance AND C:\TreyResearch\HR? • Who has “Explicit deny” access to \\TreyResearch\Finance? • What objects does user: Bobde, Nikhil have “Read” access to? • Does security group TreyResearch-Interns have access to C:\TreyResearch\Finance?
This tool consists of 2 installable components 1. Data Collector: Used for collecting data from 1 or more data servers. This needs to be installed on each data server from where data is collected. 2. Data Visualizer: Used for visualizing the data collected from 1 or more data servers (from step 1). This is installed locally on the Admin’s (or the person who has rights to view and analyze data collected) machine.
All of this lovely info has been taken from the doc included with the package.
I’ve posted this a little early, as I’ve yet to implement and/or test the application. It looks to be the solution to a challenge that can be very complex to solve.
Searching for “DFS-R last write restore from backup” on google so that I can cite some official documentation while explaining, I came across an old post of mine on the Microsoft TechNet Forums that appears to be useful.