unprotect a visio object

If you happen to be using the Office 2010 preview…And using Visio…And open a sheet on which you’ve protected objects…AND you need to undo the protection of those objects…

 

Then let me save you 20 minutes of looking around.  You have to go into the options (click the office logo button on the top left), and then add in the Developer tab to the ribbon.  The protection button is hidden in there.

Adventures of Exchange 2010 and AdminSDHolder

For those of you who haven’t heard by now, there have been many threads over the past few days around the setup of Exchange 2010, and how one of the things which it does is to modify AdminSDHolder ACL’s, and the associated security implications.

Far as I can tell, this was kicked off by this blog post, which gives a good description of what’s going on and what the fuss is about:  http://dloder.blogspot.com/2009/08/exchange-2010-rc1-and-adminsdholder.html

It didn’t take long for threads to spawn on the public forums, such as http://www.activedir.org/ListArchives/tabid/55/Default.aspx as well as several internal distribution lists.

While I won’t claim that inside Microsoft, the left hand and the right hand always know what each other is doing.  We are very security conscious and in general the product groups do go out of their way to try to do things “right”

In the meantime, who does this affect?  Well, technically Exchange 2010 is only supported for production by a small number of TAP partners.  Of course, MSIT is on that list, so you might be wondering – what do we think about it?

While it’s not an official “policy”, in general, when it comes to managing Microsoft’s internal directory, we’ve got a fairly basic principle: 

                   If you create it, it’s yours, if you don’t – leave it alone.

In this case, AdminSDHolder isn’t something that Exchange created or even ‘owns’, it’s a base AD function.  Because we know that also by policy, none of the accounts which are impacted by AdminSDHolder are mailbox enabled (and thus within the scope of Exchange), we went through and removed the ACE’s from AdminSDHolder.  Does this mean that Exchange RBAC won’t be able to touch those objects?  Yup, but that’s by design of our security model.  We require separate (in our case, smartcard required) administrator accounts for all elevated permission users, and those accounts aren’t allowed to have mailboxes.

I won’t claim to know what’s going to happen in the future with Exchange 2010, but this is how we’re approaching it internally (and why).

Federation Services and Direct Access

Now here’s an interesting combination.  What do you do when you have a service which has both an internal and internet facing components, with different behavior for each, and then you deploy Direct Access?

Quick aside:  For those not aware, Direct Access is a feature which allows domain joined Win7 laptops to behave as though they were on the corporate network and have full access to internal resources, regardless of where they are.

The important detail here, is that one of the control mechanisms is an idea of split DNS.  Internal domains are flagged as such, so that clients route that traffic internally, and everything else is considered “internet”.

So the question is, if you have your ADFS servers deployed in a unique namespace (we use *.sts.microsoft.com), then do you call that an internal namespace or an external one?  I’m not sure of the right answer at this point, but I’ve been bouncing around and just recently (this past week) requested a change.

Another quick note:  Remember, that we’ve got ADFS deployed so that users who are on corpnet get integrated authentication – no prompts – when they hit the ADFS servers.  Users on the internet get forms based auth, and have to enter credentials

So for your DA users, what kind of experience should they have?  Initially, when we first started rolling out DA, it made sense to me that DA enabled clients on the internet should have the “corpnet” experience.  In other words, even though I’m at home, I should still get integrated authentication. 

Just recently though, we ran into some issues where DA enabled users would be in situations (client issues, behind firewalls, etc…) where they were able to traverse the internet but were not able to get the DA connection back to corpnet.  In these cases, users were actually able to hit the internet based, federated resource.  But because the client thought that the ADFS servers were internal (and DA wasn’t working), they were failing to authenticate.  They could see the app, just not get into it.

So we had the DNS policy on DA clients changed, and now our DA clients believe that the ADFS servers are external.  This takes us back to our pre-DA behavior, where clients physically on corpnet (DA or not) will get integrated auth, but clients on the internet (DA or not) will always get FBA.  At least with FBA though, they can get access to the resources.

The change hasn’t been in place long enough, and we don’t have a critical mass of users on our DA pilot yet, so I haven’t heard the rumblings about the change to see whether anyone has noticed. Yet.  I’m sure this won’t be the last time we need to think about ADFS and DA, but all other things considered, right now I think the best thing to do is keep the 2 separate.

