# Monday, 28 July 2008
I spent quite a while working with ADAM (Active Directory Application Mode) in Windows 2003 Server / XP on a previous project.  It's a great way to incorporate an LDAP directory into your application without requiring a full-blown AD installation, or domain memberships.  The Windows 2008 Server version has been renamed AD LDS (Lightweight Directory Services), which is a much better name.  LDS incorporates several improvements that make it even more attractive, including some very nice performance increases.   Bart De Smet has a very nice guide to installing LDS on 2008 Server and setting up a useful configuration.  Check it out if you've used ADAM and/or have any interested in LDAP. 

Monday, 28 July 2008 12:54:31 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  | 
# Thursday, 26 April 2007

Back in February, I mentioned that I was having problems testing our AzMan code on developer machines running Window XP instead of Windows 2003 server.  This was because the 2003 Server version of the AzMan interfaces weren't present on XP.  To deal with the issue, we actually put some code in our unit tests that reported success if running on XP when the error was encountered, so that everyone could have a successful build.  Drag.

Anyway, it turns out I wasn't the only one having this problem.  Helpful reader Jose M. Aragon says

We are trying to get AzMan into our authorization architecture, and were able to do it nicely, as soon as the development was done on Windows Server 2003. But, when we tried to use IAzClientContext2.GetAssignedScopesPage on a developers machine running XP sp2 it fails miserably with a type initialization. Searching on help, I found your entry. so we started to circumvent the problem by programming our own "GetAssignedScopes" method.

Meanwhile, on another XP workstation, the problem was not occurring. So, it turns out the difference resides in what was the Server 2003 admin pack package installed on every XP machine..

adminpak.exe sized 12.537KB on 24 Jan 2007 : Does NOT include IAzClientContext2 on azroles.dll

WindowsServer2003-KB304718-AdministrationToolsPack.exe sized 13.175KB on 13 March 2007 : allows using IAzClientContext2 on XP

It seems the two files where downloaded from microsoft.com/downloads, but the one on Server2K3 SP1 is the most recent AdminPak.

I uninstalled my original version of the Admin Pack on my XP-running laptop, installed the new one, and now all of our tests succeed without the hack!

Thanks Jose!

Thursday, 26 April 2007 13:02:04 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, 17 April 2007

I've been wrestling for a while with how to deal with the fact that AzMan doesn't natively have a concept of denials.  I'd convinced myself that you could structure a hierarchy of grants such that you wouldn't really need an explicit denial, but I got a use case last week that proved that it really is necessary (without doing something REALLY horrible). 
I started with some suggesting from Cam, and modified it a bit into something that I think will work going forward.
The basic idea is that for every operation we want to add grants for, e.g. "GetAccounts", we also add a hidden operation called "!GetAccounts".  To keep them separated, we also offset their AzMan operation IDs by some arbitrary constant, say 100,000.  They when we do access checks, we actually have to call IAzClientContext.AccessCheck twice, once for the grant operations and once for the deny operations.  The results get evaluated such that we only grant access for an operation if the access check succeeds for the "grant" operation, AND doesn't succeed for the "deny" operation. 
 
WindowsIdentity identity = WindowsIdentity.GetCurrent();
 
IAzClientContext client = app.InitializeClientContextFromToken((ulong)identity.Token.ToInt64(), null);
object[] scopes = new object[] { (object)"" };
 
object[] grantOps = new object[] { (object)1, (object)2, (object)3, (object)4};
object[] denyOps = new object[] { (object)100001, (object)100002, 
     (object)100003, (object)100004 };
 
 
object[] grantResults = (object[])client.AccessCheck("check for grant", 
     scopes, grantOps, null, null, null, null, null);
object[] denyResults = (object[])client.AccessCheck("check for deny", 
     scopes, denyOps, null, null, null, null, null);
 
