Thanks,
Bill

Just bumping this thread since it is about 10 days old without a response.

Thanks!
Bill

Btw, I have setup the users in SF.  I am a bit confused though how I can get a single-signon approach going.  Since the user has logged on to the workstation, then I would like to simply use that logon and mesh it up with the SF user account.  The roles and such are no big deal...I can mess with those within the framework.  Our users are not going to like that extra logon screen.  I have shielded them from it so far...I'd like to keep doing that.  Thanks!

Bill

All you need to do is add a reference to the Microsoft.VisualBasic assembly in your C# project and you will then have access to this class....don't worry, this is just a namespace so don't think your "slummin'" by adding this reference to your project

We actually will be adding this same functionality to our medical system but by integrating this with Biometrics so that they can have a single login to the OS and application.  This will have to be coded for the most part on your side though.  You can create an automated login once a user logs into the OS...but this will require that you handle the OS system login or add a startup program for the workstation.  There are a lot of articles out there that explain how to tie into the winlogin through Windows API...or the winlogon service.  You can then manually authenticate the SF user with the :

You can find more details on this in the help docs: Role-Based Security->Defining Security Within the Application->Login Class->Methods

I hope so; otherwise, how do I get a user's password into SF from the Active Directory?

Thanks,
Bill

This would depend entirely on what you want to do.  I would probably not leave the SF password blank, but rather come up with some configuration of the user name or something just to ensure another level of security within your app.  But if your SF user name is the same as the OS, then it makes this very easy.

This would be much more complicated and require a lot of API interaction...I would recommend the above route instead.

After I created all of the users I need in the StrataFrame security database, I created a class to hold my code that queries the AD.  All I do is pass the AD user property that I am looking for and it returns the value in that user property.  For example, I pass the property "sAMAccountName" and the function returns a username (e.g. "bill").  Then, I pass the username to the SetLoggedInUser method of the Login class in StrataFrame, like this:

Login.LoginResult lr;
lr = Login.SetLoggedInUser(mLoginname, "password", "domain");

The password and the domain is the same for everyone.  I manually assigned the password to each user record in the security database.  It could be anything.  There is no user login window.  Authentication is handled all behind the scenes!  The CurrentUser is set!!  

My next step at making this even more effective will be to expand my AD class so that it returns what I need as simple properties.  For now, it is all built-in to the function call.  And, I have the entire StrataFrame security sub-system at my disposal, too!  What a beautiful thing!!

Thanks,
Bill