If I have Windows authentication turned on (SecurityBasics.AllowWindowsAuth = true) how do I pass the user and password from the OS to the application so I can authenticate in the app without having the user logging into my application directly?

Thanks,
Bill

Happy New Year!

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

Thanks!
Bill

Still looking for help on this one...bump...

I assume that you already understand that even when using Windows Authentication, you will still need an SF user account so that you can attach permissions to that account for your application.  With that understanding, you can pull the user name from the OS like this:

Thanks a ton for the reply.  I will look at this code more closely when I get back in to the office tomorrow.  Is there an equivalent namespace for Microsoft.VisualBasic.ApplicationServices in C#?

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

Do I understand this correctly?  A user must exist in the SF security database (if we are employing security, of course), but I do not need to store a password as long as the username matches the OS username and the OS has authenticated the user (using Windows Authentication).  Is that right? 

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.

I finally got back to tackle this issue.  I successfully managed to integrate our Active Directory with the StrataFrame security sub-system.  It was not too difficult, but did involve a counter-intuitive decision.  I turned off AllowWindowAuth.  It was gumming things up.

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

Glad you got it working... there's certainly not need to show a login form to the user if they're already logged in to windows, right?