Difference between revisions of "Roaming Windows User Profiles"

m (Mmuehlfeld moved page Implementing roaming profiles to Roaming Windows User Profiles: Rename to a better fitting title)
(Rewrote guide. Clearer structure, more detailed procedures, removed duplicate content, added new posibilities to assign profile paths (GPO), added profile version information, and several more things.)
Line 1: Line 1:
 
= Introduction =
 
= Introduction =
  
Roaming profiles are server side stored settings, that are "downloaded" to a Windows host when the user logs on and "uploaded" back to the server at log off. For more details about roaming profiles, see the same-titled section on the [[The_different_Windows_profile_types#Roaming_profiles|The different Windows profile types]] page.
+
A Windows profile is a set of files that contains all settings of a user including per-user configuration files and registry settings. In an Active Directory or NT4 domain you can set that the profile of a user is stored on a server. This enables the user to log on to different Windows domain members and use the same settings.
  
A roaming profile share can be setup in two ways: Using [[#Profile_share_using_Windows_ACLs|Windows ACLs]] (recommended) or via [[#Profile_share_using_POSIX_ACLs|POSIX ACLs]].
+
When using roaming user profiles, a copy of the profile is downloaded from the server to the Windows domain member when a user logs into. Until the user logs out, all settings are stored and updated in the local copy. During the log out, the profile is uploaded to the server.
  
  
  
= Creating a profiles share and setting permissions=
 
  
== Profile share using Windows ACLs ==
 
  
* Setup a share named "Profiles" according to the documentation [[Setting_up_a_Share_Using_Windows_ACLs]]
+
= Windows Roaming Profile Versions =
  
* Set the following ACLs on the root of the Profiles share according to [Setting_up_a_Share_Using_Windows_ACLs#Setting_Share_Permissions_and_ACLs|Setting Share Permissions and ACLs]].
+
Depending on the operating system version, Windows uses separate profile folders for a user to support Windows version-specific features. Version 2 profiles and later append the <code>.V*</code> suffix to the user's profile folder.
  
:* Click "Advanced" and then the "Change permissions" button for a more granular way to edit the share permissions
+
The following Windows profile versions exist:
  
::[[Image:Advanced_share_settings.png]]
+
:{| class="wikitable"
 +
!Windows Client OS Version
 +
!Windows Server OS Version
 +
!Profile Suffix
 +
!Example Profile Folder Name
 +
|-
 +
|Windows NT 4.0 - Windows Vista
 +
|Windows NT Server 4.0 - Windows Server 2008
 +
|''none''
 +
|user
 +
|-
 +
|Windows 7
 +
|Windows Server 2008 R2
 +
|V2
 +
|user.V2
 +
|-
 +
|Windows 8.0 - 8.1*
 +
|Windows Server 2012 - 2012 R2*
 +
|V3
 +
|user.V3
 +
|-
 +
|Windows 8.1*
 +
|Windows Server 2012 R2*
 +
|V4
 +
|user.V4
 +
|-
 +
|Windows 10
 +
|Windows Server 2016
 +
|V5
 +
|user.V5
 +
|}
  
:* Set the permissions as shown in the following table
+
: <nowiki>*</nowiki> Using the default settings, Windows 8.1 and Windows Server 2012 R2 use V3 profiles. However, the profiles are incompatible with Windows 8.0 and Windows Server 2012. For this reason it is recommended that you configure Windows 8.1 and Windows Server 2012 R2 to use V4 profiles. For further details, see: [https://support.microsoft.com/en-us/help/2890783/incompatibility-between-windows-8.1-roaming-user-profiles-and-those-in-earlier-versions-of-windows Incompatibility between Windows 8.1 roaming user profiles and those in earlier versions of Windows].
  
 +
When you set the profile path for a user, you always set the path without any version suffix. For example:
 +
\\server\profiles\user
 +
 +
 +
 +
 +
 +
= Setting up the Share on the Samba File Server =
 +
 +
== Using Windows ACLs ==
 +
 +
To create a share, for example <code>profiles</code>, for hosting the roaming profiles on a Samba file server:
 +
 +
* Create a new share. For details, see [[Setting up a Share Using Windows ACLs]]. Set the following permissions:
 +
 +
:* Share permissions:
 
::{| class="wikitable"
 
::{| class="wikitable"
!Name
+
!Principal
!Permissions
+
!Access
!Apply to
 
 
|-
 
|-
|Administrator
+
|Domain Users
|Full control
+
|Change
|This folder, subfolders and files
 
 
|-
 
|-
|Domain Users
+
|Domain Admins
|Traverse folder/execute file, List folder/read data, Create folder/append data
+
|Full Control
 +
|}
 +
 
 +
:* File system permissions on the root of the <code>users</code> share:
 +
 
 +
::{| class="wikitable"
 +
!Principal
 +
!Access
 +
!Applies to
 +
|- style="vertical-align:top;"
 +
|Domain Users*
 +
|Traverse folder / execute file<br />List folder / read data<br />Create folder / append data
 
|This folder only
 
|This folder only
 
|-
 
|-
Line 37: Line 90:
 
|Full control
 
|Full control
 
|Subfolders and files only
 
|Subfolders and files only
 +
|-
 +
|Domain Admins
 +
|Full control
 +
|This folder, subfolders and files
 
|}
 
|}
 +
::<nowiki>*</nowiki> You can alternatively set other groups, to enable the group members to store their user profile on the share. When using different groups, apply the permissions as displayed for <code>Domain Users</code> in the previous example.
 +
 +
:: Verify that permission inheritance is disabled on the root of the share. If any permission entry in the <code>Advanced Security Settings</code> window displays a path in the <code>Inherited from</code> column, click the <code>Disable inheritance</code> button. On Windows 7, unselect the <code>Include inheritable permissions from this object's parent</code> check box to set the same setting.
 +
 +
::[[Image:Profiles_Folder_File_System_ACLs.png]]
 +
 +
:: On a Samba share, you can omit the <code>SYSTEM</code> account in file system ACLs. For details, see [[The SYSTEM Account]].
  
:: On a Samba share, you can omit the <code>SYSTEM</code> account in the file system ACLs. For details, see [[The SYSTEM Account]].
+
These settings enable members of the <code>Domain Users</code> group to store their roaming profiles on the share, without being able to access other user's profiles. Members of the <code>Domain Admins</code> group are able to access all directories on the share.
  
::The above settings allow the auto-creation of new profile folders for users being member of "Domain users", but preventing them to access any profile of a different user. The domain administrator has full control on all profile folders.
 
  
::[[Image:Profile_share_permissions_for_group.png]]
 
  
:* Save the new permissions by closing the windows with "OK".
+
== Using POSIX ACLs ==
  
 +
Instead of using Windows access control lists (ACL), you can set up a share using POSIX ACLs on your Samba server. For example, to create the <code>profiles</code> share:
  
 +
{{Imbox
 +
| type = note
 +
| text = When setting up the share on a Samba Active Directory (AD) domain controller (DC), you cannot use POSIX ACLs. On an Samba DC, only shares using extended ACLs are supported. For further details, see [[Setting_up_a_Share_Using_Windows_ACLs#Enable_Extended_ACL_Support_in_the_smb.conf_File|Enable Extended ACL Support in the smb.conf File]]. To set up the share on a Samba AD DC, see [[#Using_Windows_ACLs|Setting up the Profiles Share on the Samba File Server - Using Windows ACLs]].
 +
}}
  
== Profile share using POSIX ACLs ==
+
* Add the following share configuration section to your <code>smb.conf</code> file:
  
* Create a folder for the roaming profiles and set the following ACLs
+
  [profiles]
 +
          path = /srv/samba/profiles/
 +
          read only = no
 +
          force create mode = 0600
 +
          force directory mode = 0700
 +
          store dos attributes = Yes
 +
          profile acls = yes
 +
          csc policy = disable
  
# mkdir -p /srv/samba/Profiles/
+
: For details about the parameters used, see the descriptions in the <code>smb.conf(5)</code> man page.
# chmod 1770 /srv/samba/Profiles/
 
# chgrp "Domain Users" /srv/samba/Profiles/
 
  
* Add the Profiles share to your smb.conf
+
* Create the directory and set permissions:
  
  [Profiles]
+
  # mkdir -p /srv/samba/profiles/
        path = /srv/samba/Profiles/
+
# chgrp -R "Domain Users" /srv/samba/profiles/
        read only = no
+
# chmod 2750 /srv/samba/profiles/
        store dos attributes = Yes
 
        create mask = 0600
 
        directory mask = 0700
 
        profile acls = yes
 
        csc policy = disable
 
  
:See the smb.conf man page for further details on the uses parameters.
+
: These settings enable members of the <code>Domain Users</code> group to store their roaming profiles on the share, without being able to access other user's profiles. Alternatively, you can set a different group.
  
 
* Reload Samba:
 
* Reload Samba:
Line 78: Line 145:
  
  
= Setting roaming profiles for a user =
+
= Assigning a Roaming Profile to a User =
  
== In an AD environment ==
+
Depending on the Windows version, Windows uses different folders to store the roaming profile of a user. However, when you set the profile path for a user, you always set the path to the folder without any version suffix. For example:
 +
\\server\profiles\user
  
In an AD environment, you can setup individual roaming profiles for every user.
+
For further details, see [[#The_Windows_Roaming_Profile_Versions|The Windows Roaming Profile Versions]].
  
* Open ADUC
+
Note that you must not set a trailing backslash.
  
* Right-click to an user account and choose "Properties"
 
  
* Go to the "Profile" tab and fill the path with the one to the users profile
 
  
:[[Image:ADUC_profile_share.png]]
 
  
:Using the windows variable %USERNAME% allows setting profile paths on multiple accounts at once
 
  
:Note: Newer Windows version use different profile versions, that are indicated by an appended .V* (like username.V5 for Windows 10 profiles). You only fill the path to the users base profile folder here. The version is appended automatically by Windows!
+
== In an Active Directory ==
  
 +
=== Using <code>Active Directory Users and Computers</code> ===
  
 +
In an Active Directory, you can use the <code>Active Directory Users and Computers</code> Windows application to set the path to the user's profile folder. If you do not have the Remote Server Administration Tools (RSAT) installed, see [[Installing RSAT|Installing RSAT]].
  
== In a NT4 domain ==
+
To assign <code>\\server\profiles\demo\</code> as profile folder to the <code>demo</code> account:
  
In a NT4 environment, you can only setup roaming profiles globally for all users on the Samba PDC.
+
* Log in to a computer using an account that is enabled to edit user accounts.
  
* Add the following directive to your smb.conf:
+
* Open the <code>Active Directory Users and Computers</code> application.
  
logon path = \\%L\Profiles\%U
+
* Navigate to the directory container that contains the <code>demo</code> account.
 +
 
 +
* Right-click to the <code>demo</code> user account and select <code>Properties</code>.
 +
 
 +
* Select the <code>Profile</code> tab.
 +
 
 +
* Fill the path to the home folder into the <code>Profile path</code> field.
 +
: Set the path always without any profile version suffix and without trailing backslash. For details, see [[#The_Windows_Roaming_Profile_Versions|The Windows Roaming Profile Versions]].
 +
 
 +
:[[Image:ADUC_Set_Profile_Folder.png]].
 +
 
 +
* Click <code>OK</code>.
 +
 
 +
The setting is applied the next time the user logs in.
 +
 
 +
 
 +
 
 +
=== Using a Group Policy Object ===
 +
 
 +
Using group policy objects (GPO), you can assign settings to organizational units (OU) or to a domain. This enables you, for example, to automatically assign profile paths to all users that log on to a computer that is a member of the OU or domain. If you move the computer to a different OU or domain, the setting is removed or updated. Using this way, you do not have to assign manually the settings to each user account.
 +
 
 +
{{Imbox
 +
| type = note
 +
| text = Windows only supports assiging a profile path using GPOs on a per-computer basis. This means that the path is also applied to local users on domain members, which have no access to the profile share. To set the profile path on a per-user basis, see [[#Using_Active_Directory_Users_and_Computers|Using Active Directory Users and Computers]].
 +
}}
 +
 
 +
To create a group policy object (GPO) for the domain that automatically assigns the <code>\\server\path\''user_name''</code> path to every user that logs on to a Windows domain member:
 +
 
 +
* Log in to a computer using an account that is allowed to edit group policies, such as the AD domain <code>Administrator</code> account.
 +
 
 +
* Open the <code>Group Policy Management Console</code>. If you are not having the Remote Server Administration Tools (RSAT) installed on this computer, see [[Installing RSAT|Installing RSAT]].
 +
 
 +
* Right-click to your AD domain and select <code>Create a GPO in this domain, and Link it here</code>.
 +
 
 +
:[[Image:GPMC_Create_GPO.png]]
 +
 
 +
* Enter a name for the GPO, such as <code>Profiles on ''server''</code>. The new GPO is shown below the domain entry.
 +
 
 +
* Right-click to the newly-created GPO and select <code>Edit</code> to open the <code>Group Policy Management Editor</code>.
 +
 
 +
* Navigate to the <code>Computer Configuration</code> &rarr; <code>Policies</code> &rarr; <code>Administrative Templates</code> &rarr; <code>System</code> &rarr; <code>User Profiles</code> entry.
 +
 
 +
* Double-click the <code>Set roaming profile path for all users logging onto this computer</code> policy to edit:
 +
 
 +
:* Enable the policy and set the profile path. For example:
 +
 
 +
\\server\profiles\%USERNAME%
 +
 
 +
:: Windows replaces the <code>%USERNAME%</code> variable with the user name during login. Set the path without trailing backslash.
 +
 
 +
::[[Image:GPME_Set_Profiles_Properties.png]]
 +
 
 +
:* Click <code>OK</code>.
 +
 
 +
* Close the <code>Group Policy Management Editor</code>. The GPOs are automatically saved on the <code>Sysvol</code> share on the domain controller (DC).
 +
 
 +
* Close the <code>Group Policy Management Console</code>.
 +
 
 +
The GPO is applied at the next reboot of the Windows domain members or when they reload the group policies.
 +
 
 +
 
 +
 
 +
=== Using <code>ldbedit</code> on a Domain Controller ===
 +
 
 +
On a domain controller (DC), to assign, for example, the <code>\\server\profiles\demo\</code> path as profile folder to the <code>demo</code> account:
 +
 
 +
* Edit the <code>demo</code> user account:
 +
 
 +
# ldbedit -H /usr/local/samba/private/sam.ldb 'sAMAccountName=demo'
 +
 
 +
* The accounts attributes are displayed in an editor. Append the following attribute and value to the end of the list:
 +
 
 +
profilePath: \\server\profiles\demo
 +
 
 +
: You must not set a trailing backslash to the path.
 +
 
 +
* Save the changes.
  
:The logon path directive is where you actually set up roaming profiles. This directive should contain a Windows network path to the location of the profile for each user. If the users profile directory does not exist, it will be created on that location (as long as the user has write access to that directory).
+
The setting is applied the next time the user logs in.  
  
:You can also take full advantage of Samba's variable substitutions (see the "variable substitutions" section of the smb.conf man page).
 
  
* Reload Samba:
 
# smbcontrol all reload-config
 
  
 +
== In an NT4 Domain ==
  
 +
In an Samba NT4 domain, to set <code>\\server\users\%U</code> as path to the profile folder:
  
 +
* Add the following parameter to the <code>[global]</code> section in your <code>smb.conf</code> file:
  
 +
logon path = \\%L\Profiles\%U
  
= Troubleshooting roaming profiles =
+
: During logging in to the domain member, Samba automatically replaces the <code>%U</code> variable with the session user name. For further details, see the <code>Variable Substitutions</code> section in the <code>smb.conf(5)</code> man page.
  
The registry contains information about each user's profile and should your Samba infrastructure change, like the network location of users profiles, Windows might be unable to find it. The list of user profiles is located at:
+
* Reload Samba:
  
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ProfileList
+
# smbcontrol all reload-config
  
Deleting the correct subkey (user SID) will force Windows to look up the user's profile setting from the domain controller and restore the profile when the next login happens.
 
  
  
  
  
 +
= Configuring Windows Profile Folder Redirections =
  
----
+
See [[Configuring Windows Profile Folder Redirections]].
[[Category:Active Directory]]
 
[[Category:Domain Members]]
 
[[Category:File Serving]]
 
[[Category:NT4 Domains]]
 

Revision as of 01:05, 11 March 2017

Introduction

A Windows profile is a set of files that contains all settings of a user including per-user configuration files and registry settings. In an Active Directory or NT4 domain you can set that the profile of a user is stored on a server. This enables the user to log on to different Windows domain members and use the same settings.

When using roaming user profiles, a copy of the profile is downloaded from the server to the Windows domain member when a user logs into. Until the user logs out, all settings are stored and updated in the local copy. During the log out, the profile is uploaded to the server.



Windows Roaming Profile Versions

Depending on the operating system version, Windows uses separate profile folders for a user to support Windows version-specific features. Version 2 profiles and later append the .V* suffix to the user's profile folder.

The following Windows profile versions exist:

Windows Client OS Version Windows Server OS Version Profile Suffix Example Profile Folder Name
Windows NT 4.0 - Windows Vista Windows NT Server 4.0 - Windows Server 2008 none user
Windows 7 Windows Server 2008 R2 V2 user.V2
Windows 8.0 - 8.1* Windows Server 2012 - 2012 R2* V3 user.V3
Windows 8.1* Windows Server 2012 R2* V4 user.V4
Windows 10 Windows Server 2016 V5 user.V5
* Using the default settings, Windows 8.1 and Windows Server 2012 R2 use V3 profiles. However, the profiles are incompatible with Windows 8.0 and Windows Server 2012. For this reason it is recommended that you configure Windows 8.1 and Windows Server 2012 R2 to use V4 profiles. For further details, see: Incompatibility between Windows 8.1 roaming user profiles and those in earlier versions of Windows.

When you set the profile path for a user, you always set the path without any version suffix. For example:

\\server\profiles\user



Setting up the Share on the Samba File Server

Using Windows ACLs

To create a share, for example profiles, for hosting the roaming profiles on a Samba file server:

  • Share permissions:
Principal Access
Domain Users Change
Domain Admins Full Control
  • File system permissions on the root of the users share:
Principal Access Applies to
Domain Users* Traverse folder / execute file
List folder / read data
Create folder / append data
This folder only
CREATOR OWNER Full control Subfolders and files only
Domain Admins Full control This folder, subfolders and files
* You can alternatively set other groups, to enable the group members to store their user profile on the share. When using different groups, apply the permissions as displayed for Domain Users in the previous example.
Verify that permission inheritance is disabled on the root of the share. If any permission entry in the Advanced Security Settings window displays a path in the Inherited from column, click the Disable inheritance button. On Windows 7, unselect the Include inheritable permissions from this object's parent check box to set the same setting.
Profiles Folder File System ACLs.png
On a Samba share, you can omit the SYSTEM account in file system ACLs. For details, see The SYSTEM Account.

These settings enable members of the Domain Users group to store their roaming profiles on the share, without being able to access other user's profiles. Members of the Domain Admins group are able to access all directories on the share.


Using POSIX ACLs

Instead of using Windows access control lists (ACL), you can set up a share using POSIX ACLs on your Samba server. For example, to create the profiles share:

  • Add the following share configuration section to your smb.conf file:
 [profiles]
         path = /srv/samba/profiles/
         read only = no
         force create mode = 0600
         force directory mode = 0700
         store dos attributes = Yes
         profile acls = yes
         csc policy = disable
For details about the parameters used, see the descriptions in the smb.conf(5) man page.
  • Create the directory and set permissions:
# mkdir -p /srv/samba/profiles/
# chgrp -R "Domain Users" /srv/samba/profiles/
# chmod 2750 /srv/samba/profiles/
These settings enable members of the Domain Users group to store their roaming profiles on the share, without being able to access other user's profiles. Alternatively, you can set a different group.
  • Reload Samba:
# smbcontrol all reload-config



Assigning a Roaming Profile to a User

Depending on the Windows version, Windows uses different folders to store the roaming profile of a user. However, when you set the profile path for a user, you always set the path to the folder without any version suffix. For example:

\\server\profiles\user

For further details, see The Windows Roaming Profile Versions.

Note that you must not set a trailing backslash.



In an Active Directory

Using Active Directory Users and Computers

In an Active Directory, you can use the Active Directory Users and Computers Windows application to set the path to the user's profile folder. If you do not have the Remote Server Administration Tools (RSAT) installed, see Installing RSAT.

To assign \\server\profiles\demo\ as profile folder to the demo account:

  • Log in to a computer using an account that is enabled to edit user accounts.
  • Open the Active Directory Users and Computers application.
  • Navigate to the directory container that contains the demo account.
  • Right-click to the demo user account and select Properties.
  • Select the Profile tab.
  • Fill the path to the home folder into the Profile path field.
Set the path always without any profile version suffix and without trailing backslash. For details, see The Windows Roaming Profile Versions.
ADUC Set Profile Folder.png.
  • Click OK.

The setting is applied the next time the user logs in.


Using a Group Policy Object

Using group policy objects (GPO), you can assign settings to organizational units (OU) or to a domain. This enables you, for example, to automatically assign profile paths to all users that log on to a computer that is a member of the OU or domain. If you move the computer to a different OU or domain, the setting is removed or updated. Using this way, you do not have to assign manually the settings to each user account.

To create a group policy object (GPO) for the domain that automatically assigns the \\server\path\user_name path to every user that logs on to a Windows domain member:

  • Log in to a computer using an account that is allowed to edit group policies, such as the AD domain Administrator account.
  • Open the Group Policy Management Console. If you are not having the Remote Server Administration Tools (RSAT) installed on this computer, see Installing RSAT.
  • Right-click to your AD domain and select Create a GPO in this domain, and Link it here.
GPMC Create GPO.png
  • Enter a name for the GPO, such as Profiles on server. The new GPO is shown below the domain entry.
  • Right-click to the newly-created GPO and select Edit to open the Group Policy Management Editor.
  • Navigate to the Computer ConfigurationPoliciesAdministrative TemplatesSystemUser Profiles entry.
  • Double-click the Set roaming profile path for all users logging onto this computer policy to edit:
  • Enable the policy and set the profile path. For example:
\\server\profiles\%USERNAME%
Windows replaces the %USERNAME% variable with the user name during login. Set the path without trailing backslash.
GPME Set Profiles Properties.png
  • Click OK.
  • Close the Group Policy Management Editor. The GPOs are automatically saved on the Sysvol share on the domain controller (DC).
  • Close the Group Policy Management Console.

The GPO is applied at the next reboot of the Windows domain members or when they reload the group policies.


Using ldbedit on a Domain Controller

On a domain controller (DC), to assign, for example, the \\server\profiles\demo\ path as profile folder to the demo account:

  • Edit the demo user account:
# ldbedit -H /usr/local/samba/private/sam.ldb 'sAMAccountName=demo'
  • The accounts attributes are displayed in an editor. Append the following attribute and value to the end of the list:
profilePath: \\server\profiles\demo
You must not set a trailing backslash to the path.
  • Save the changes.

The setting is applied the next time the user logs in.


In an NT4 Domain

In an Samba NT4 domain, to set \\server\users\%U as path to the profile folder:

  • Add the following parameter to the [global] section in your smb.conf file:
logon path = \\%L\Profiles\%U
During logging in to the domain member, Samba automatically replaces the %U variable with the session user name. For further details, see the Variable Substitutions section in the smb.conf(5) man page.
  • Reload Samba:
# smbcontrol all reload-config



Configuring Windows Profile Folder Redirections

See Configuring Windows Profile Folder Redirections.