The following is my opinion... and my opinion may change based on the context that the individual items are placed.  With that said... I hope you find them useful.

 

Store Selection: prefer AD to leverage existing investment in availability and performance then ADAM (functional mode, political, organization policies, etc)

 

Authentication: prefer AD to take advantage of multiple client context initialization e.g. token/name/sid.  ADAM is very popular for Internet access however some additional code is required for SID/role population in security client context. Another cool part about the
Win2k3 SP 1 update is that it possible to use dynamic ldap query groups with ADAM. The binding is signed and sealed... so pointing to an ldap store other than ADAM is not supported.  Another thing to note... since the coder is doing the pointing on an attribute of the client context,  it is possible for that coder to point to the wrong DN. Check out ADFS which may use AD or ADAM as the AuthN store for claims based applications and utilize AzMan as the transformation engine between ADFS claims and either AzMan application groups or directly to roles.  There is a small bit of code with an example pending in a future ADFS SDK.

 

Performance: 

reducing the additional (internal) call to populate security context sids.

  • Wrap large number of users in AD groups so that the only compare required is against the group Sid.
  • Use scopes where applicable. 
  • Minimize usage of dynamic query groups when you want to reduce lookup times. 
  • Make judicious use of business rules. Keep them short.
  • Try to limit Application groups to fewer than 1000 members if possible reducing lookup time. The load time is reduced with a smaller dataset size of SIDs.
  • If unable to move domain to Win2k3 functional mode use ADAM and load balance for performance and availability. Check performance counters and network health. Test and tune.  Remember that a server needs to be listed when using ADAM e.g. there is no server-less bind e.g. for ADAM msldap://myserver:50000/CN=azstore;CN=azmanapps;DN=foo;DN=COM vs AD with CN=azstore;CN=azmanapps;DN=foo;DN=COM
  • When using AD ensure a healthy directory/infrastructure.  Validate/identify DC that is being utilized for lookups and try to have it relatively close in proximity.
  • Utilize Win2k3 SP1 and new interfaces for better performance including store creation/population
  • Avoid role bloating - favor scopes.
  • Utilize trusted subsystem model for store access as opposed to impersonation model where all end users get some level of access to the authorization store itself. Avoid impersonation model on win2k if possible. There is also a different API
  • Note transactions are not supported but multiuser access and administration is when using other than XML store.  XML store will support multiple reads but when using .NET use locks or catch errors on access.  When reading, the whole XML store loads and writing the whole XML writes to disk.  AD and ADAM utilize a lazy load mechanism where gathering data is done as needed. Caching grows to the size of the store for each process with it open.  The largest store that I have personally seen is 15 MB.  I would like to hear about any greater than than.
  • Design audit information for clarity per the accesscheck
  • For code readability you may choose to enumerations or constants for your operations
  • Delegation is possible with AD
  • Remember to see the operations that the MMC (AzMan.msc) must be in developer mode otherwise it only shows tasks (which is the level that most admins would look at anyway)  Tasks being a logical grouping of low level operations that make up a role definition.
  • Reduce network calls through multiple ops in accesschecks when possible. When using .NET – I recommend wrapping the result of the accesscheck from S_OK which equals 0 to either a Boolean response of True or False or returning an array/list of the same
  • Check out existing docs

 

Check out the AzMan Team Blog http://blogs.msdn.com/azman !