Yes, I am using the -resetPasswordFor command. I also noticed an issue where creating an account via sysadminctl doesn't enable the secure token, while creating an account using dscl does enable it. Example: sudo sysadminctl -addUser testuser -fullName "Test User" -password - -adminUser AdminUser -adminPassword - If I try to manually enable the secure token I get an error: "Operation is not permitted without secure token unlock." Example: sudo sysadminctl -addUser testuser -fullName "Test User" -password - -admin -secureTokenOn AdminUser -passwordFor - Secure token for the current account is already enabled

Thank you so much for your prompt and helpful response! I must admit, I completely overlooked using the - flag to prompt for passwords. It worked perfectly for resetting the password. Here's the output I received: 2025-01-13 10:05:49.547 sysadminctl[41068:1823531] resetting password for TestUser. (Keychain will not be updated!) 2025-01-13 10:05:52.409 sysadminctl[41068:1823531] - Done As you pointed out, it looks like there’s a keychain password sync issue, since the keychain isn't updated along with the system password. Is there a command or method to update the keychain password to match the system password? Also, just a thought—if the sysadminctl reset command is causing this out-of-sync issue, wouldn't it make the command effectively useless? Since the keychain wouldn't be updated, the reset wouldn't actually work as expected, right?

Thanks for your insights I was able to achieve my use case using sysadminctl commands, which worked as expected. The main issue, however, is that this approach requires admin credentials to be passed as a parameter to the command. This, of course, introduces a potential security risk, as some endpoint security solutions might intercept these commands and expose the credentials. Currently, I'm executing the sysadminctl command from a daemon, but I’m wondering if there’s a way to hide or obfuscate the admin credentials passed as parameters to prevent such exposure. Do you have any recommendations for mitigating this risk ?

I’d like to clarify a few more details about the use case: The new user account we create is exclusively for controlling FileVault authentication. The account is hidden from the login window and is not meant for direct user login. The intention is to leverage this account solely for managing access to FileVault during system startup. Additionally, automatic FileVault login is disabled. This means that upon system boot, users will first authenticate using our hidden account (through FileVault unlocking), after which they can log into their respective accounts—the password for this account is also managed dynamically by our iOS app. This system ensures that while the users will never directly interact with the hidden account, the password for FileVault access is securely rotated after each login, providing continuous security improvements.

Thank you for your helpful response ! I need to change the user's password silently on every login. Scenario Overview: I’m working on a system where I want to create a secondary user account with SecureToken enabled. This account is hidden from the login window, and while the account is visible in FileVault, the goal is to dynamically reset the account password after each successful login, sending the new password to a secure mobile app for the next login. The password would change automatically after each login, and the user would not be required to remember it, improving security with password rotation. Thank you again for your insights.

I just realised that root user doesn't have the secure token enabled and may be that's why account being created by a launch daemon doesn't have secure token enabled by default. My understanding here is that only a user which has secure token enabled can create another user with secure token enabled. So Is there a way to create a user account with secure token enabled using OD API ?

Okay with few changes I am able to create a user and also reset the password for the admin account using OD APIs but I see that SecureToken is disabled whereas I was under the assumption that SecureToken gets enabled automatically for admin users. Any idea why secure token is not getting enabled for new account created via the OD APIs? I also noticed that its not possible to change the password of an admin user which has Secure token enabled. It throws above error as mentioned in the post. Create User func createUserAccount(username: String, fullName: String, password: String) throws { // Get the local node let localNode = try ODNode(session: ODSession.default(), type: ODNodeType(kODNodeTypeLocalNodes)) // Generate a unique user ID let uniqueID = "509" // Create the user record with properly formatted attributes let attributes: [String: [String]] = [ kODAttributeTypeFullName: [fullName], // User's full name kODAttributeTypeUniqueID: [uniqueID], // Unique ID for the user kODAttributeTypePrimaryGroupID: ["80"], // Default group ID (staff group) kODAttributeTypeNFSHomeDirectory: ["/Users/\(username)"], // User's home directory kODAttributeTypeUserShell: ["/bin/bash"] // Default shell ] // Create a new user record let userRecord = try localNode.createRecord( withRecordType: kODRecordTypeUsers, name: username, attributes: attributes ) // Set the user's password try userRecord.changePassword(nil, toPassword: password) // Add the user to the "admin" group let adminGroupRecord = try localNode.record( withRecordType: kODRecordTypeGroups, name: "admin", attributes: nil ) try adminGroupRecord.addMemberRecord(userRecord) print("Admin account \(username) created successfully with UID \(uniqueID).") }

@DTS Engineer I am trying to access system keychain from an authorization plugin as login keychain is locked on login window. Is it possible to use Keychain ACL or keychain sharing with an authorization plugin and make sure only the auth plugin has access to the keychain item ?

@eskimo I am facing another issue on similar lines with PAM modules. Can you please share your insights on this ? https://developer.apple.com/forums/thread/751017

Thanks for your reply. Yes authorization right is system.login.console. Yes. The Custom Auth Plugin is using SFAuthorizationPluginView. Also custom auth plugin is loading fine on logout. I referred this sample app (https://github.com/skycocker/NameAndPassword).
Today the auth plugin only supports password which is set with tag kAuthorizationEnvironmentPassword. I want to add support for smart card with my custom auth plugin and provide option to enter PIN. As per my understanding, When a smart card is connected OS(apple native login window) automatically detects it and triggers authorization_ctk.

I couldn’t find any API to trigger authorization_ctk from custom auth plugin and allow user to pass PIN with tag kAuthorizationEnvironmentPassword.

I updated /etc/pam.d/login with auth sufficient pam_smartcard.so to provide support for smart card with my custom auth plugin. Is there any way to trigger authorization_ctk from a custom auth plugin ? I was hoping that this approach would allow me to pass smart card PIN with tag kAuthorizationEnvironmentPassword and user could log in. I see very mixed results with this approach as it worked intermittently. Any idea why /etc/pam.d/login not showing consistent behavior ? Is my understanding correct or am I missing anything ? I tried above approach by updating /etc/pam.d/authorization instead of etc/pam.d/login and it did work as expected in all the test attempts. I was able to pass PIN via custom authorization plugin and login was successful. Although another behavior that I noticed was that all the native apps(ex: slack),browsers were getting logged out of the account. Any idea what could have caused this behavior ? Could it be something with keychain ? I kept the policy as sufficient for pam_smartcard.so so that other modules are not interrupted # authorization: auth account auth sufficient pam_smartcard.so use_first_pass auth optional pam_krb5.so use_first_pass use_kcminit no_auth_ccache auth optional pam_ntlm.so use_first_pass account required pam_opendirectory.so Thanks in advance.