Post

Replies

Boosts

Views

Activity

macOS 26.3.1: creating and verifying a disabled local service account without a password credential
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.
2
0
261
9h
macOS 26.3.1: creating and verifying a disabled local service account without a password credential
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.
Replies
2
Boosts
0
Views
261
Activity
9h