Do I need to import AD users/groups into a database from which StrataFrame can retrieve user data for authentication and authorization?  Or, can I simply use these entities directly (database connection to the AD database directly)?  I really do not want to use anything other than the active directory.  All of my necessary data is already there.  I really did search through both the documentation and the forums for an answer but I missed it somewhere.

Thanks,
Bill

If you are using Windows Authentication, StrataFrame will authenticate through the Windows API whether you are on a domain or using workgroup permissions.  However, you still need a StrataFrame user so that you can assign all of your applications permissions to a user once they login to the application itself.  So you may want to write a program that queries LDAP to automatically create SFSUsers records....or you can do this manually as well.  We have developers out there who do it both ways.

We never query AD directly.  We use Windows APIs for authentication.  The issue with not creating SF users is that you cannot assign any permissions, roles, etc. for your application.  So even though you are authenticating off of AD, you still need an SF user to which permissions can be assigned.

I just had a big response written, when I hit 'Post Reply', I received the dreaded ASP.NET Server Application error.  My response is gone.  Bummer. 

Here it is in a nutshell:

Manual entry may be the way to go; however, what do I do about passwords when I do not know what they are?

Also, I am getting an error when I fire up the SecurityDialog from my app...SFSUSers is empty; SFSPreferences is not set.  The SF database is on my local SSE installation.  Is that a problem?  Is there something else that I need to consider?

Thanks,
Bill

See http://forum.strataframe.net/Topic13101-6-1.aspx.  This may be the root of the problem...the security DB cannot be in the development SF DB, but must be relocated for runtime use.  Yup...that makes sense! 

Yep, that's the one... the database reachable by our MicroFour.StrataFrame.Security.SecurityBasics.SecurityDataSourceKey needs to contain the SFSPreferences table (and all of the rest of the SFSx tables... save for the SFSProjects table, which is only needed at design-time).