locked
Why do roaming profiles exclude domain admin access? RRS feed

  • Question

  • This is a question for the Microsoft support people. Why do roaming profiles by default get set up with account folder security that excludes access rights for domain administrators?

    Why is it an extra and special step to allow domain administrators access to user folders, through group policy?

    I am dealing with some weird permissions problems for some roaming profiles, where for some reason the only Administrator owns their NTUSER.DAT so their profile never logs off properly, yet the containing folder itself only allows the user access to their profile.

    I find it exceptionally irritating that the Domain Admin can't even view the Security permissions on a User's profile, without:

    1. Taking ownership of the user's profile
    2. Assigning Domain Admins access to the object
    3. Reassigning the user as owner of their profile

    It just seems moronic for the network administrator to have to deal with this. At this point it's unclear to me if the domain accounts were just set up wrong on the first place and this isn't really how things are supposed to work.

    What's the point of excluding the domain admin from accessing user accounts? If the domain admin can't have access by Microsoft's default account security permissions, then who?

    Also I suppose I should mention that UAC is active on the domain controllers and file servers... which may be part of these weird security limitations on what the domain administrators can do with user accounts.

    Seems odd for the domain administrator to be denied being able to do pretty much anything they want regardless of permissions, basically.

     

    Tuesday, January 10, 2012 7:50 PM

All replies

  • Hi,

    this is by design. Here is no Group Policy for adding Administrator to Roaming Profile Folder:

    http://social.technet.microsoft.com/Forums/hu-HU/winserverfiles/thread/92a6d067-4516-4ac5-82d2-e7f46364bc04
    

     


    This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Microsoft Student Partner 2010 / 2011 / 2012
    Microsoft Certified Professional | Connected Home Integrator | Consumer Sales Specialist
    Microsoft Certified IT Professional: Consumer Support Technician on Windows Vista
    Microsoft Certified IT Professional: Enterprise Support Technician on Windows Vista
    Microsoft Certified IT Professional: Server Administrator on Windows Server 2008
    Microsoft Certified Technology Specialist:
    Windows 7, Configuration | Microsoft Windows Vista, Configuration
    Pre-Installing Windows 7 for OEMs | Windows 7 and Office 2010, Deployment | Windows Vista and Server Operating Systems, Preinstallation
    Windows Server 2008 Active Directory, Conf | Windows Server 2008 Network Infrastructure, Conf | Windows Server 2008 Applications Infrastructure, Conf
    Windows Server 2008 R2, Servaer Virtualization | Windows Server Virtualization, Configuration | Microsoft Lync Server 2010, Configuring
    Windows SBS 2011, Configuring | Windows EBS 2008, Configuration | Windows SBS 2008, Configuration
    Windows HPC Server 2008, Development | Windows Internals | MDOP, Configuration | SharePoint 2010, Configuration
    Microsoft SCOM, Configuration | Microsoft SCDPM 2007, Configuration | Microsoft SCVMM 2008, Configuration

    • Proposed as answer by Jiří Janata Tuesday, January 10, 2012 10:26 PM
    Tuesday, January 10, 2012 10:17 PM
  • > What's the point of excluding the domain admin from accessing user
    > accounts? If the domain admin can't have access by Microsoft's default
    > account security permissions, then who?
     
    Profiles may contain sensitive data (like homesets do), and NOT granting
    Admins access to the profile directory protects this data.
     
    Nothing weird about that...
     
    sincerely, Martin
     

    A bissle "Experience", a bissle GMV... Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Wednesday, January 11, 2012 8:35 AM
  • Hi,

    Based on my experience and research, if we haven't enabled the policy "Add the Administrators security group to roaming user profiles" before the users roaming profile being created, administrator should have to take the ownership of the roaming profile to be able to manage and access users roaming profile.

    But if we enabled the policy before the user roaming profile was created, administrator could access those users profile.

    By default, domain admins don't have right to access users roaming profiles. This is by design, as users should have personal files.

    Best Regards,

    Yan Li


    Yan Li

    TechNet Community Support

    Monday, January 16, 2012 7:21 AM
  • Profiles may contain sensitive data (like homesets do), and NOT granting
    Admins access to the profile directory protects this data.
     
    Nothing weird about that...
    This "security" is an illusion due to the ability of the Domain Admin to Take Ownership, access whatever is needed, and then reassign the user as the owner of the files. What were we trying to prevent here?

    It basically comes down to a child drawing a line in the sand at the beach and saying "nyah nyah you can't cross this". Denying access is a pointless and unnecessary encumbrance on the ability of a network administrator to just simply do their job of fixing problems and making sure it's all working properly.

    If an organization does not trust a network administrator to have access to everyone's documents, hey guess what, they should not be giving that person that power in the first place.


    Tuesday, January 17, 2012 4:01 PM
  • This "security" is an illusion due to the ability of the Domain Admin to Take Ownership
    Actually, getting around the problem by making the administrator Domain Admin is also an illusion.  The only time an administrator cares is when a user says oops!, and needs a restore.  Then it's too late because the administrator did not have access when the backup was taken.  Since the user has no visibility from the client to restore from a shadow, nor the rights to restore at the server level, the user can't restore his own desktop either.

    There is only one way that works, and that is to make the user administrator, log into the server.  Then you don't have to take ownership.  This also means that the user either needs to give you his password, or he has to log into the server, or you need to tell the user what you will reset his password to, so he can log in and change it.  If you work remotely, you also need to add him to Remote Desktop, since his account was set up without using the Administrator template.  Perhaps the best way to do this is to make the Group Policy change part of your best practices.

    Monday, February 27, 2012 8:55 PM