On login, MyWorkDrive conducts a real-time lookup in Active Directory for a user's group membership and matches that up with the configuration in shares in order for a user to be successfully logged in.
Lookup Process Requirements
In order for a user to successfully log in, the following must all be true.
- AD Groups are configured on the shares in MyWorkDrive.
- The groups configured on shares are granted permissions in NTFS.
- The user logging in is a member of group(s) configured on shares in MyWorkDrive.
- The share has NTFS permissions and Windows permissions, which do not conflict.
- The computer account or user account MyWorkDrive is installed has rights to query Users and Groups on AD.
Errors You May Encounter
These are the typical errors a user may encounter when logging in if the login process is not successful due to share/permission issues.
- A warning message that the administrator has not provisioned any shares for your account.
- Shares which are missing (some present, some not).
- Shares which are empty/blank.
These errors may not affect all users. Depending on your configuration, some users may experience issues while others may not. You might notice patterns, such as: "Admins can log in, but regular users cannot," "Accounting works, but Finance does not," or "New users can't access the share, while existing users can."
Troubleshooting
If your users encounter any of those issues, you can use a combination of tools built into MyWorkDrive as well as tools in AD to help troubleshoot the issue.
File Share test tool
The file share test tool will let you simulate a login as a user account for a given file share, with either an Email (SSO) or username/password.
The file share test tool will report on errors with delegation (delegation is required if you are using SSO). It will also report on the groups a user is a member of (which you can use to validate MyWorkDrive returns the expected group) and if they have permission to the share (NTFS Permissions are correct).
Health Dashboard
The Health Dashboard will give you a quick snapshot of whether delegation is correctly configured and if our queries on AD are successful.
Effective Access
Not a tool within MyWorkDrive, but Effective Access is the most efficient way to determine if a user has permissions to a share, or they are being blocked/denied for any reason (Windows sharing, Inherited Denies, not inheriting permission).
Common Problems and Solutions
Eight common problems result in empty shares, missing shares, or login failures.
1. Delegation (SSO)
If a user has access to a share via user/password (using the file share testing tool, or by turning SSO off temporarily on the server), but not via SSO, missing delegation is nearly certainly the cause.
Missing delegation can be resolved by enabling delegation on the MyWorkDrive server to the appropriate file servers (and DFS servers, if DFS is used). A common mistake is adding or changing file servers or adding new DFS servers and failing to enable delegation on the MyWorkDrive server. If you have an otherwise working environment that is suddenly missing shares or intermittently missing shares, check for new resources in the environment that may need to be updated on the MyWorkDrive computer account.
Note that different scenarios may require different methods of setting delegation - through the UI, through PowerShell, or using KCD Via PowerShell, or on a User Account for AzureFiles with Azure AD Domain Services. The different methods are all covered in our Delegation Article.
Propagation
A final note about Delegation.
It takes at least 15 minutes for Kerberos tickets to recycle, and potentially longer for Active Directory to propagate the changes, particularly in larger/distributed Domains. Wait at least 15 minutes before repeating your tests. A wait of an hour is not abnormal.
2. Share Configuration (Groups Not Present)
It is not uncommon for groups to be missing or not configured on shares, as changes to NTFS permissions must also be made in MyWorkDrive (MyWorkDrive does not automatically sync with NTFS permissions, as it is designed for administrators to be able to provide less access via MyWorkDrive than a user would have locally. Double-check check share configuration or use the Test Tool to validate the configuration, including user group membership.
If you manually add the user to the share and the share appears with content on user login, then it is likely an issue of the user not being a member of the groups defined on the share.
If you manually add the user to the share and the share appears blank on user login, then the user likely does not have permission to the share.
Details about share configuration are available in this article.
3. NTFS Permission for the Group on the Share (Missing)
As noted above, in Share Configuration, you can use the test tool to validate if the user has permission to the share. The test tool will also show you what groups the user is a member of. If the tool indicates the user does not have permission to the share, double-check their group membership and NTFS permissions.
4. Conflicting Windows Share Permission
Access to shares is only granted when the user is granted access by both Windows sharing AND NTFS permissions.
Granting access in a way where access is limited, either via Windows sharing or NTFS, will result in missing shares, missing folders, shares unexpectedly being read only or blank.
As described in our Windows File Share Guide, we recommend granting everyone full control via Windows share and using NTFS to apply granular permissions.
You will see this if you use Effective Access and note that permissions like Create Files or Create Folders are blocked by the share. You can read more about testing with Effective Access in our Test Tool article.
5. User/Group Membership (User Not a Member of the Group)
MyWorkDrive uses Active Directory and NTFS for auth and permissions. If a user is not in the right active directory groups, or the right groups do not have the correct permissions to shares/folders/files, the user will have no more access via MyWorkDrive than they would via SMB. Using a combination of the Share Test Tool and Effective Access testing, you can determine if one or the other is an issue.
6. AD Synchronization
MyWorkDrive makes all of the requests on the domain and SMB via the computer account of the server it is installed on. The computer and AD negotiate the domain controller used, and it often will not be the one changes were made in large environments. Immediate changes may not be reflected, including password changes, new users, user group membership changes, etc. Wait at least 15 minutes for changes to propagate. Double-check what logon server the computer hosting MyWorkDrive is using and check your changes there. If replication is an issue, see here for information on troubleshooting replication.
7. AD Lookup Permissions
MyWorkDrive Server must be able to look up user information in Active Directory. If the server cannot lookup these permissions, one of these errors may be seen:
- Invalid Username or Password
- Your account is expired
- The administrator has not provisioned your account for any shares
- SAML Username != Forms username
- Forms Username does not match
Some or all users may experience an issue.
It is suggested to try solution 1, but solutions 2 and 3 may work for your specific scenario.
Solution 1: Give Read Permission to MWD Server
Recommended Solution
We suggest giving permission to read user properties to your MWD server.
Select the OU containing the users or the root of the domain, then right-click and select Properties.
Select "Security", then "Advanced".
Select "Add".
Click "Select Principal". "Computer" must be available as an "Object Type". Then select your MWD server and select "OK".
Select "Descendant User Objects" under "Applies To". Make sure "Read all properties" is selected. Select "OK" in the remainder of the menus.
Your MWD server should now have permissions to read user properties. Please try logging in once more to confirm the issue is fixed.
Solution 2: Add User or Group to "Pre-Windows 2000 Compatible Access"
A common change made to AD which prevents logins is removing/disabling the "Pre-Windows 2000" group without replacing it with the "Authenticated Users" group.
We recommend that you do not disable the Pre-Windows 2000 group. However, if you must disable this group for any reason, grant the Read Remote Access Information permission to the Computer Account for the Windows Server(s) MyWorkDrive is installed on in AD for the relevant users/user groups/OUs.
To verify if Authenticated Users on the Pre-Windows 2000 Compatible group are the issue, run the following PowerShell command:
Get-ADGroupMember -Identity "pre-windows 2000 compatible access"
We expect Authenticated Users to be returned in the result.
The MyWorkDrive server may or may not be named here; inherited group membership (group in a group) is not displayed with this command.
If the return does not include Authenticated Users, it was likely intentionally removed. You may need to consult with your security team to see if you can restore it.
If you have removed inherited groups, a way to address the issue witout altering individual user permissions is to grant the MyWorkDrive server permission to read user's attributes.
To add the MyWorkDrive computer object to the Pre-windows 2000 compatible access group, PowerShell can be used.
Add-ADGroupMember -Identity "Pre-windows 2000 compatible access" -Members "MWDServer$"
In our example, we used a server named mwf-scott3, and then ran the following command to validate that it was added correctly:
Get-ADGroupMember -Identity "pre-windows 2000 compatible access"
Solution 3: Add User or Group to "Windows Authorization Access Group"
The "Windows Authorization Access Group" may be used as an alternative. It can also be added to and queried using PowerShell.
Add-ADGroupMember -Identity "Windows Authorization Access Group" -Members "MWDServer$"
Here we add mwf-scott3 and query with the following command to validate that it was added correctly:
Get-ADGroupMember -Identity "Windows Authorization Access Group"
Adding Authenticated Users to the Windows Authorization Access group is best handled through the Active Directory Users and Computers UI.
8. Read-Only Domain Controllers (RODC)
MyWorkDrive does not support using Read-Only Domain Controllers (RODC) due to limitations in the frameworks our auth is built on (.NET, WCF) and how RODCs proxy requests to writable domain controllers (WDC). Requests made on RODCs do not return proxied identity requests, so when the host computer queries an RODC, the received response is "There are currently no logon servers available to service the logon request" instead of the expected data returned."
Essentially, when using an RODC, the logon server remains one of the DCs in the environment. The RODC uses its own cache or forwards/proxies uncached information to the logon server to service requests. The logon server entry for the domain-joined member(echo %LOGONSERVER% or use the set command and scroll) will return the regular DC the RODC is proxying to, not the RODC that's actually connected.
Our recommendation is to ensure the domain controller is a writable domain controller (WDC) rather than a read-only domain controller (RODC) to support user authentication and directory updates.
We appreciate your feedback. If you have any questions, comments, or suggestions about this article please contact our support team at support@myworkdrive.com.