Friday, July 25, 2014

Citrix / Terminal Server Profile Folders, and why you may not get the results you expect from a NAS

After struggling with permissions issues in a Citrix profile environment for some considerable time, I think I know what is going on. Note, this summary does not cover technologies like Citrix's User Profile Manager (UPM).

Take the following structure:

If you follow best practice, the NTFS permissions on E:\TSUSers would be set thus:

       E:\TSUsers

          • Administrators      [Full Control]
          • System              [Full Control]
          • Creator/Owner       [Full Control]
          • Authenticated Users [Special]
            • Scope: 'This Folder Only'
            • List Folder / Read Data
            • Create Folders / Append Data

This arrangement ensures that the users can only see their own profile folder. Specifically, the 'Creator/Owner' permission provides a user access to their own profile, and the 'special' permission allows a new user to create their profile folder when they log in for the first time.

The fun starts when we need to do any maintenance. Imagine a new user named 'Fred' logs on for the first time. By design, when Microsoft Terminal Services creates the new folder, it switches the inheritance flag off on that new user folder, leaving only the following 'System' permission and adding the user's permission, thus:
  • System              [Full Control]
  • DomainName>\Fred    [Full Control]
In the real world, it is a standard troubleshooting step to delete a profile folder, and have the user recreate it by logging on. You can see that there is no administrative account on that ACL, so the administrator of the server would have to seize ownership and give themselves permission in order to delete the folder.

Micrsoft's partial solution is to set the following group policy setting:

Add the Administrators security group to roaming user profiles:
Computer Configuration\Administrative Templates\System\User Profiles

Here are Microsoft's words:
When a new roaming profile directory is created, Windows disables permission inheritance and grants SYSTEM and the profile’s user account full control. That makes user profiles inaccessible to administrators which prevents them from performing maintenance. If this policy setting is enabled the group “Administrators” is given full control on new profile folders. Note that this applies to new profiles only. Profiles created before this policy settings was in place lack the entry for “Administrators”.

So that's all fine, but what if your help desk needs to perform this troubleshooting step and they are not administrators on the server? You may have wasted your time setting up the permissions on the TSUsers folder thus:

  • Administrators      [Full Control]
  • ProfileAdmins       [Full Control]
  • System              [Full Control]
  • Creator/Owner       [Full Control]
  • Authenticated Users [Special] Scope: 'This Folder Only'
    • List Folder / Read Data
    • Create Folders / Append Data
In this scenario, you added an additional AD group to the ACL 'ProfileAdmins' which contains your help desk staff, but any new user profile created will not inherit that ACL and thus the group is useless.

You have three choices:

  1. Run a script periodically that re-ACLs the profile folders to allow the 'ProfileAdmins' group to have rights on the folders. This may be challenging in a troubleshooting scenario, since your help desk staff might want to delete and recreate the folder multiple times in short succession. (I include an example script at the end of this article).
  2. Allow your help desk staff to be administrators on the server, perhaps you might feel OK about that, if the server was dedicated to this one task.
  3. Use a more mature product such as Citrix Profile Manager.
So what has all this got to do with a NAS device?
  • Whatever emulation the NAS box uses to simulate NTFS, will have to understand 'special' ACLs as described above. In my experience, this varies from vendor to vendor and there is a minefield of variance with CIFS, SAMBA versions, EMC's Isilon etc.
  • Option (1) above is not really an option without engaging your storage team to write something that runs on the NAS OS (typically a UNIX OS).
  • Option (3) above is not really an option since it would require some kind of admin privilege on the NAS OS.
So, to sum up, no magic answers here. Just a technology you have to live with.

Cheers!

No comments:

Post a Comment