The proper way would have been to leave the project alone, notify the maintainers of problems if any turn up and remove the project from the .Net Foundation if the problems persist.
Of course from the issues that came up the last few days it seems that there is literally no point in joining the .Net Foundation and kicking a project out is essentially doing the maintainers a favor.
I don't understand your scenario. Microsoft isn't involved here. I mean Microsoft uses the WiX Toolset (my project) but they have never suggested forking it. I'm confused where you were going with this.
The proper "open-source-if-a-bit-dickish" way would be to do exactly what the .NET Foundation did here, but where the letter said "You will need to add this admin for compliance with our policies" that word policies would be studded with footnotes to policy pages, reams of meeting minutes, and archives of open mailing list discussions.
Apache and Eclipse and others all mandate that they control a lot of minutia of source control like what .NET Foundation seems to want to be doing with their GitHub Enterprise account, but their transparency policies mean all of the discussions of that are open and no one is surprised when changes happen.
So, the proper, open-source-if-a-bit-dickish way to go about this would have been...
1) Microsoft forks the primary git repository and declares theirs to be "Microsoft-blessed".
2) Microsoft puts a skeleton team in charge of maintaining the Microsoft-blessed version, but mostly they just pull the original maintainer's patches.
3) People slowly migrate to the Microsoft blessed version.
NOT: We flipped this hidden switch under the table and now your repository in GitHub is controlled by us.