A common scenario I see in SharePoint implementations is the use of Active Directory security groups to manage access. This allows for central management of group memberships from Active Directory.
This type of implementation works well but from time to time you may get reports from users advising they still cannot access SharePoint even though you have them added to the Active Directory group.
The reason for this is Claims Based Authentication. Claims authentication is the default for SharePoint 2013 and 2016. Claims authentication utilizes security tokens. These tokens handled by the Security Token Service contain the user’s identity and claims to validate access. When the user first accesses SharePoint the token is generated and has a lifetime based on the authentication provider. The default for Windows Integrated Authentication is 10 hours. This minimizes the need to authenticate for every item accessed in SharePoint. The token is used to validate access. Until the user’s security token expires and renews on the site it will not recognize the new group the user was added as a member of.
The simplest resolution if you are sure the users is in the proper Active Directory group is to just have the user wait, the access will be granted with their next authentication after the token expires. If there is as critical need for access then add the user directly to the site for short term fix and then remove the direct access once the process completes.
You can also utilize powershell to check the current values using Get-SPSecurityTokenServiceConfig and use the WindowsTokenLifetime and LogonTokenCacheExpirationWindow properties of the SPSecurityTokenServiceConfig to update the values if the defaults are not suitable. Keep in mind though that changing this values lower will result in more authentication requests being sent from the Security Token Service to Active Directory potentially impacting performance.