for (int i = 0; i < grantResults.Length; i++)
{
       if(((int)grantResults[i] == 0) && ((int)denyResults[i] != 0))
            Console.WriteLine("Grant");
       else
            Console.WriteLine("Deny");
}

We'll hide all the details in the administration tool, so that all the user will see is radio buttons for Grant and Deny for each operations.

I'm pretty happy with this for a number of reasons

  • it gives us the functionality we need
  • it's easy to understand (no coder should have a hard time figuring out what "!GetAccounts" means)
  • all of the logic is localized into the admin tool and the CheckAccess method, so the interface to the client doesn't change
  • it's not too much additional semantics layered on top of AzMan, and we take full advantage of AzMan's performance this way
Tuesday, 17 April 2007 15:44:12 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [3]  | 
# Thursday, 05 April 2007

Donovan posted a link to the latest Channel 9 screencast on AzMan, in which Keith Brown talks about some of the new features coming up in the Longhorn Server version of AzMan.  It's a good video, and very encouraging to me, because it looks like the things the AzMan team has added for Longhorn are exactly the things I would have wanted. 

The programmatic interface is much simplified (thank you) and there's a new plugin model for the admin tool which allows you to work with custom principles such as ADAM principals from within the AzMan MMC snapin. 

Another interesting feature calls BizRule groups allows you to define ad hoc groups defined by script, which can then be associated with roles at runtime.  The example in the video created a group consisting of the current user's direct manager, and then assigning that group with an expense approver group.  This is a cool idea, but I'm reluctant to go back to defining application logic in VB script.  The one thing I really wish the team had done for Longhorn would be to create a managed interface for AzMan, and let us get away from COM (finally).  Since I'm writing the rest of my application in C#, I don't really want to have to maintain and deploy a bunch of COM based scripting files.  I'm not too concerned about the "COM overhead" involved with calling AzMan interfaces, but the scripting part is lame.

I'm looking forward to testing some of the new features, and trying out the performance improvements.

Thursday, 05 April 2007 10:32:08 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, 04 April 2007

Since there's not way to manage an explicit "Deny" in AzMan like there is with ACL's, that has some influence on the way in which we will have to define roles.  Let's say I have a group hierarchy like this...

  • Ray's Bakery
    • Admins
    • Bill Payers
    • Corporate Headquarters
      • Finance
      • Payroll

If we have the ability to deny, we might give rights to all operations to the top level "Ray's Bakery", and then deny rights to "Payroll" for example that we don't want that group to have, but are OK for "Finance".  It's relatively easy to understand, and has the advantage of being not very much work. 

Because of the way AzMan works, however, we have to work from the top of the hierarchy down, going from most restrictive to least restrictive.  In other words, we can only assign rights to the "Ray's Bakery" group that we want ALL users to have, then grant additional rights as we go down the tree.  We might want everyone in Finance and Payroll to be able to see balances, so those rights could be assigned at the "Corporate HQ" level, while rights to transfer money from one corporate account to another might be granted only to Finance, and rights to wire transfers only to Payroll.  This should also be pretty easy to understand, but it does require a bit more thinking about.  I think a good test tool will help make it clear to users who has what rights, so it shouldn't be too hard to follow. 

For the sake of clearing up any implementation details, what I'm really describing are hierarchical groups in ADAM, which are associated with AzMan roles, so when I say "assign rights at the Finance level", I mean that the group SID for the Finance group in ADAM will be associated with an AzMan role called something like RaysBakeryFinance, which is in turn associated with the operations or tasks that comprise wire transfers. 

Wednesday, 04 April 2007 13:51:28 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [3]  | 
# Thursday, 15 March 2007

Donovan Follette, ADAM/AzMan/Identity Evangelist at Microsoft, has posted a set of links to some videos, whitepapers, and case studies on using AzMan.  Not only are these great resources, but it's great to see Donovan working to make sure that AzMan doesn't stay the "best kept secret" in Windows 2003 Server. 

One of the big questions we've had around using AzMan has been "is anyone actually using this thing?", so it's very cool to get our hands on some real case studies to answer that question in the affirmative.

