Posts Tagged ‘microsoft’

Don’t get-mousejacked

March 4, 2016 Leave a comment

[UPDATED: April 14th, 2016:

Good news everyone! MSFT has released an optional update that resolves this issue:


This morning, my boy Bruce Schneier posted about Bastille’s February 23rd published attacks on various wireless mouse/keyboard dongles.

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:


Exchange distribution group migration… remember the Outlook cache

December 23, 2014 Leave a comment

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:

#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.

A quick note about WSUS auto-approval policies

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.


Paper: MSFT’s Best Practices for Securing Active Directory

June 6, 2013 Leave a comment

Software: Microsoft Research’s MACE

December 31, 2012 Leave a comment
Check out the page Using MACE to keep track of file share permissions, a guide to roll out MACE.


Management of Access Control in the Enterprise (MACE) is a piece of software that:

...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.

Quick Primer: DFS-R

June 13, 2012 Leave a comment

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.

Read more…

%d bloggers like this: