Some normal users cannot access K2 Workspace after upgrading Nintex Automation K2 to 5.9

Good day,

Do you use Active Directory or Azure Active Directory?

Good day ​@VTNIT ,

Thank you for reaching out. Can you please do a network trace in the browser with preserve logs on  (see detail below on how to do this). When you get these, please create a Nintex Support Case on https://customer.nintex.com/ and let them know that the case must be sent up to Anelle van Zyl

Open an InPrivate Window

• Press Ctrl + Shift + N or click ⋮ (Settings) → New InPrivate window.

1. Open Developer Tools
   • Press F12 (or Ctrl + Shift + I) to open Developer Tools.
2. Switch to the Network Tab
   • Click Network in the Developer Tools panel.
3. Enable “Preserve log”
   • Check the box Preserve log at the top of the Network tab.
4. Reload the Page or Perform the Action
   • Navigate to the form that results in access denied.
   • All network requests will appear in the panel.
5. Export the Network Trace
   • Right-click anywhere in the list of requests.
   • Select Save all as HAR with content.
   • Choose a location and save the .har file.

Regards,

Anelle

We are using Active Directory.
User k2test1 can access Production (v5.6), but cannot log in to the Test environment after upgrading to v5.9.
This issue does not affect all users.

Good day ​@VTNIT ,

Thank you for the confirmation. Please look at my second reply and complete that. Reposting here:

Can you please do a network trace in the browser with preserve logs on  (see detail below on how to do this). When you get these, please create a Nintex Support Case on https://customer.nintex.com/ and let them know that the case must be sent up to Anelle van Zyl

Open an InPrivate Window

• Press Ctrl + Shift + N or click ⋮ (Settings) → New InPrivate window.

1. Open Developer Tools
   • Press F12 (or Ctrl + Shift + I) to open Developer Tools.
2. Switch to the Network Tab
   • Click Network in the Developer Tools panel.
3. Enable “Preserve log”
   • Check the box Preserve log at the top of the Network tab.
4. Reload the Page or Perform the Action
   • Navigate to the form that results in access denied.
   • All network requests will appear in the panel.
5. Export the Network Trace
   • Right-click anywhere in the list of requests.
   • Select Save all as HAR with content.
   • Choose a location and save the .har file.

Regards,

Anelle

Thank you. I have created a Nintex Support case (Case No. 00741399).
The support team is currently reviewing it.

Kind regards,
Angkrit

Hi ​@VTNIT 
Has the support team resolved your issue? 

Hi @VTNIT and all,

We ran into what looks like the same issue after installing Nintex Automation K2 (5.9) FP18 (upgrading from FP05) on our test environment. Since this thread has no resolution posted yet, here is what we found.

SYMPTOMS
- After the Fix Pack, every user except local administrators of the K2 server got the "Not authorized" page (/Designer/NotAuthorised.aspx). This affected Designer, Management, Workspace and SmartForms.
- K2 permissions (Designer node, server rights) were fine, and changing them made no difference. The Host Server log showed no errors.

WHERE TO LOOK
The key was the Windows Application event log on the web server: ASP.NET event ID 1314, event code 4008 "File authorization failed for the request". The message text that Get-WinEvent returns is truncated, but the event properties contain the details:

$ev = Get-WinEvent -FilterHashtable @{LogName='Application'; Id=1314; StartTime=(Get-Date).AddDays(-2)}
$ev | ForEach-Object { [pscustomobject]@{ Time=$_.TimeCreated; Path=$_.Properties[18].Value; User=$_.Properties[20].Value } } | Format-Table -AutoSize

In our case, every failure was on one of these pages, for many different authenticated domain users:
- /Runtime/_trust/authorize.aspx
- /Runtime/_trust/spauthorize.aspx
- /Designer/_trust/spauthorize.aspx

CAUSE
ASP.NET file authorization checks the NTFS permissions of the requested .aspx file against the end user, not against the app pool account. The effective ACL on the _trust pages contained only Administrators, IIS_IUSRS and a few named admin accounts. It had neither BUILTIN\Users nor Authenticated Users. That explains why only local admins could log in, and it would also explain the "some users work, some don't" pattern: it depends on whether a user has read access to those files through some group.

Note that /Runtime, /Management, /Workspace and /Report all run from the same "K2 smartforms Runtime" folder, so all of them break at once.

To check:
icacls "C:\Program Files\K2\K2 smartforms Runtime\_trust\spauthorize.aspx"

FIX
We granted Authenticated Users Read & Execute on the two SmartForms folders, after backing up the ACLs first:

$sf = "C:\Program Files\K2\K2 smartforms Runtime", "C:\Program Files\K2\K2 smartforms Designer"
$i=0; foreach ($p in $sf) { icacls $p /save "C:\temp\acl_sf_$i.txt" /T /C | Out-Null; $i++ }
foreach ($p in $sf) { icacls $p /grant "*S-1-5-11:(OI)(CI)RX" }

(S-1-5-11 is the SID of Authenticated Users, so it works regardless of the Windows language.) No restart was needed, and access was restored for all users immediately.

The Fix Pack did not replace the files themselves (they still carry the 5.9 install date and inherit their permissions from the parent folder). We have not yet confirmed whether the ACL changed during the upgrade or whether the Fix Pack changed how these pages are authorized. Either way, I'd recommend checking this ACL and testing with a non-admin account right after installing a Fix Pack.

Hope this helps someone.