So I've found the version of the SQL User Manager on K2's download page that has the source code and I've created my own implementation of a user manager.

  The process of creating your own basic user manager is actually
pretty simple.  Of course, it will not be supported by K2, so you'll be
on your own in that respect.  In certain circumstances, rolling out
your own custom user manager can be a great solution; especially if you
already have an existing framework of users and groups that you'd like
to plug into.  I'm very pleased that K2 made this feature available so we're not stuck using only their version of the ADUM or their SQLUM.  I just wish K2 would have put some effort in documenting the subject of custom user managers.

In summary:

1. create a new project
2. Add a reference to the SourceCode.K2UMI assembly
3. Create the classes that implement interfaces defined in the K2UMI assembly
   
   1. SourceCode.K2UMI.IK2UserManager
      
   2. SourceCode.K2UMI.IK2Group
   3. SourceCode.K2UMI.IK2Groups
   4. SourceCode.K2UMI.IK2User
   5. SourceCode.K2UMI.IK2Users
4. Implement the functions in the classes.  The main class is the one that implements IK2UserManager.  This class will implement the methods:
   1. FindSecurityGroups() - this method is used to get the security groups for a given user.  It is also used to search for groups based on criteria (name, description) from the Find Groups panel in the K2.net 2003 Service Manager
   2. FindSecurityUsers() - used to search for users in the Find Users panel in the service manager
   3. GetGroup() - gets an IK2Group by name
   4. GetUser()  - gets a IK2User by  name
   5. Init() - this method is called by K2 server when the service starts.  There is one parameter that is passed which is the value of the 'Data' text field in the User Manager tab in the K2.net server Properties panel.  I'm using this to hold the sql connection string.
   6. Login() - this passes the K2 connection string (from the external connection string property of the server registration properties or from a caller like K2Rom.K2Connection.Login() method) - here is where you could perform authentication and return the username. ** If you set the UMName property in the K2.y_settings] table to "K2" then the Login() method in your class will not be called.  The ADUM assebly will do Windows authentication and return your windows domain/username.  This provides a way to have a mixed mode user manager where authentication is done using AD but authorization is performed in your custom class.
      
   7. ResolveQueue() - we don't use queues, so I left the implementation of this method blank.
      

K2 server will use the values in the K2._Settings table to determine which user manager assembly to load/use. 

     K2._settings table values
     Name          Value

    Anonymous      True
    UMName          K2                    ***Using "k2" forces K2 server to use AD/Windows authentication***
    UMAssembly    iDistrictUserManager
    UMType            iDistrictUserManager.K2UserManager
    UMData            Data Source=(local);Initial Catalog=id30_119;User Id=myID;Password=myPassword;
    Version             3.6262.1.0
    IPCRetryCount    3
    IPCRetryInterval    600
    ManagedUsers    True
    XMulti    

Attached is the source code for the custom user manager that I'm using.  As you can see, there's not much to it.  The interesting parts are in the iDistrictK2UserManager.vb.  There are two methods that make a sql call to our custom database to get the users.  If the user exists in our database, a single K2Group is returned.  In K2, our process permissions are granted to that single K2 group.

This implementation is rather simple and straightforward, but provides the groundwork for more involved user-group-role resolution.