# Monday, 26 February 2007

It looks like the issue I've been having with calling AzMan via PowerShell via MMC have nothing to do with PowerShell, and is probably an AzMan issue.  I tried exactly the same scenario, but accessed a different path with my drive provider that ultimately makes a COM call to ADAM, rather than AzMan, and it worked just fine.  That makes me think it's something about the AzMan implementation. 

However, I still need to call my PowerShell drive provider from MMC, and that problem has been resolved, (many) thanks to Bruce Payette

Turns out that there's a way to get PowerShell to run in the caller's thread, rather than creating its own MTA thread.  This means that my PowerShell code will get called from MMC's STA thread directly, and the AzMan interfaces get created just fine.  Woohoo!

Previously, I was creating the Runspace and calling it thusly...

RunspaceConfiguration config = RunspaceConfiguration.Create();
PSSnapInException warning;
//load my drive provider
PSSnapInInfo info = config.AddPSSnapIn(snapInName, out warning); 
Runspace rs = RunspaceFactory.CreateRunspace(config);
rs.Open();
...
create Command object with right parameters
...
Collection<PSObject> results;
using (Pipeline pipeline = _runspace.CreatePipeline())
{
    pipeline.Commands.Add(command);
    results = pipeline.Invoke();
}

This wasn't working, I believe because MMC is calling this code on an STA thread, and PowerShell is creating its own MTA thread, which doesn't seem to be acceptible to AzMan (not sure why).

However, according to Bruce's suggestion, I changed it to look like this...

Runspace rs = RunspaceFactory.CreateRunspace();
rs.Open();
PSSnapInException warning;
//load my drive provider
rs.RunspaceConfiguration.AddPSSnapIn(snapinName, out warning);
Runspace.DefaultRunspace = rs;
EngineIntrinsics _exec = rs.SessionStateProxy.GetVariable("ExecutionContext") as EngineIntrinsics;
ScriptBlock sb = _exec.InvokeCommand.
    NewScriptBlock("my script block");
Collection<PSObject> results = sb.Invoke();

This causes the PowerShell call to happen on the caller's (MMC's) thread, and everyone is happy. 

Monday, 26 February 2007 11:09:26 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [2]  | 
# Thursday, 22 February 2007

Update:  OK this is even wierder.  If I call into the PowerShell Runspace from inside a WinForms app marked STAThread, but first I create my own MTA thread and use it to make the call to the Runsapce, everything works.  However, from within MMC, even if I create the MTA thread myself to call the Runsapace on, it fails with the same "Interface not registered" error.

 

 

Our plan is to build PowerShell Cmdlets and drive providers to expose our management interfaces, then layer an MMC interface on top of them to provide a GUI management tool. 

Yesterday, I ran into the first hitch in that plan...