Enabling Logging in ADFS

* This post applies to the Beta 2 release of ADFS and may or may not apply to the final product *

 

In ADFSv1, the logging was enabled in the UI.  You checked the checkboxes, set a log file path, and left it alone.  In fact, in the MSIT deployment, we were in the habit of running with full logging enabled all the time, letting them wrap on their own, and accepting the imperceptable performance hit because we didn’t have that much load.  The latest version of ADFS is a different beast though.  In addition to being a much richer product from a feature/functionality perspective, there is much more logging which can be enabled for an administrator to use in troubleshooting.

To enable logging, start by opening the web.config file (located in the c:\inetpub\IdentityServer\WSFederationPassive.Web directory) and scrolling towards the bottom.  You’ll see a section which looks like this:

<system.diagnostics>
  <sources>
    <!– To enable tracing on a particular component, uncomment the desired section below. Then uncomment
         the shared listener named "xml" and the Microsoft.IdentityServer.SourceSwitch in the switches element.
     –>
    <!– Federation passive related tracing
    <source name="Microsoft.IdentityServer.Shared.WSFederation" switchName="Microsoft.IdentityServer.SourceSwitch" switchType="System.Diagnostics.SourceSwitch" >
      <listeners>
        <add name="xml" />
      </listeners>
    </source> –>
  </sources>

  <!– This is the shared listener for all of the tracing.  All of the sources write to this listener.
       If you want a more fine-grained listener, one can be added to the listeners element in each source above, which
       can then output to different files if desired. After uncommenting this, put the absolute path of the trace file
       ie c:\temp\TraceData.svclog.  Be sure that the identity of the service can write to the file and directory –>
  <sharedListeners>
    <!– <add name="xml" type="System.Diagnostics.XmlWriterTraceListener" initializeData="" /> –>
  </sharedListeners>
  <switches>
    <!– Uncomment this switch to use with your trace sources.  You can add more and configure
         them per source by editing the value attribute.  For each source above, there is a switchName
         attribute that links the source to a switch in this collection.  You can use the same switch
         with every source, or you can create a different switch for source for more control if thats
         desired.
    <add name="Microsoft.IdentityServer.SourceSwitch" value="Information" />
    –>
  </switches>
  <trace autoflush="true" ></trace>
</system.diagnostics>

To enable tracing, you want to do a few things (basically following the instructions in this section):

1)  Uncomment the tracing that you’re looking for – being careful to keep the comments/instructions commented out (yeah, I’ve blown that at least twice)

2)  Uncomment the <sharedListeners> tag, and if you like, add a path to the initializeData field.  We usually use d:\logs

2a)  Make sure that the account ADFS is running under, either NETWORK SERVICE or a system account, has write access to that directory (yeah, blown that one before too)

3) Uncomment the <add name= tag, and we usually change the value to “Verbose”

At this point, you should see the log file, something like TraceData.svclog.  If you open it up in notepad.exe, you’ll find a horrendous jumble of unformatted XML which is nearly indecipherable by humans.  So I highly suggest you use a utility, such as svcTraceViewer.exe, which is available when you install Visual Studio 2008 [1], and which provides a much, MUCH better experience parsing the logs.

Good luck, and happy federating!

~B

 

 

[1]  Personally, I’m not a huge fan of needing a utility that’s only available in VS2008 to read these things, because as an IT admin I don’t normally need developer tools like Visual Studio.  I would love to post a copy of it for those that don’t have access/ability to get it from a VS2008 install, but I can’t get a definitive answer on redistribution rules, and as an MS employee I’m not risking my job over it…  I’m happy to host any comments from the readers who want to help others with utilities for reading these things.

 

Oh yeah, one more thing…  don’t leave the logging turned on all the time.  Just enable it when you need it, and then disable it.  Came back to a server a few days later to find a 1.5GB log file that was just growing and growing…

Facebook is going to allow user names on June 12th

If you use Facebook, you might notice a box when you log in that says beginning June 12th, Facebook will allow registration of user names.  If you “click here” to have them send more info, you’ll receive this in your registered email inbox:

Starting on Friday, June 12th, at 9:01pm, you’ll be able to choose a username for your Facebook account to easily direct friends, family, and coworkers to your profile.