Thanks Donovan!

Thursday, 15 March 2007 13:57:36 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 

I'm just starting to look into the feasibility of implementing complex constraints in the world of AzMan.  I've already discovered how easy it is to create simple "accessibility" constraints (i.e. can user x execute operation y), but now we need a solution for what we think of as "parameterized" constraints, like can user x execute the transfer operation if the total amount user x wants to transfer is $y.

AzMan certainly provides the capability, in the for of "BizRules", which are scripts that can be attached to roles and other objects to perform exactly this kind of evaluation.  When your application calls CheckAccess, it can pass a set of parameters to evaluate, as well as additional objects, etc.  I have two main concerns about this that I'm going to spend the next week or so evaluating...

  1. Is this going to give us the performance we need?
  2. Is the interface too cumbersome?

Both of those concerns stem from the fact that the only interface currently provided to AzMan is COM based, which means that I'm forced to write my scripts in VBScript of JScript, and I have to pass COM objects (or at least COMVisible objects) for all my parameters at evaluation time.  That means potentially some extra marshalling overhead, although I think there are ways around that.  It also makes the interface to CheckAccess a bit clunky.

I guess I'll find out...

Thursday, 15 March 2007 13:21:44 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [3]  | 
# 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]  | 
# 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]  | 
# Wednesday, 24 January 2007

I'll post some code later on, but I wanted to make some quick points about integrating ADAM and AzMan.  I'm in the midst of building an authentication/authorization system using the two technologies together, and have some across some stumbling blocks.  There's not much documentation, particularly around AzMan, and the COM interfaces for AzMan can be a bit cumbersome.

  • Storing users in ADAM and authorizing them using ADAM requires Windows 2003 Server or Vista.  There's no decent way to make this work on Windows XP.  The necessary AzMan interface, IAzClientContext2, doesn't exist on XP.  It's required for using a collection of user and group SIDs from ADAM to do access checks against AzMan.  I'll post some code later...
    • IAzClientContext2 is also available on Vista, so Vista is also a viable dev platform.
  • There are some confusing interactions between the AzMan UI and the programmatic API.  If you create a Role in the AzMan UI, but don't create a RoleAssignment, the programmatic call to IAzApplication2.OpenRole will fail.  If you create the role assignment, but don't actually assign any users or groups to it, OpenRole succeeds.  Conversely, if you call the programmatic IAzApplication2.CreateRole method and assign operations and users to the role in code, the RoleAssignment shows up in the UI, but not the Role itself. 
  • If you assign an ADAM user to be a member of an AzMan group, it won't show up in the AzMan UI, but if you assign them directly to a Role, the ADAM user's SID will show up (as "unknown SID") under the RoleAssignment.  Either way, the call to AccessCheck works correctly.
  • You must pass the complete list of group SIDs from ADAM, but fetching the user's "tokenGroups" property.  Don't use "memberOf" because it doesn't take into account groups which belong to other groups.

More detail to come...

Wednesday, 24 January 2007 10:08:12 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [2]  | 
# Monday, 11 December 2006

One of the (many) issues I encountered in creating a duplex http binding with IssuedToken security (details here) was that when using a duplex contract, the client has to open a "server" of its own to receive the callbacks from the "server" part of the contract.  Unfortunately, there are a couple of fairly critical settings that you'd want to change for that client side "server" that aren't exposed via the configuration system, and have to be changed via code.

One that was really causing me problems was that for each duplex channel I opened up (and for one of our web apps, that might be 2-3 per ASP.NET page request) I had to provide a unique BaseClientAddress for each channel, which quickly ran into problems with opening too many ports (a security hassle) and insuring uniqueness of the URI's (a programming hassle).  Turns out that you can ask WCF to create unique addresses for you, specific to your chosen transport in their method of uniqueness.  However, you make that request by setting the ListenUri and ListenUriMode properties on the ServiceEndpoint (or the BindingContext).  For the client-side "server" part of a duplex contract, that turns out to be one of those settings that isn't exposed via configuration (or much of anything else, either). 

