1. "Synchronising" user accounts (worst option).
If you create local user accounts on the workgroup server with the same username and password as the domain user accounts that you want to grant access, you can add these local accounts to the share and NTFS permissions and it will allow the domain users to seamlessly connect to the share.
The obvious headache with this approach is administration, since whenever the domain user changes their account, it will no longer be in sync with the local account on the workgroup server and access will be denied. Therefore, I wouldn't recommend this approach.
2. Use "Credential Manager" to store credentials for the workgroup host (only recommended for very small numbers of users).
Credential Manager only exists on Windows Vista and later, so if your clients are Windows XP then forget about this option and skip to the next.
Credential Manager can be found in the Control Panel and allows you to enter Windows credentials which are stored securely. Whenever the user accesses the workgroup host, their client will use the saved credentials you entered instead of the domain credentials.
The positive aspect of this approach is that it alleviates the password changing issue. However, there are still too many negatives, such as having to enter the credentials manually for each user per computer, which isn't practical if you've got more than a couple of users requiring access.
3. Use a mapped drive via a logon script (still not a preferred option).
You can use a logon script to map a drive to the workgroup server, using the /user switch. For example:
net use G: \\workgroupServer\share /user:workgroupServer\user passwordThe upside to this approach is that you're finally using a centrally managed solution. The downsides are that the password is completely unsecure, and unless you plan to put in a bit of fancy DOS scripting, everyone's going to use that one account to map with, meaning the same access for all. Still, it's potentially better than the other two previous approaches.
4. Group policy user logon script (a better option).
Mostly the same as the above, though it offers one advantage in that it's easier to target different groups of people if you're not comfortable with scripting that kind of logic.
5. Use Group Policy Preferences (preferred option).
This option is only available natively with Windows 7. If you want to use policy preferences with Windows XP or Vista, you'll need to look at downloading the GPP extensions for those operating systems from
here. For Windows XP you'll also need to have deployed Service Pack 2 (though SP3 is highly recommended owing to some issues with SP2) and for Vista, Service Pack 1.
You will also need access to a Vista with SP1 or Server 2008 machine from where you can run the Group Policy Management Console (part of the RSAT tools for Vista, or the Features section of Server Manager for Server 2008) in order to define group policy preferences.
Assuming you meet these requirements, you can deploy a mapped drive quite easily to specific people (or groups of people). It also makes it a little harder for curious people to obtain the password for the account you're using.
So, as you can see, there's a lot of alternative options for solving your problem - some good, some not so good. Hopefully this helps you decide on an approach.
Cheers,
Lain