BadUserAccessDenied

BadPermissions

What you actually see

Browsing works, reads on some nodes work, and a specific read, write or method call is refused for one user while an administrator can perform it.

Why it happens

• Role does not grant the permission on that nodePer-node RolePermissions and UserRolePermissions attributes decide what each role may do. A user mapped only to Observer can read but not write; a user with no applicable role gets nothing. The node exists and is visible, which is why this looks like a data problem rather than a permissions one.
• User not mapped to any useful roleRoles are assigned through identity mapping rules on the server. A user who authenticates successfully but matches no mapping rule ends up with only the roles that apply to any authenticated user, which may grant almost nothing. Authentication succeeding tells you nothing about authorisation.
• AccessRestrictions require signing or encryptionA node can carry AccessRestrictions demanding that access occurs over a signed or encrypted channel. Connecting with a lower security mode then produces this code even for a user whose roles would otherwise permit the operation. The fix is the endpoint, not the permissions.
• Anonymous session where a real identity is requiredWhere a client silently falls back to anonymous, the session holds only the Anonymous role. Everything sensitive is denied. This is the case most often misdiagnosed, because the client believes it authenticated.
• Method or service restricted at the service levelBeyond node permissions, servers can restrict whole services or administrative methods - certificate and trust list management, node management, history update - to specific roles. The node is browsable and the method is visible, and calling it is refused. A per-certificate failed-authentication lockout can produce the same denial after correct credentials are supplied.

How to fix it

In diagnostic order: work down, do not skip ahead.

1. Confirm which identity the session is really usingRead the server's session diagnostics for your session and check the user identity. If it says anonymous, your client fell back and the permissions investigation is premature. This is the first check every time.
2. Read the node's UserRolePermissions attributeRead UserRolePermissions on the target node - it reports the permissions applicable to the current session, which is more directly useful than RolePermissions. If the operation you want is absent, the answer is a server-side role change, not a client change.
3. Look up the roles your session holdsThe server exposes its role set in the address space with the identity mapping rules attached to each role. Find which role your user should map to and confirm the mapping rule actually matches your identity - a criteria mismatch in the mapping is a common cause.
4. Check AccessRestrictions and the channel securityRead the node's AccessRestrictions attribute. If it requires signing or encryption, reconnect over an endpoint with Sign or SignAndEncrypt. A permission granted only over an encrypted channel is a deliberate design, not a bug.
5. Check the AccessLevel and UserAccessLevel attributes tooUserAccessLevel reports what the current user may do with the Value attribute, which is the fastest way to distinguish a node that is read-only for everyone from one that is read-only for you. AccessLevel tells you the node's inherent capability.
6. Request the role change with the specific evidenceTake the node, the operation and the UserRolePermissions reading to whoever administers the server. A request naming the exact node and permission is actioned; a request saying access is denied produces a conversation.

Where it shows up, by tool and stack

What it looks like in the log

Write ns=3;s=Oven.SetPoint denied for user 'scada_ro': BadUserAccessDenied
Session identity anonymous; node requires role Operator
AccessRestrictions on ns=4;i=1503 require an encrypted channel

Confirm the fix

Confirm UserAccessLevel or UserRolePermissions on the node now includes the operation for your session, and confirm the operation itself succeeds rather than inferring success from the permission attribute alone.

Stop it happening again

Define roles and per-node permissions deliberately rather than leaving a server open, make the client fail loudly instead of falling back to anonymous, use distinct credentials and certificates per integration, and record which role each integration needs so reviews are possible.

Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.