It depends on how the application is written as to whether it will try stored credentials if the current (local) ones fail. There are some ideas on this page:
http://www.olegsych.com/2009/05/crossing-domain-boundaries-windows-authentication/ runas sounds like your best option if the app won't use stored credentials. Jeff On Wed, May 6, 2009 at 11:25 AM, John P. Bonner <[email protected]>wrote: > Using runas /user:machinename\account localexepath everything runs > perfect. So again it really looks as though the I/O operation at the Msoft > level to find the second share inherits the perms of the executing user. > > > > So next question. Is this the best solution? > > > > Thoughts? > > > > TIA > > JB > > > > *From:* Tom Miller [mailto:[email protected]] > *Sent:* Tuesday, May 05, 2009 5:16 PM > *To:* NT System Admin Issues > *Subject:* RE: Sorry for the simple question but I'm a developer not a Sys > Admin Guru > > > > Are we talking Windows shares, CIFS, etc? If you are talking Windows, this > would be easiest with Active Directory using a single set of credentials per > user, then pass-through authentication should work. Single-server accounts > will cause you grief - stay away from that scenario if you can. Put the > server in AD DS if you can, even if it's only a single server AD, then at > least you could create a cross forest Trust. How is this different? > Maintaining hundreds of single server accounts or maintaining hundreds of ad > accounts? The agents, even if they are “employees” will provide their own > laptops and thus each have their own login. We have no issue giving them the > uid & pwd for access to what they need but apparently somewhere behind the > scenes Msoft. doesn’t use the credentials challenged for initially. In the > application we say ok after you have logged in look for this folder in the > same location. It appears that file I/O Operation must inherit the security > context of the logged in user instead of using the uid / pwd challenged for. > > > > > > > Also, version of server (assuming Windows) will matter. Windows 2008 is > better than 2003 at security and out of the box won't let you do much. > That's the opposite of 2003, for the most part. > > > > So, if you can: > > 1. Get the server into a domain. Any reason preventing it? > > 2. Use AD accounts and put those who need access in a group. > > Problem here is that these people are NOT employees. Think > of it like insurance. These agents sell our insurance but also other > products / policies. > > 4. Optional: if the VPN is reliable and has decent throughput, you can > put those PCs in the domain. Even a low-end PC at your remote site can be a > DC for authentication. > > > > > > If you're talking Linux, never mind ;-) If you're not a sys admin, then > those folks could probably give you a hand with this. > > J J J In this case those folks are the ones asking me for help…. J J J….and > I’ve gotten a lot further then they did. Please don’t flame about competent > help etc. I can do nothing about it nor talk to anyone in a position to do > anything about it…but you are right that is part of the problem. > > > > Tom Miller > Engineer, Information Technology > Hampton-Newport News Community Services Board > 757-788-0528 > > > > > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