To select your username, visit the link below after 9:01pm on June 12th:

http://www.facebook.com/username/

To learn more about usernames, visit the Help Center:

http://www.facebook.com/help.php?page=896

Thanks,

The Facebook Team

 

So what does this mean?  Well, for one thing, it means that if you’ve got a common name – or – if your like me, and you KNOW that there’s someone else on Facebook with the same name (since he and I are actually friends on Facebook), then it means that you want to “claim” your user name as soon as the application opens.

I did seen an interesting article here http://www.huffingtonpost.com/jonathan-handel/trademark-protection-and_b_213756.html about trademark registrations and how Facebook intends to handle squatters.  So don’t bother trying to register facebook.com/McDonalds, you won’t have it for long if you do. 

I like the very last part of that article though.  There is already a recommendation for what to do, if somebody maliciously claims not only your trademark, but also fills out the forms sufficiently such that you (the legitimate owner of the trademark) actually can’t use the automation to claim it back.

Oh how much fun Identity Management can be

Congratulations!

Congratulations to all of the MSIT and Product Group members who got us this far (and let’s not forget the users!)

Random port? I think not…

6 months ago – We’re in the process of federating with a new partner, and the link they send us to their federation server looked something like this:  https://federation.foo.com:9031/blah – notice the port 9031?

This seemed a little random, but not completely unusual since people tend to grab an available port when they want to host a test/beta site.

With a bit of troubleshooting, working with our proxy server team, etc… figured out that our proxy servers only allow SSL connectivity out to port 443, so the federation was broken.  A bit of back and forth with the partner, they moved to the standard SSL port, and everything worked great.

4 months ago – We’re in the process of federating with a new partner, and the link they send us to their federation server looked something like this:  https://federation.contoso.com:9031/blah

Us:  Hey, we’ve seen this before – we can only connect to port 443 for SSL sites, can you move your federation server to the standard port?
Reply:  Sure, done – check it now

And there was much rejoicing. yeah.

Rinse and repeat this a half a dozen times over the past few months, and we’re getting pretty good at recognizing the issue.  And since about 60% of our federation partners are using STS’s which are not ADFS/Geneva, this scenario is even more common.

The other day, while dancing this dance yet again, we did notice one thing though – It’s not a random port – it’s ALWAYS port 9031.  Not only that, but looking back, it’s always with partners who are using Ping Federate server.

A quick search for “9031” on the Ping website, finds that a lot of their sample code uses port 9031. 

Ah ha!  Now I get it.  It wasn’t random after all, but rather re-using the sample code to set up services.  Which is a great, so now we know that when we’re federating with a partner that’s using Ping Federate – be on the lookout for port 9031.

SYSVOL Replication Migration Guide: FRS to DFS Replication

Web pages on Microsoft TechNet: http://go.microsoft.com/fwlink/?LinkId=139749

A Microsoft Word (.doc) document on the Microsoft Download Center: http://go.microsoft.com/fwlink/?LinkId=150375

AD in the Perimeter Network

A new whitepaper has been published providing the guidance you need to deploy Active Directory, and specifically RODC’s, in a “Perimeter Network” (the network segment formerly known as DMZ).

I know that a lot of folks have come to me, asking for help/guidance on putting RODC’s into the DMZ rather than putting full DC’s or having a separate forest.  This should provide the information you need to keep safe, secure, and most of all…functional.

Some of the topics include:
•         Security considerations and configurations for RODCs in the DMZ 
•         Network configurations for RODCs
•         Application compatibility with RODCs in the DMZ
•         Step by step instructions and a sample script to help perform domain join using RODCs

http://technet.microsoft.com/en-us/library/dd728034.aspx

 

Brandon pointed out to me, that the doc is nice, but having a downloadable version would be much nicer.  We fired off a quick mail, and there will be a downloadable version of the document in the download center in the near future.

Happy Birthday Redmond.Corp.Microsoft.Com

10 years ago, Microsoft’s largest internal domain was upgraded to Windows 2000 becoming the first production Active Directory, and it’s still going strong…

Dn: DC=redmond,DC=corp,DC=microsoft,DC=com
   whenCreated: 4/9/1999 7:49:12 PM Pacific Daylight Time;