Hi,
I have a custom MOSS 2007 web part which uses a RadGrid bound to a LinqDataSource hitting a SQL DB. Everything works fine when running MOSS and SQL on the same machine, but when moving the webpart to an environment where those services reside on separate machines I run into the usual 'double-hop' issue. User on machine A authenticates to MOSS machine B; on machine B the web.config is set to impersonate; but those impersonated credentials cannot be sent to the last hop to SQL machine C.
I don't think I can get away with changing the impersonation account on the entire web application's web.config (web app is used for many, many other things than this one web part). I also don't believe getting Kerberos set up between the MOSS machine B and the SQL machine C would be acceptable for the target environment, but I'm investigating that approach just in case.
Suggestions on how this would typically be done? Best approach I've come up with so far is to:
1. Create a domain account login.
2. Grant that domain login the appropriate access on the SQL box.
3. Edit the DataClasses.designer.cs file to intercept the Get method for the table and wrap the 'return this.GetTable<tablename>();' with additional code to read in an encrypted username / password from the web.config, use them to impersonate the domain account, make the call, and then undo the impersonation.
Note that this requires editing an auto-generated file, which means having to deal with preventing re-generation so I don't lose the chnages, etc.
Any better approaches out there?
Thanks,
William
I have a custom MOSS 2007 web part which uses a RadGrid bound to a LinqDataSource hitting a SQL DB. Everything works fine when running MOSS and SQL on the same machine, but when moving the webpart to an environment where those services reside on separate machines I run into the usual 'double-hop' issue. User on machine A authenticates to MOSS machine B; on machine B the web.config is set to impersonate; but those impersonated credentials cannot be sent to the last hop to SQL machine C.
I don't think I can get away with changing the impersonation account on the entire web application's web.config (web app is used for many, many other things than this one web part). I also don't believe getting Kerberos set up between the MOSS machine B and the SQL machine C would be acceptable for the target environment, but I'm investigating that approach just in case.
Suggestions on how this would typically be done? Best approach I've come up with so far is to:
1. Create a domain account login.
2. Grant that domain login the appropriate access on the SQL box.
3. Edit the DataClasses.designer.cs file to intercept the Get method for the table and wrap the 'return this.GetTable<tablename>();' with additional code to read in an encrypted username / password from the web.config, use them to impersonate the domain account, make the call, and then undo the impersonation.
Note that this requires editing an auto-generated file, which means having to deal with preventing re-generation so I don't lose the chnages, etc.
Any better approaches out there?
Thanks,
William