Published
Apr 10 2019 03:17 AM
2,357
Views
First published on TECHNET on Oct 09, 2013
To continue the blog post series on Work Folders, I’d like to talk about how to manage a new attribute storing the Sync Server Url as part of the user object in Active Directory Domain Services (AD DS). If you have seen the demo of the client setup in this video [00:08:20], it shows that a user can simply use their email address to configure Work Folders. The magic here is to use the user email address to construct a Url that a Work Folders client can query from the sync server.
For example, if the user email is Joe@contoso.com, the Work Folders client will build the Url as https://workfolders.contoso.com, and use that as the Url to establish the communication with the Work Folders server. The server then queries AD DS for the new user attribute to figure out the server location of the user. This process is called auto-discovery.
This makes it so that the only data users need to know to set up Work Folders is their email address. Admins can simply configure the user attribute. When a user needs to be moved to another server, the admin can just update the user attribute, and remove user access to the old server. At this point, the user is automatically redirected to the new server. Auto-discovery can make client set up really simple when multiple sync servers are deployed.
Although this attribute makes discovery really simple, it is not a must-have attribute. There are a couple of cases you won’t need to configure this attribute or extend the schema to use it.
I’m not going to get too deep with the discovery process in this post – instead I’ll focus on the management of this new attribute: msDS-SyncServerUrl .
Note: The msDS-SyncServerURL attribute in Active Directory should not be defined for remote users that are accessing Work Folders through a reverse proxy solution such as Web Application Proxy or Azure AD Application Proxy. If the msDS-SyncServerURL property is defined, the Work Folders client will try to access an internal URL that's not accessible through the reverse proxy solution. When using Web Application Proxy or Azure AD Application Proxy, you need to create unique proxy applications for each Work Folders server. For more details, see Deploying Work Folders with AD FS and Web Application Proxy: Overview or Deploying Work Folders with Azure AD Application Proxy .
The new attribute is included in AD DS with Windows Server 2012 R2, but you don’t need to upgrade the domain controller to get this. If you are running a previous released version of Windows Server, you can simply run ADprep.exe on any Windows Server 2012 R2 member servers to extend this attribute in the AD schema. For more information about adprep, take a look at this http://technet.microsoft.com/en-us/library/dd464018(v=WS.10).aspx
By default, only members of the Domain Admins or the Enterprise Admins group can modify the user attribute. For Work Folders management, the file server admins should have permissions to modify the user attribute.
Let’s take a look at how you could accomplish this.
1. In Active Directory Administration Center, create a file server admin security group (for example, fsadmin).
2. Launch the Delegation of Control Wizard by right-clicking the domain root node.
3. Add FSadmins to the wizard:
4. Select the option to create a custom task to delegate:
5. Select the option to delegate control to only user objects:
6. Specify the msDS- SyncServerUrl as the property to be managed by FSAdmins:
7. Complete the wizard.
DsAcls.exe is a tool you can use to modify the permissions on the user object for a given attribute. To do the same delegation, you can run the following cmd:
DsAcls dc=contoso,dc=com /I:S /G "Contoso\FSAdmin:RPWP;msDS-SyncServerUrl;user"
In the cmd line above, it enables Contoso\FSAdmin group to Read and Write on the user attribute “msDS-SyncServerUrl”. You can change the FSAdmin to the security group name you have created to manage this user attribute.
1. Since the ACL will be applied to existing user objects, the operation may take a while if there is a large number of user objects present in the domain.
2. If you have multiple domains in the forest, you need to repeat the steps to delegate the permission for each domain.
3. After the delegation, all members in FSAdmin will be able to modify the mSDS-SyncServerUrl attribute of the (new or existing) user object.
Now that the FSAdmins have permissions to modify the msDS-SyncServerUrl, they can change the value of this attribute using a number of ways:
1. Open the ADSI Edit from the Server Manager -> Tools menu.
2. Connect to the Default naming context by right-clicking the ADSI Edit node, and then selecting Connect to…
3. Select the user, right-click the user object, and then click Properties:
4. Navigate to the msDS-SyncServerUrl property, and click Edit:
5. Enter the Url value for this user, click Add, and then OK.
You can use Set-ADObject cmdlet to set the user property:
Get-AdUser <username> | Set-ADObject –Replace @{"msDS-SyncServerUrl" = "<Url String>"}
For example, I can use the following cmdlet to set the attribute for user “Sally”:
Get-ADUser Sally | Set-ADObject –Replace @{"msDS-SyncServerUrl"="https://sync1.contoso.com"}
You can also verify the setting by running the following cmdlet:
Get-ADUser Sally | Get-ADObject –Properties "msDS-SyncServerUrl"
If you are familiar with using ldf files to manage AD objects, you can also create the ldf file to do the same as above:
dn: CN=Sally,CN=Users,DC=Contoso,DC=COM
changetype: modify
add: msDS-SyncServerUrl
msDS-SyncServerUrl: https://sync1.contoso.com
-
After the Work Folders server authenticates the user, the server will query the user attribute using “local system” account. If the server fails to query AD DS, it will log an event on the server. Below are some troubleshooting tips:
1. Check the network: see if the server has network access to a domain controller (DC).
2. Check the status of AD DS: make sure the AD DS is healthy and that a DC is online.
3. Check whether the file server has read permissions to the attribute.
By default, file servers have read permissions to the user attributes in the AD DS. In some deployments, however, IT admins may have explicitly blocked it, and the query will fail. The steps below will show you how to verify whether the server has read permission to this user attribute:
1. Open ADSIEdit
2. Right click on “ADSI Edit”, and select “ Connect to… ”
3. Select “ Schema ” naming context:
4. Find the ms-DS-SyncServerUrl attribute, and open the properties page:
5. Go to the “ Security” page, and click on “ Advanced ”
6. Go to the “Effective Access” page, and click on “ Select a user”, make sure Computers is checked below:
7. Enter the sync server name in the object picker, then click on “ View effective access” button:
8. Make sure the sync server’s machine account can read the user properties:
On clusters, check the machine account for the cluster nodes - not the cluster VCO, as the access is done using the local system account of the physical machines.
The following are related resources about Work Folders:
Work Folders Overview
Introduction of Work Folders on Windows Server 2012 R2
Work Folders Test lab deployment
Certificate management for Work Folders
Overview
To continue the blog post series on Work Folders, I’d like to talk about how to manage a new attribute storing the Sync Server Url as part of the user object in Active Directory Domain Services (AD DS). If you have seen the demo of the client setup in this video [00:08:20], it shows that a user can simply use their email address to configure Work Folders. The magic here is to use the user email address to construct a Url that a Work Folders client can query from the sync server.
For example, if the user email is Joe@contoso.com, the Work Folders client will build the Url as https://workfolders.contoso.com, and use that as the Url to establish the communication with the Work Folders server. The server then queries AD DS for the new user attribute to figure out the server location of the user. This process is called auto-discovery.
This makes it so that the only data users need to know to set up Work Folders is their email address. Admins can simply configure the user attribute. When a user needs to be moved to another server, the admin can just update the user attribute, and remove user access to the old server. At this point, the user is automatically redirected to the new server. Auto-discovery can make client set up really simple when multiple sync servers are deployed.
Although this attribute makes discovery really simple, it is not a must-have attribute. There are a couple of cases you won’t need to configure this attribute or extend the schema to use it.
- If you have a single server deployment, the user will get a valid sync share when querying the sync server.
- If you want to manage the users per sync server. I.e. send a server Url to the user, so the user will connect to the server directly without going through auto-discovery.
I’m not going to get too deep with the discovery process in this post – instead I’ll focus on the management of this new attribute: msDS-SyncServerUrl .
Note: The msDS-SyncServerURL attribute in Active Directory should not be defined for remote users that are accessing Work Folders through a reverse proxy solution such as Web Application Proxy or Azure AD Application Proxy. If the msDS-SyncServerURL property is defined, the Work Folders client will try to access an internal URL that's not accessible through the reverse proxy solution. When using Web Application Proxy or Azure AD Application Proxy, you need to create unique proxy applications for each Work Folders server. For more details, see Deploying Work Folders with AD FS and Web Application Proxy: Overview or Deploying Work Folders with Azure AD Application Proxy .
Schema extension
The new attribute is included in AD DS with Windows Server 2012 R2, but you don’t need to upgrade the domain controller to get this. If you are running a previous released version of Windows Server, you can simply run ADprep.exe on any Windows Server 2012 R2 member servers to extend this attribute in the AD schema. For more information about adprep, take a look at this http://technet.microsoft.com/en-us/library/dd464018(v=WS.10).aspx
Delegation
By default, only members of the Domain Admins or the Enterprise Admins group can modify the user attribute. For Work Folders management, the file server admins should have permissions to modify the user attribute.
Let’s take a look at how you could accomplish this.
Using UI
1. In Active Directory Administration Center, create a file server admin security group (for example, fsadmin).
2. Launch the Delegation of Control Wizard by right-clicking the domain root node.
3. Add FSadmins to the wizard:
4. Select the option to create a custom task to delegate:
5. Select the option to delegate control to only user objects:
6. Specify the msDS- SyncServerUrl as the property to be managed by FSAdmins:
7. Complete the wizard.
Using cmdline
DsAcls.exe is a tool you can use to modify the permissions on the user object for a given attribute. To do the same delegation, you can run the following cmd:
DsAcls dc=contoso,dc=com /I:S /G "Contoso\FSAdmin:RPWP;msDS-SyncServerUrl;user"
In the cmd line above, it enables Contoso\FSAdmin group to Read and Write on the user attribute “msDS-SyncServerUrl”. You can change the FSAdmin to the security group name you have created to manage this user attribute.
A few notes
1. Since the ACL will be applied to existing user objects, the operation may take a while if there is a large number of user objects present in the domain.
2. If you have multiple domains in the forest, you need to repeat the steps to delegate the permission for each domain.
3. After the delegation, all members in FSAdmin will be able to modify the mSDS-SyncServerUrl attribute of the (new or existing) user object.
Modify user attribute
Now that the FSAdmins have permissions to modify the msDS-SyncServerUrl, they can change the value of this attribute using a number of ways:
Using the UI
1. Open the ADSI Edit from the Server Manager -> Tools menu.
2. Connect to the Default naming context by right-clicking the ADSI Edit node, and then selecting Connect to…
3. Select the user, right-click the user object, and then click Properties:
4. Navigate to the msDS-SyncServerUrl property, and click Edit:
5. Enter the Url value for this user, click Add, and then OK.
Using Windows PowerShell
You can use Set-ADObject cmdlet to set the user property:
Get-AdUser <username> | Set-ADObject –Replace @{"msDS-SyncServerUrl" = "<Url String>"}
For example, I can use the following cmdlet to set the attribute for user “Sally”:
Get-ADUser Sally | Set-ADObject –Replace @{"msDS-SyncServerUrl"="https://sync1.contoso.com"}
You can also verify the setting by running the following cmdlet:
Get-ADUser Sally | Get-ADObject –Properties "msDS-SyncServerUrl"
Using an Ldf file
If you are familiar with using ldf files to manage AD objects, you can also create the ldf file to do the same as above:
dn: CN=Sally,CN=Users,DC=Contoso,DC=COM
changetype: modify
add: msDS-SyncServerUrl
msDS-SyncServerUrl: https://sync1.contoso.com
-
Troubleshooting
After the Work Folders server authenticates the user, the server will query the user attribute using “local system” account. If the server fails to query AD DS, it will log an event on the server. Below are some troubleshooting tips:
1. Check the network: see if the server has network access to a domain controller (DC).
2. Check the status of AD DS: make sure the AD DS is healthy and that a DC is online.
3. Check whether the file server has read permissions to the attribute.
Checking for server permission
By default, file servers have read permissions to the user attributes in the AD DS. In some deployments, however, IT admins may have explicitly blocked it, and the query will fail. The steps below will show you how to verify whether the server has read permission to this user attribute:
1. Open ADSIEdit
2. Right click on “ADSI Edit”, and select “ Connect to… ”
3. Select “ Schema ” naming context:
4. Find the ms-DS-SyncServerUrl attribute, and open the properties page:
5. Go to the “ Security” page, and click on “ Advanced ”
6. Go to the “Effective Access” page, and click on “ Select a user”, make sure Computers is checked below:
7. Enter the sync server name in the object picker, then click on “ View effective access” button:
8. Make sure the sync server’s machine account can read the user properties:
On clusters, check the machine account for the cluster nodes - not the cluster VCO, as the access is done using the local system account of the physical machines.
Related links
The following are related resources about Work Folders:
Work Folders Overview
Introduction of Work Folders on Windows Server 2012 R2
Work Folders Test lab deployment
Certificate management for Work Folders