microg/GmsCore · error · SecurityException

client not admin, yet tried to add work account

Error message

client not admin, yet tried to add work account

What it means

UnauthorizedWorkAccountServiceImpl.addWorkAccount unconditionally throws this SecurityException. Like its sibling methods, this stub exists to reject any work-account insertion attempt from callers that were not granted the authorized/admin service implementation — the operation is deliberately denied at the binder boundary.

Source

Thrown at play-services-auth-workaccount/core/src/main/kotlin/org/microg/gms/auth/workaccount/WorkAccountService.kt:142

            } else {
                val future = accountManager.removeAccount(it, null, null)
                Thread {
                    future.result.let { result ->
                        callback?.onAccountRemoved(result)
                    }
                }.start()
            }
        }
    }
}

class UnauthorizedWorkAccountServiceImpl : IWorkAccountService.Stub() {
    override fun setWorkAuthenticatorEnabled(enabled: Boolean) {
        throw SecurityException("client not admin, yet tried to enable work authenticator")
    }

    override fun addWorkAccount(callback: IWorkAccountCallback?, token: String?) {
        throw SecurityException("client not admin, yet tried to add work account")
    }

    override fun removeWorkAccount(callback: IWorkAccountCallback?, account: Account?) {
        throw SecurityException("client not admin, yet tried to remove work account")
    }
}

View on GitHub (pinned to 157c9d86ac)

Solutions

  1. Obtain the authorized binding (the service must classify your client as admin) before calling addWorkAccount
  2. Use AccountManager-based flows (addAccount with the work account type) intended for third-party apps
  3. Catch SecurityException and route the user to proper work-profile provisioning
  4. Verify you are connecting to AuthorizedWorkAccountServiceImpl, not the unauthorized stub

Example fix

// before
workAccountService.addWorkAccount(callback, token)
// after
try {
    workAccountService.addWorkAccount(callback, token)
} catch (e: SecurityException) {
    Log.w(TAG, "Not authorized to add work account", e)
}
Defensive patterns

Strategy: try-catch

Try / catch

try { svc.addWorkAccount(callback, token) } catch (e: SecurityException) { routeToWorkProfileProvisioning() }

Prevention

When it happens

Trigger: Calling addWorkAccount(callback, token) on IWorkAccountService when the client resolved to UnauthorizedWorkAccountServiceImpl because it lacks admin/authorization.

Common situations: Non-admin app trying to provision a work account via microG; scripts or tests invoking the binder directly; apps that should instead use AccountManager.addAccount with the work authenticator type.

Understand the failure class

Background: "You do not have permission" / 403 Forbidden errors: authenticated but not allowed — causes and fixes across open-source libraries — this error's family across 31 libraries.

Related errors

AI-assisted analysis of microg/GmsCore@157c9d86ac (2026-09-06). Data as JSON: /api/errors/063ba999b2439323. Report an issue: GitHub.