Luckily, I found an answer in the good works of Nicholas Allen (yet again).  He mentioned that you could set such a property on the BindingContext for the client side of a duplex contract.  Not only that, but Mike Taulty was good enough to post a sample of said solution. 

There's a great summary of the solution here, but to summarize even more briefly, you have to create your own BindingElement, and inject it into the binding stack so that you can grab the BindingContext as it hastens past.  Now I'm setting the ListenUri base address on a specific port, and asking WCF to do the rest by unique-ifying the URI.  Not only do I not have to keep track of them myself, but I can easily control which ports are being used on the client side, which makes both IT and Security wonks really happy.

Monday, 11 December 2006 11:02:53 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, 17 October 2006

After some minor setbacks, I’m finally getting going with ADAM, and amazed at how well it works (once you figure out how it’s supposed to work, which is a non-trivial undertaking).  One thing that makes it harder is that most of the (still scant) documentation around ADAM is geared toward IT Pros, not developers, so there are plenty of places where you track down the documentation for that critical change you need to make to your directory, only to be told “start the command line tool…”.  Frustrating, but workable. 

Once the magic incantations are prized forth, it seems very fast.  Granted we’re not doing anything tricky at this point, but adding users, setting passwords, simple queries, all seem pretty snappy. 

On my previous problems with ADAM and AzMan integration, this is apparently caused by the fact that I had my users in one application partition in ADAM, and my AzMan store in another partition in the same ADAM instance.  The official word is that this is not supported, which probably makes sense.  It means that I’ll probably end up using a separate ADAM instance as the AzMan store, or fall back to the XML file, although that’s harder to distribute.  Only time will tell.

Tuesday, 17 October 2006 10:32:08 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, 06 October 2006

I'd been having some trouble (read: beating my head against the wall) trying to get passwords set/changed for users in ADAM early this week.  Unfortunately, many of the available samples are geared toward IT rather than development users, so tend to be in script, etc.  I've been working from the excellent book "The .NET Developer's Guide to Directory Services Programming" by Joe Kaplan and Ryan Dunn.  Sadly, I couldn't get their password changing samples to work, although aside from that the information in the book has been invaluable. 

I finally found what I needed in an obscure section of the documentation after many a googling.  This article gave me the key info that made this work.  I haven't tried all the permutations, but I think the key piece I was missing was the right combination of AuthenticationTypes flags

 

            // Set authentication flags.

            // For non-secure connection, use LDAP port and

            //  ADS_USE_SIGNING |

            //  ADS_USE_SEALING |

            //  ADS_SECURE_AUTHENTICATION

            // For secure connection, use SSL port and

            //  ADS_USE_SSL | ADS_SECURE_AUTHENTICATION

            AuthTypes = AuthenticationTypes.Signing |

                AuthenticationTypes.Sealing |

                AuthenticationTypes.Secure;

 

            // Bind to user object using LDAP port.

            try

            {

                objUser = new DirectoryEntry(

                    strPath, null, null, AuthTypes);

                objUser.RefreshCache();

            }

            catch (Exception e)

            {

                Console.WriteLine("Error:   Bind failed.");

                Console.WriteLine("        {0}.", e.Message);

                return;

            }

This sample worked just fine, and I was finally able to set or change passwords for ADAM users.  Once that's done, authenticating that user is as easy as

            DirectoryEntry de = new DirectoryEntry("LDAP://localhost:50000/RootDSE",

                "test.user",

                "passwordSuppliedByUser",

                AuthenticationTypes.None);

            de.RefreshCache();

If the supplied password is correct, it succeeds, else you get an exception. 

Now I can get on with the interesting parts...

Friday, 06 October 2006 10:42:25 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  | 
# Tuesday, 03 October 2006

