I'm using SDK 8.3. If I put AD credentials into conn.UserName and Password, it fails. In the client, if I uncheck "Use Windows Authentication" and type in AD username and password, I connect OK.
You need to impersonate the Windows identity you want to use while you authenticate to the Laserfiche server. You'll first need call LogonUser to get a session token for the user, and then impersonate it with WindowsIdentity.Impersonate. While impersonating, connect to the server with blank username and password. Don't forget to stop impersonating and release the session token.
Hi Brian,
I am using SDK 9. Is the above still the case? I think it is because I have tried logging in as follows without success:
string lfWinUserName = @"somedomain\" + username;
_sessionToken.LogIn(lfWinUserName, password, myRepoReg);
It would be nice to have the option to login an AD user in the future.
Thanks
Regards
Peter
It's still true for both LFSO and RA. It's true we could move the calls to LogonUser etc into the library, but honestly I would worry about that hiding too much complexity for the most common use cases. This is how Web Access authenticates to the Laserfiche server (in the case where the user enters their domain credentials into the login form), and I don't know how many times we've had to help people out because those users were not given logon permissions to the web server. If it's your code, you'll more quickly realize that it's the LogonUser call that fails, not the authentication to Laserfiche.
Furthermore, this approach isn't really the best practice for using Windows authentication with Laserfiche. Better than handling domain credentials in your application is either launching your application as the user you want to authenticate as or using a technology like Kerberos if you are delegating a client identity. Both are more secure and give a better user experience.
All that said, here's how you do it:
IntPtr tokenPtr = IntPtr.Zero;
bool loggedOn = LogonUser(user, domain, password, (int)LOGON_TYPE.LOGON32_LOGON_BATCH, (int)LOGON_PROVIDER.LOGON32_PROVIDER_DEFAULT, out tokenPtr);
if (!loggedOn)
throw new Win32Exception();
WindowsImpersonationContext ctx = null;
try
{
ctx = WindowsIdentity.Impersonate(tokenPtr);
sess.LogIn(repoReg); // this is RA, LFSO would call LFConnection.Create()
}
catch (Exception ex)
{
if (ctx != null) ctx.Undo();
CloseHandle(tokenPtr);
throw;
}
if (ctx != null) ctx.Undo();
if (tokenPtr != IntPtr.Zero)
CloseHandle(tokenPtr);
You can get the declaration for LogonUser and its enum types from PInvoke.net.
The exception handling code is a little different than what you usually see, but there's a reason for that.
This code works for me in 9.2 but not 10:
RepositoryRegistration myRepoReg = new RepositoryRegistration("ServerName", "RepositoryName");
Session mySess = new Session();
mySess.LogIn(@"domain\userid", "password", myRepoReg);
We need to connect on an internal web server with a service account that has different authorizations than the Laserfiche user making the web call. Our application was working fine on 9.2, an it is not optimal to have to change it for 10 for this.
Thank you for the reply. I chose to add the AD user as an LDAP Account rather than a Windows Account in LF Admin tool to make the programming side simpler.
Brian, we have a complex situation where one web service will be calling our own web service for information stored in Laserfiche. For LF security reasons, we'll need to at log in as the user who originated the request, and are trying to sort out the best way to do that. The debate is whether we use Windows Impersonation, or assign what amounts to a separate Laserfiche user name and password to the user's account (which uses Windows Authentication).
In the example above, it looks like you need to have the password already. Is there an approach where we can use the user's session token, assuming we can get it, vs. creating out own?
I ask because in the example above, it looks like you need to have the password on hand already. That may not be something we have access to.
BTW, here are some additional resources on this topic we have turned up, with a little overlap with the link you posted.
http://devproconnections.com/development/insecure-exceptions
http://pluralsight.com/wiki/default.aspx/Keith.GuideBook.WhatIsImpersonation
The original question here was about a scenario where you have AD credentials and want to use them to authenticate to the Laserfiche server, so that's what all of the answers start with.
If you set up authentication on the web server properly, there will already be a WindowsIdentity attached to the request that you can impersonate (rather than creating one from credentials as above). If Kerberos is configured, then you will be able to delegate that identity to the LF server when you log in with the SDK.
That last link talks about the way to configure your web app for authentication and impersonation. If you follow its recommendations, you don't have to explicitly interact with any WindowsIdentity objects because you will always be impersonating the caller. This may be ok for some scenarios, but it can cause unexpected problems because all of your code runs in the security context of the caller. Your users may not have rights to e.g. write to certain files on the server that your application needs to write to. For this reason, Web Access has impersonation turned off in the web.config file and calls Impersonate() on the identity just when it wants to authenticate to LFS.
Thanks Brian,
It looks like we'll have access to internal Laserfiche user names and passwords, and can avoid the context issues (and all the related security issues) altogether, It's a very complex area, and your comments on the various aspects of it are very useful.
Bill
Hola que tal buen dia. /Hello, such a good day.
Necesito de su apoyo en este foro, ya que tengo el siguiente detalle. No puedo realizar la Conexión a Laserfiche. Aqui les muestro mi codigo. Me pudieran decir que es lo estoy haciendo mal. Version de Laserfiche 8.1.1.600
I need your support in this forum, as I have the following detail.
I can not make the Laserfiche Connection. Here I show you my code.
They could tell me what I'm doing wrong. Version of Laserfiche 8.1.1.600
this.server = new LFApplication().GetServerByName("Server");
this.db = server.GetDatabaseByName("Repositorio");
this.conn.UserName = @"dominio\dah.usuario01";
this.conn.Password = "Password";
Agradezco los comentarios y sugerencias.
I appreciate the comments and suggestions.