How can we help you today?
Troubleshooting failed login / missing share(s) for users
On Login, MyWorkDrive conducts a real time look up 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.
Contents
Lookup Process Requirements
In order for a user to successfully login, 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 impact all users. Depending on your configuration, some users may be impacted, others may not. You may find commonality around group memberships “Admins can login, users cannot” or users that get shares “Accounting is working, but Finance is not”, “New Users can’t access the share, but existing users are fine”.
Troubleshooting
If your users encounter any of those issues, you can use a combination of tools built in to MyWorkDrive as well as tools in AD to help troubleshoot the issue.
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 if 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 / Solutions
There are six common problems that result in Empty Shares, Missing Shares or Login Failures
1. Delegation (sso)
If a user has access to a share via User/Pass (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 which is suddenly missing shares or intermittently missing shares, check for new resources in the environment which 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.
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 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.
As noted 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.
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 unexpected 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 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 on 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, troubleshoot replication.
AD Lookup Permissions
While rather rare, AD changes which prevent the MyWorkDrive server from being able to lookup user information on AD can be very frustrating to resolve, as AD does not provide good feedback for denied/blocked LDAP requests.
The most common change made to AD which prevents logins for users is removing/disabling the Pre-Windows 2000 group without replacing it with the Authenticated Users Group. While users are usually still able to login, as they can still read their own attributes under the user context, group membership cannot be looked up – which results in a successful authentication, but a failed login as the user is not matched to shares.
MyWorkDrive uses Microsoft Active Directory as an external identity source to validate users and lookup group membership.
User and machine authentication in Active Directory allows network access only to users and devices that are listed in Active Directory.
MyWorkDrive is installed on a domain joined Windows server. As a computer account on Active Directory, the Windows Server is a member of the Authenticated Users group.
The Authenticated Users group is a member of the Pre-Windows 2000 group by default.
If you disable the Pre-Windows 2000 group or remove Authenticated Users from the Pre-Windows 2000 group, authentication and group look up failures occur.
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 is 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’s likely it was intentionally removed. You may need to consult with your security team to see if you can restore it.
If you have removed inherited groups and need 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 a Get-ADGroupMember command to validate it was added correctly.
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 Get-ADGroupMember to validate it was added correctly
Adding Authenticated Users to the Windows Authorization Access group is best handled through the Active Directory Users and Computers UI
