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. 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. 3. For Windows 2008, use the "Share and Storage" applet and create the share to grant appropriate permissions. 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. Also, if you are using Windows 2008, you can use the Public folder (sounds like Novell, hmmmmmmmmm) 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.
Tom Miller Engineer, Information Technology Hampton-Newport News Community Services Board 757-788-0528 >>> "John P. Bonner" <[email protected]>05/05/09 6:41 PM >>> <o:p></o:p> Both shares are shared out with everyone full control. We were trying to get it to work and we would tighten down from there.<o:p></o:p> I honestly dont know where the network challenge comes from originally. Both shares are open to everyone full control. So I am *ASSUMMING* the network challenge is coming from the client & server not knowing each other so there is a credentials challenge BEFORE even showing the shares.<o:p></o:p> <o:p> </o:p> JB<o:p></o:p> <o:p> </o:p> Klint Price - ArizonaITPro [mailto:[email protected]] Sent: Tuesday, May 05, 2009 4:37 PM To: NT System Admin Issues Subject: Re: Sorry for the simple question but I'm a developer not a Sys Admin Guru<o:p></o:p> <o:p> </o:p> Are the two shares on different servers, or the same server? Is the UID and PW the same for both shares, or different? Klint John P. Bonner wrote: <o:p></o:p> Hello,<o:p></o:p> <o:p></o:p> Sorry for the lame question but I am trying to figure out exactly what is going on. We have a server in a central office and we connect to the corporate network via vpn. The server is not on a domain and 99% of the workstations are not in a domain of any sort either.<o:p></o:p> <o:p></o:p> Client ABC logs into local machine with some username<o:p></o:p> Client ABC connects to the vpn.<o:p></o:p> \\XXX.XXX.XXX.XXX\sharename<o:p></o:p> Client ABC is challenged for a UID & PWD<o:p></o:p> Client ABC enters correct Network Resource UID & PWD<o:p></o:p> Client ABC sees files and folders on share<o:p></o:p> Client ABC can work with files no problem<o:p></o:p> \\XXX.XXX.XXX.XXX\sharename<o:p></o:p> Client ABC program opens and asks for uid & pwd to database<o:p></o:p> Client ABC enters the UID & PWD for database and access granted<o:p></o:p> \\XXX.XXX.XXX.XXX\sharename2<o:p></o:p> Client ABC has full access to this share as well but the locally executing program *MUST* (I am assuming here) use the credentials of the logged on user *NOT* the credentials Client ABC entered above to gain access to the resource.<o:p></o:p> <o:p></o:p> I make the above statement because if I create a local windows account with the Network Resource UID & PWD from and log in under that account everything runs smoothly.<o:p></o:p> <o:p></o:p> <o:p></o:p> So my questions for you professionals is how to best solve this problem. Creating hundreds of user accounts on the server would be maintenance H&*%. <o:p></o:p> <o:p></o:p> Would creating the account on the local machine then giving the locally installed exe run as (Network Resource UID & PWD) solve it?<o:p></o:p> <o:p></o:p> <o:p></o:p> Thoughts or suggestions greatly appreciated.<o:p></o:p> <o:p></o:p> Thank You<o:p></o:p> JB<o:p></o:p> <o:p></o:p> <o:p></o:p> <o:p></o:p> <o:p> </o:p> <o:p></o:p> <o:p></o:p> Confidentiality Notice: This e-mail message, including attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