I’m sure this must work for someone, but I’m having a heck of a time with ADAM.  The latest is that I can create users just fine, assign properties to them, etc., but I cannot seem to set their passwords.  I feel like I’m missing something here, possible a permissions problem, although I can set passwords through the ADSI GUI.  The other possibility is that the user is not in the right state, maybe not correctly enabled, or something.  This is the code that should work

            entry = new DirectoryEntry("LDAP://localhost:50000/CN=test.user,OU=Users,C=Bank", null, null, AuthenticationTypes.Secure);

            entry.RefreshCache();

            entry.Options.PasswordEncoding = PasswordEncodingMethod.PasswordEncodingClear;

            entry.Options.PasswordPort = 50000;

 

            entry.Invoke("ChangePassword", new object[] {"old","new"});

Unfortunately, I have no idea what the problem really is, because all I get back is

System.Reflection.TargetInvocationException was unhandled
  Message="Exception has been thrown by the target of an invocation."
  Source="System.DirectoryServices"
  StackTrace:
       at System.DirectoryServices.DirectoryEntry.Invoke(String methodName, Object[] args)
       at AdAzMan.Program.Main(String[] args) in Program.cs:line 43
       at System.AppDomain.nExecuteAssembly(Assembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()

Where the inner exception is {"An operations error occurred. (Exception from HRESULT: 0x80072020)"}.  Not very helpful.  That’s pretty much equivalent to “something bad happened”.  Granted, it’s a different error from the ones I get if the bind fails, or if I don’t set the entry’s password options to allow changing the password over an insecure channel, but this one’s got me stymied.

Tuesday, 03 October 2006 10:33:39 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, 10 August 2006

I have progressed a bit.  At least I seems to have an install where ADAM and AzMan will coexist happily in the same ADAM instance, and I can retrieve a user from the ADAM store.  I can also add roles to AzMan programatically, so that's all good.  However, I still can't add an ADAM principal to AzMan as a member of a role.
This is supposed to work...

   15           string roleName = "RetailUser";

   16 

   17             MembershipUser user = Membership.GetUser("TestUser@bank.com");

   18             Console.WriteLine(user.ProviderUserKey);

   19 

   20             IAzAuthorizationStore2 azStore = new AzAuthorizationStoreClass();

   21             azStore.Initialize(0, "msldap://localhost:50000/CN=Test,CN=AzMan,O=AzManPartition", null);

   22             IAzApplication2 azApp = azStore.OpenApplication2("TestApp", null);

   23 

   24             IAzTask task = azApp.CreateTask(roleName, null);

   25             task.IsRoleDefinition = -1;

   26             task.Submit(0, null);

   27             IAzRole role = azApp.CreateRole(roleName, null);

   28             role.AddTask(roleName, null);

   29             role.Submit(0, null);

   30 

   31             IAzRole newRole = azApp.OpenRole(roleName, null);

   32 

   33 

   34             newRole.AddMember(user.ProviderUserKey.ToString(), null);

   35             newRole.Submit(0, null);

And should result in TestUser@bank.com being added to the role "RetailUser". 
Sadly, on that last line, I get

System.ArgumentException was unhandled
  Message="Value does not fall within the expected range."
  Source="Microsoft.Interop.Security.AzRoles"
  StackTrace:
       at Microsoft.Interop.Security.AzRoles.IAzRole.Submit(Int32 lFlags, Object varReserved)
       at ADAMAz.Program.Main(String[] args) in C:\Documents and Settings\PCauldwell\My Documents\Visual Studio 2005\Projects\ADAMAz\ADAMAz\Program.cs:line 35
       at System.AppDomain.nExecuteAssembly(Assembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()

All I can figure is that AzMan doesn't like the SID as generated above. 
I'm running this on XP SP2, with the 2003 Management tools, and ADAM SP1 installed.  I'm fearing that I may have to run this on 2003 R2 to get it to work.


Thursday, 10 August 2006 17:07:15 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  |