Symptoms

You receive an error when accessing SharePoint via smartforms when using AD groups to grant access to SharePoint instead of granting access directly to users:
Failed to initialize the Context URL: https://your-site.your-domain.com
Username:DOMAINUSER
Error Details: Access denied. You do not have permissions to perform this action or access this resource. Method: SharePointService:InitializeContext Method: Set List Forms URL From XML.

At the same time, when access to SharePoint granted directly to user everything works fine.
There is a KB article which describes similar issue, but it is unclear whether it is applicable to 1.0.0 (K2 for SharePoint) - KB001627 – Known Issue when using OAuth with On-Premises SharePoint Farms
https://community.nintex.com/t5/K2-Archived-Articles/KB001627-Known-Issue-when-using-OAuth-with-On-Premises/ta-p/218760 

 

Diagnoses

Sometimes you may see a situation when workaround 1 from aforementioned KB does not work consistently for all users (works for some but not for all) - sometimes some user have to open SharePoint site firs and only afterwards everything is work for them in smartforms.
Regarding workaround 2 from aforementioned KB - not all tables exist in K2 for SharePoint 1.0 than what are mentioned in the KB article (which is for 1.0.1) so workaround 2 is not applicable for 1.0.
So it seems that workaround 1 works but some users sometimes has to access SharePoint site first before access from smartforms start working for them.

It is possible to try the following as a workarounds:
1) As per the K2 KB article, add the user directly to the SharePoint site collection (in Members or Owners group, it should at least have read/write permissions as per K2 for SharePoint 1.0 release notes)
2) Add a hidden Content control to the Form/View that will open the SharePoint site in the background
3) Do a SharePoint User Profile Full Synchronization after the users have been added directly to SP (as per 1 above) and before these users load the page for the first time.

But you may see the following problems with these workarounds: 1) any user that uses a K2 form that integrates with SharePoint first has to log into SharePoint before the integration will work. 2) The workaround that users should be assigned directly to SharePoint does not seem to be viable from administrative standpoint.
 

Resolution

Properly configured and operational User Profile Application is a requirement to allow access to SharePoint using AD DS groups. There can be some issues for example with subset of users or groups when not all containers selected in the connection properties and some custom selection exist there.

If a user profile service and the relevant group memberships for the user are not synchronized, SharePoint Server 2013 may incorrectly deny access to a given resource. Therefore, make sure that group memberships are synchronized with the User Profile service application.

Sometimes this also can be resolved by a manual run of "DirectorySyncClientCmd initial" for a fuller AD import, but this is for a 0365 and Azure instance.

Please verify the settings on the UPA sync connections and make sure that you have selected all containers in the connection and make sure no custom selection exist. Make sure you click on “Select All” in the container selection so that everything new on the root will be imported. If custom selection is used then any addition to the root of the domain will not be included unless they are part of an OU which is already selected.

Please try to synchronize your user profile application service:
• Open SharePoint central admin.
• Click on User Profile Service Application.
• Click on Start Profile Synchronization.
• Start Full Synchronization.
• Click OK.

Also important point to keep in mind is the following:
SharePoint recognizes AD security groups and attaching permissions to these groups will cause the permissions to be granted to the User.
But due to SharePoint caching the user's memberships on login, changes made to a security group are identified only after the cache has expired, possibly taking as long as 10 hours (by default) for it to happen.
This causes the unexpected behavior of adding a user to a Group and the user still being shown the access denied or lack of interface feedback related to the new permissions he should have received.
The user not having his tokens cached prior to being added to the group would cause him to receive access immediately.
Apart from adjusting this caching behavior, it is possible just clear the Logon Token Cache which sometimes may be more preferable:
 

Clear-SPDistributedCacheItem –ContainerType DistributedLogonTokenCache