macOS 26.3.1: creating and verifying a disabled local service account without a password credential

Question

Created 22h

Replies 2

Boosts 0

Participants 2

I’m designing a dedicated local PostgreSQL service account on macOS 26.3.1. No account has been created.

Design requirements: no usable human password credential, no ordinary interactive login, shell /usr/bin/false, home /var/empty, no SSH credential, and no admin/wheel membership or Secure Token/FileVault volume-owner role. Any eventual service execution would be separately controlled.

These are desired properties, not claims about established macOS behavior. I’m seeking a supported provisioning and verification procedure.

Direct disabled creation: What supported Apple API/tool and attribute representation can create a local service account directly in a DisabledUser state? Can this be established during initial creation, without an externally available enabled password-authenticating intermediate state?
Credential absence: Can creation occur without ever assigning or storing a usable human password credential or equivalent authentication secret? Please distinguish no password, an empty password, an unknown/generated password, disabled password authentication, and a disabled account. An empty password is unacceptable for this design.
DisabledUser scope: What authentication paths does it prevent on macOS 26.3.1—password authentication, GUI/console login, SSH password authentication, and other Open Directory-backed authentication? How does this differ from system-controlled process execution under the UID, including launchd execution using UserName/GroupName?
Nonauthenticating verification: What supported read-only attributes, policies, or APIs establish that the account is disabled and lacks a usable password credential, without attempting authentication or exposing hashes/secrets? Does inspecting the disabled marker establish only account state, or also credential absence?

Secondary clarification: Is pwpolicy disableuser still recommended for local accounts? Is DisabledTags;SecureToken relevant only to token issuance, and can a controlled daemon run under a disabled UID without enabling human authentication?

Source basis

APPLE_DOCUMENTED: AuthenticationAuthority documentation identifies DisabledUser as indicating a disabled account.
APPLE_DOCUMENTED: ODNode documentation provides record creation with attributes; the reviewed material does not establish the requested creation-time guarantee.
LOCAL_MANUAL_DOCUMENTED: The installed pwpolicy(8) describes disableuser; its complete current authentication-path scope remains unresolved.
APPLE_DOCUMENTED: Secure/bootstrap-token guidance discusses token issuance separately from account authentication.
APPLE_DOCUMENTED, ARCHIVED: Daemon guidance describes selecting service identities through launch configuration.

Not yet established: a safe credential-free creation sequence, the state of every intermediate step, the complete disabling scope, and sufficient nonauthenticating verification. A create-then-disable sequence would not meet the requirements unless every intermediate authentication state is characterized.

Answered by DTS Engineer in 908557022

Creating role accounts on macOS has always been a tricky issue. A key problem is that there are multiple layers of abstraction and many of the underlying layers have supported APIs. For example, the Open Directory framework is a supported way to read and write user records. However, that’s only part of the story. Using these APIs to achieve a high-level goal, like creating a role account, is tricky, to the point where I’m not sure it’s something you’d want to attempt. You might find that things work today but fail on older, or worse yet newer, systems.

Given that, what your really need is a high-level ‘create a role account’ API. Sadly, we don’t have that. The best we have is the sysadminctl tool and its -roleAccount option. That’s not ideal — command-line tools aren’t really APIs — but it’s probably your best option as things currently stand.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Answer 1

DTS Engineer OP

Apple

12h

Recommended

Creating role accounts on macOS has always been a tricky issue. A key problem is that there are multiple layers of abstraction and many of the underlying layers have supported APIs. For example, the Open Directory framework is a supported way to read and write user records. However, that’s only part of the story. Using these APIs to achieve a high-level goal, like creating a role account, is tricky, to the point where I’m not sure it’s something you’d want to attempt. You might find that things work today but fail on older, or worse yet newer, systems.

Given that, what your really need is a high-level ‘create a role account’ API. Sadly, we don’t have that. The best we have is the sysadminctl tool and its -roleAccount option. That’s not ideal — command-line tools aren’t really APIs — but it’s probably your best option as things currently stand.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Answer 2

Semedo OP

11h

Thank you for pointing me to sysadminctl -roleAccount. No account has been created.

For macOS 26.3.1, could you clarify its supported guarantees for these requirements?

Can it create the account directly disabled, without an externally available enabled password-authenticating intermediate state? Does it establish DisabledUser, or a different mechanism?
Can creation avoid ever assigning or storing a usable account password or equivalent authentication secret? Please distinguish absent, empty, generated/unknown and disabled credentials.
Which authentication paths are excluded—GUI/console, SSH password and other Open Directory-backed authentication—and can launchd still execute a controlled daemon under that UID?
What supported read-only attributes or APIs verify both the disabled state and credential absence without authentication attempts or exposing secrets?

If these guarantees are outside the tool’s supported contract, could you identify the relevant documentation or support route? The related questions about pwpolicy disableuser and DisabledTags;SecureToken also remain open.