My PowerShell drive provider makes use of the AzMan COM interfaces to deal with Operations, Roles, and Tasks.  That works great from within PowerShell, and it does all the stuff it needs to.  However, when I started running the PowerShell stuff through a Runspace inside of MMC, the AzMan calls started failing with "Interface not registered".  Hmm.  So, on a hunch, I tried the same PowerShell calls (again using a Runspace) inside a WinForms app.  Same problem.  Even though they work fine in PowerShell (which obviously makes me doubt that the interface isn't registered). 

On another hunch, I changed the COM threading model attribute on the WinForms app from [STAThread] to [MTAThread].  Everything worked just peachy.  Dang. 

Turns out that MMC always calls snap-ins on an STA thread, and for the life of my I can't find any way to change that behavior.  I still don't know why the problem manifests itself quite this way.

To further qualify the problem, I called the AzMan interfaces directly from within the WinForms app, and it worked in both STA and MTA threads.  So apparently it has something to do with launching the Runspace from an STA thread, and then making the COM calls from PowerShell (which uses an MTA thread). 

I'm hoping that I won't have to abandon the MMC -> PowerShell concept for this particular part of the product, but right now I'm not sure how to resolve this.

Thursday, 22 February 2007 12:57:24 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, 21 February 2007

Rhapsody (my online music provider of choice) has continued to make improvements to their online, browser based version of their music player.  The most recent addition is support for the "My Library" feature that's long been present in their desktop player.  You can add albums or songs to your library for future recall, rather than having to search for them again, and just like in the desktop client, it's portable across machines.

Since I've had nothing but trouble with their desktop client lately, this makes the online version a lot more attractive.  It works in Firefox, and supposedly even under Linux, which is pretty sweet.  $25 bucks a quarter, zillions of albums, and works anywhere there's a 'net connection.  Can't beat that.

Wednesday, 21 February 2007 10:42:43 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, 19 February 2007

I'm finally taking the time to get to know PowerShell, and I'm pretty much as impressed as I expected to be given the rave reviews from Scott and others. 

In rewriting our core platform, we're committed to exposing management operations through both PowerShell and MMC, so I've been building out some PS Cmdlets, and now a "drive provider" to make it easy for an end user to navigate through our authentication system.  In the end, the user will be able to "CD" into our authentication system, and navigate the available groups (ADAM) roles, and operations (both from AzMan) like they were directories and files in a file system. 

It's taken me a while to get my head around the PS drive provider model, but now that I (mostly) have, I totally get how flexible a model it is.  You can choose different levels of functionality to support, including adding new items to the tree, "cd"-ing into multiple levels of hierarchy, etc.  Once I grokked the stateless model used by the drive providers, it made sense as an easy way to expose hierarchical data to PS, in a way that's intuitive to users. 

Once that stuff is done, we'll layer an MMC interface on top of the PS Cmdlets, so we won't have to reinvent the wheel functionality wise. 

Very exciting times...

ADAM | AzMan | Work | PowerShell
Monday, 19 February 2007 11:06:24 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, 15 February 2007

I just finished a couple of pretty interesting books...

 


The Devil's Teeth: A True Story of Obsession and Survival Among America's Great White Sharks

The Devil's Teeth is all about a journalist who gets involved with the biologists studying great white sharks in the Farallones, islands about 20 miles due West of San Francisco.  It's an interesting portrait, not only of the harsh reality of life for a shark, but of the harsh reality of the people who live to study them.  Not an easy job.  Unfortunately, the author's obsession with the sharks leads to her violation of the rules of the study, which ultimately result in the lead biologist losing his job.  I notice that part gets downplayed significantly.  Other than that, it's a very well written account.

 


Adrift: Seventy-six Days Lost at Sea

 Adrift is about the truly remarkable adventure of Steven Callahan, who survived in an inflatable life raft for 76 days in the North Atlantic.  Only one other man is recorded as having survived at see that long solo.  Callahan's sailboat was sunk (he thinks by running into a whale) while only a few days out from the Canary Islands, headed for the Caribbean.  Using only the tools in his raft and survival kit, he manages to provide himself with enough food and water to make it all the way to Guadeloupe, where he was rescued by some fishermen.  Callahan showed some pretty amazing competence and ingenuity, which makes this a very interesting read.

Thursday, 15 February 2007 10:30:00 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, 13 February 2007

One obvious thing you might want to do with an authorization system is to get a list of all the operations a given user is granted access to.  This is particularly useful for building up UI elements such as navigation menus.  Nobody likes navigation links that result in Access Denied errors, so it's best to only include in your navigation hierarchy those pages a user can actually execute successfully. 

Here's an example of how to do this with ADAM and AzMan.  It's a little weird, since you have to switch back and forth between an operation's string name, and its integer ID, hence the lookup dictionaries. 

 

   1:  public string[] AvailableOperations(string userId)
   2:  {
   3:      IAuthenticationStore authenticate = AuthenticationStoreFactory.Create();
   4:      UserInfo userInfo = authenticate.LookupUser(userId);
   5:      IAzClientContext2 client = setupClientContext(userId, userInfo);
   6:   
   7:      try
   8:      {
   9:          Dictionary<string, int> opToId = 
  10:      new Dictionary<string, int>(azApp.Operations.Count);
  11:          Dictionary<int, string> idToOp =
  12:      new Dictionary<int, string>(azApp.Operations.Count);
  13:          foreach (IAzOperation op in azApp.Operations)
  14:          {
  15:              opToId.Add(op.Name, op.OperationID);
  16:              idToOp.Add(op.OperationID, op.Name);
  17:              Marshal.ReleaseComObject(op);
  18:          }
  19:   
  20:          List<string> availableOps = new List<string>();
  21:   
  22:          object[] scope = new object[] { (object)"" };
  23:   
  24:          object[] operations = new object[idToOp.Count];
  25:          int i = 0;
  26:          try
  27:          {
  28:              foreach (int opId in idToOp.Keys)
  29:              {
  30:                  operations[i] = (object)opId;
  31:                  i++;
  32:              }
  33:          }
  34:          catch (COMException ex)
  35:          {
  36:              throw new InvalidOperationException("Failed", ex);
  37:          }
  38:          object[] results = (object[])client.AccessCheck("User authentication", scope,
  39:               operations, null, null, null, null, null);
  40:   
  41:          for (int j = 0; j < results.Length; j++)
  42:          {
  43:              if ((int)results[j] == 0)
  44:              {
  45:                  availableOps.Add(idToOp[(int)operations[j]]);
  46:              }
  47:          }
  48:          return availableOps.ToArray();            
  49:      }
  50:      finally
  51:      {
  52:          Marshal.ReleaseComObject(client);
  53:      }
  54:   
  55:  }

I talked about the LookupUser and setupClientContext methods yesterday.  This method returns a handy list of all the operations that the given user can access.  In practice, you probably want to cache the results, although so far it seems to perform very well.  It might prove particularly valuable to cache the ID->Name and Name->ID lookup tables, as they aren't likely to change very often.

Tuesday, 13 February 2007 09:34:22 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, 12 February 2007

I'm working on an authentication and authorization solution using ADAM and AzMan, and starting to write the code to integrate the two.  For those who might be looking to do such a thing, here's an example.  This method takes two pieces of information, a user's ID (which in this case corresponds to a userPrincipalName in ADAM), and the name of the operation to check access to...

 

   1:  public bool CheckAccess(string operation, string userId)
   2:  {
   3:      log.Verbose("Starting CheckAccess");
   4:      bool result = false;
   5:      IAuthenticationStore authenticate = AuthenticationStoreFactory.Create();
   6:      UserInfo userInfo = authenticate.LookupUser(userId);
   7:      log.Verbose("LookupUser {0} succeeded", userId);
   8:      IAzClientContext2 client = setupClientContext(userId, userInfo);
   9:   
  10:      object[] scope = new object[] {(object)""};
  11:   
  12:      object[] operations = null;
  13:      try
  14:      {
  15:          IAzOperation op = azApp.OpenOperation(operation, null);
  16:          operations = new object[] { (Int32)op.OperationID };
  17:          Marshal.ReleaseComObject(op);
  18:      }
  19:      catch (COMException ex)
  20:      {
  21:          log.Error("No such operation: {0}", operation);
  22:          if (ex.ErrorCode == AzManConstants.INT_NO_SUCH_OBJECT)
  23:              throw new UnknownOperationException(operation);
  24:          else
  25:              throw;
  26:      }
  27:      object[] results = (object[])client.AccessCheck("User authentication", scope, 
  28:                      operations, null, null, null, null, null);
  29:      if ((int)results[0] == 0)
  30:      {
  31:          result = true;
  32:          log.Verbose("Access granted to {0} for user {1}", operation, userId);
  33:      }
  34:      else
  35:      {
  36:          log.Verbose("Access denied to {0} for user {1}", operation, userId);
  37:      }
  38:      Marshal.ReleaseComObject(client);
  39:      log.Verbose("Leaving CheckAccess");
  40:      return result;
  41:  }
 

There are a couple things here that need explaining.  The LookupUser method finds the specified user in ADAM by searching for the userPrincipalName using the DirectorySearcher class.  It returns a structure containing the user's SID, all of the SIDs for groups they belong to, and some other stuff specific to our application.  There's a great example of how to retrieve this info in the paper Developing Applications Using Windows Authorization Manager, available on MSDN. 

The other method of interest here is the setupClientContext method, which looks like this...

 

   1:  private IAzClientContext2 setupClientContext(string userId, UserInfo userInfo)
   2:  {
   3:      log.Verbose("Setting up client context");
   4:      IAzClientContext2 client = azApp.InitializeClientContext2(userId, null);
   5:      log.Verbose("User sid = {0}", userInfo.SecurityId);
   6:      object[] userSids = null;
   7:      if (userInfo.GroupIds != null)
   8:      {
   9:          userSids = new object[userInfo.GroupIds.Count + 1];
  10:          userSids[0] = userInfo.SecurityId;
  11:          int i = 1;
  12:          foreach (string sid in userInfo.GroupIds)
  13:          {
  14:              log.Verbose("Adding group sid {0}", sid);
  15:              userSids[i] = sid;
  16:              i++;
  17:          }
  18:      }
  19:      else
  20:      {
  21:          log.Verbose("No group IDs returned, using only user SID");
  22:          userSids = new object[1];
  23:          userSids[0] = (object)userInfo.SecurityId;
  24:      }
  25:      client.AddStringSids(userSids);
  26:      log.Verbose("Finished setting up client context");
  27:      return client;
  28:  }
 
 

This is the part that only works on Windows 2003 Server or Vista. On XP, the IAzClientContext2 interface is not available, and so you can't add the additional group SIDs to make this work.

The end result is that the user's role membership will be used by AzMan to determine whether or not the specified user can access the specified operation, and return a boolean value back to the caller.  Easy to use by the client, and as far as I can tell, pretty performant.

Monday, 12 February 2007 11:21:02 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  |