Set the permissions of \\fileserver\users as described in the Microsoft TechNet article entitled "Security Considerations when Configuring Folder Redirection" http://technet.microsoft.com/en-us/library/cc775853(WS.10).aspx. The situation you are describing is exactly the situation in which folder redirection operates. The permissions described will allow regular user accounts to create their own folders and then to access them, but they will not allow users to access folders belonging to others. Thus, a logon script will operate as you desire once these permissions are set.
For what it's worth, your next step along the road to best practices is to actually use folder redirection and get rid of drive mapping altogether. Windows surfaces redirected folders throughout the user interface, and so it is easier for users to find a redirected folder than a mapped drive. Also, folder redirection requires no scripting, and folder creation is automatic, which is what you want.
The feature you're looking for is folder redirection. This feature, on it's own or in combination with roaming user profiles (I recommend using both) will allow you to keep the largest folders of the user's profiles on the server and speed up logon times.
I also recommend creating the folders and setting the permissions yourself on the destination folders. The OS default method seems buggy brain-damaged to me.
Edit:
My issue with the built-in functionality that allows clients to create the folders is that I stronly prefer not to have a world-writable folder for such a critical purpose (redirected user folders) on my server computers. I'm not sure that Microsoft has ever cleaned up the idiotic "feature" where the client blocks NTFS permission inheritance when it creates the user's folder and applies permission to it, either. I want to be in control of my filesystem permissions, I want inheritance turned on throughout the entire folder hierarchy, and I don't want a world-writable folder laying around on my servers.
I generally redirect "My Documents", "Desktop", and "Application Data". I always disable the idiotic "Grant the user exclusive access..." functionality (since it screws up my NTFS permission inheritance hierarchy). I may do redirection based on group membership if I have multiple destination file server computers and want all my redirection handled in a single GPO... that's more of a GPO design concern than a Folder Redirection configuration issue.
"AppData" redirection has been somewhat problematic. I've had issues with Adobe Reader 9.0 versions and the current Apple iTunes 9.2 versions not working properly when the user has a redirected AppData folders. Still, with the huge proliferation of small files that get created there, leaving "AppData" in the user's roaming user profile isn't an option if you want short logon / logoff times.
Generally I wouldn't exclude any "normal" users from Folder Redirection. Administrative and service account context users would be excluded, typically by being located elsewhere in the OU hierarchy such that the GPO applying Folder Redirection settings doesn't apply. WMI filters aren't useful because Folder Redirection is a user setting, and WMI filters only apply to computers.
Slow links and disconnected computers are good candidates for Offline Files. If a user isn't ever going to be connected to the LAN with high speed I might be apt not to use Folder Redirection at all, but I don't have any situations where that's the case in my current Customer base so I haven't really thought about it. Offline Files works very well in Windows 7 and Windows Vista. It works acceptably in Windows XP if the user's redirected folders are under 2GB in size. Anything more than 2GB and it starts working poorly because of a frustrating signed 32-bit integer size limit on the amount of data that will be automatically cached by Offline Files.
Best Answer
You can do what you're asking, but you REALLY should not -- Unix users should always have a dedicated home directory, owned by that user's UID.
This is what Unix expects, and the reason you're giving above is a poor justification for Doing It Wrong.
To briefly summarize the problems:
Permissions
If your users have different UIDs and are sharing a home directory LOTS of things break.
SSH won't work properly (because ~/.ssh will have the wrong owner/permissions)
Shell history may not work (and will almost certainly throw errors).
Your users will invariably make files nobody else can read/manage, or step on each other's files.
Security and Auditing
Unix relies on the numeric UID for pretty much everything. If you get around the permissions problem by assigning everyone the same UID you wind up losing the ability to audit who did what.
If John Doe and Jane Smith are both logged in to the system and someone deletes the Apache configuration (out of malice or by accident) it becomes very difficult to track down the responsible person.
Principle of Least Astonishment
Generally you should set up systems that behave as the majority of the world expects them to.
This means every user has a distinct username, User ID, and Home Directory (and in the general case that the user's home directory name matches their username).
Setting up a system that violates the Principle of Least Astonishment should only be done with extremely good reason (and as I mentioned above you seem to lack a good reason).
Given the above, if you still want to do this then based on the fact that you've told us that Centrify Express is RFC 2307 compliant, the best possible solution would be to assign all your users the same User and Group ID (
uidNumber/gidNumber), and Home Directory (homeDirectory).This minimizes the chance of breaking things (SSH, shell history, file permissions, etc. will all be fine because the numeric UID is the same) at the expense of security/accountability.
This also means that you can't use these accounts as "normal" unix accounts on any other system -- the accounts are effectively aliases to one account (UID) with different passwords.
A better solution to this situation would be to create a local admin account on your Unix systems and allow your users to access it using their SSH keys. This still breaks accountability to some extent, but leaves you with LDAP/AD accounts that can still be used as "normal" unix logins.