In the first bit of your post it sounds like somebody had already configured a "Restricted Groups Policy" for the "Remote Desktop Users" group, which explains why it "emptied out". That's not a stock OS feature-- somebody configured that at some point. You got around it by either modifying the GPO that was "emptying out" the group, or by making a new GPO that applied after the existing "Restricted Groups"-containing GPO to override the setting.
The next bit-- the "You do not have access to logon to this session" bit is a bit more confusing. I've been trying to repro it on a Windows Server 2003 SP2 32-bit Std. machine for a bit now, and I can't come up with a repro condition.
If you would, open the "Terminal Services Configuration" tool on the machine, highlight the "Connections" node in the left pane, and bring up the "Properties" of the "RDP-Tcp" object in the right pane. Have a look at the "Permissions" tab and see that "Remote Desktop Users" is granted "User Access" and "Guest Access" (the stock permission).
Failing that, I'm not sure w/o being able to repro it. What service pack level are you running of W2K3?
(BTW: I've got a similiar background to you-- I started on Unix and moved over to Windows grudgingly. Group Policy is incredibly useful once you get over the quirks. I script Windows machines like a mad man because I can't stand to do the same work more than once. The built-in Windows command shell is utterly inferior to any Unix shell, but it can be coaxed into performing most tasks...)
Edit:
Oh-- they're Windows XP machines. I didn't realize that. That changes things. I thought these were servers you were trying to access w/ RDP.
My psychic powers say that you're seeing the "You do not have access to logon to this session" message because there is someone already logged-on to the PC and the user logging-on with RDP doesn't have "Administrator" rights on the Windows XP machine. Windows XP can only host one RDP / console session at a time, and if someone is already logged-on only an "Administrator" user can remotely "bump them off" with RDP. All other users attempting to logon w/ RDP will receive the message you described above.
How does that look?
To investigate the "Restricted Groups" policy more, run the RSoP tool on the WinXP clients and see if there are any GPOs enforcing a "Restricted Groups" setting on "Remote Desktop Users". In a network I setup, for example, there would be. It's a common way to grant groups access to RDP on clients.
In the VPN settings in RRAS, you can change the policy to check that users are a member of a domain security group. Then you can simply add users and groups to give access. Everyone else is denied.
OUs are organisation units. Security groups allow access to resources. They serve different purposes. Sometimes it would be nice to treat OUs and groups the same but they arn't and it usually means that you are using them in a way that isn't as MS intended (which usually causes other problems later)
I'm not in front of an RRAS server so I can't detail the exact options, but I'll update this answer later if nobody else comes up with the steps.
Addn: Create a security group. Make sure users have 'Control access through Remote Access Policy' option selected on their Dial-in tab in Users and Computers. In Routing and Remote Access add a new remote access policy, and add to that conditions NAS-Port-Type matches 'Virtual (VPN)' to apply this to VPN connections and Windows-Groups matches 'DOMAIN\Group' substituting your domain and the new group.
Best Answer
NTFS is a bit odd (to some people) in that the same access bit does different things when set on directories than they do when set on files. If you have a structure like this on Server 2003:
To allow users to view the contents of the "config" directory, but not able to view the contents (just the metadata) of the "\" and "projectFour" directories, several things need to be done. I'm assuming that the users have no other rights that would grant them visiblity/access to the top of that share.
This rights setup, complicated though it is, will allow users the ability to get to the Config directory with a local drive-mapping to the share root. They will be able to enter the projectFour directory and view its directory listing information but no other data.
If you have it available, icacls makes this easier:
(oi) means "object inherit" which means, "apply to files".
(ci) means "container inherit" which means, "apply to directories".
(r) means "Read", when set directly on directories means, "allow users to read meta-data of this directory".
(rx) means "Read & Execute". As (r), but allow users to execute programs in this structure.
When used in conjunction with Access Based Enumeration (available, IIRC, on Server 2003 R2 and higher) users will only see directories and files they have access to. In the above case, users would only see "projectFour" under the root of the share, even if there were thirty other directories at the root.