What is the altSecurityIdentities attribute? #

altSecurityIdentities is an advanced Active Directory attribute used to associate external identities—such as X.509 certificates, smartcards, Kerberos principal names, and custom identity strings—with a user account.

In practical terms, this attribute is used for:

• Certificate-based logon
• Smartcard and NFC token mappings
• Passwordless authentication mechanisms
• Third-party credential providers such as CodeB Credential Provider V2

Any system that needs to link an external hardware or certificate identity to an AD user typically writes a value into altSecurityIdentities.

Because these mappings affect domain authentication, the attribute is security-sensitive and write access is heavily restricted by default.

Why does a service running as LocalSystem need access to it? #

Software such as identity management agents, provisioning systems, and credential providers often run under the LocalSystem account on a domain-joined machine.

LocalSystem processes authenticate to Active Directory as the machine account:

DOMAIN\MACHINENAME$

If such software needs to assign or update smartcard/credential mappings for a user, it must be able to read and write altSecurityIdentities on user objects.
However, by default only highly privileged groups (Domain Admins, Enterprise Admins, Account Operators, or SYSTEM) have the ability to update this attribute.

To avoid storing admin passwords in a configuration file—and to follow least-privilege best practices—you can safely delegate write access only for the required attribute to the computer account.

How do I give LocalSystem (the machine account) permission to write to altSecurityIdentities? #

Follow these steps on a domain controller using Active Directory Users and Computers (ADUC):

Step-by-Step Instructions #

1. Open Active Directory Users and Computers #

• Log in to a domain controller or use RSAT tools.
• Enable Advanced Features under the View menu.

2. Locate the OU containing the user accounts #

• Identify the OU where the users reside for whom you want to manage altSecurityIdentities.

3. Delegate Control #

1. Right-click the OU
2. Select Delegate Control…
3. Click Next

4. Add the computer account #

1. Click Add…
2. Enter: DOMAIN\COMPUTERNAME$ This represents the LocalSystem context on that machine.
3. Click OK, then Next

5. Create a custom task #

• Choose Create a custom task to delegate
• Click Next

6. Select object type #

• Choose Only the following objects in the folder
• Check User objects
• Click Next

7. Delegate specific permissions #

• Select:
  • Property-specific
  • Tick:
    • Read/Write altSecurityIdentities
• Click Next → Finish

What does this achieve? #

After delegation:

• Any application running as LocalSystem on that machine
• Can read and write the altSecurityIdentities attribute
• Without needing domain admin credentials
• Without storing any passwords
• Without impersonation
• Using least-privileged, attribute-only delegation

This is the most secure and Microsoft-recommended method to allow a system to manage identity mappings.

Is this safe? #

Yes—as long as you limit the delegated rights to:

• A specific machine account
• A specific OU
• Only the specific attributes needed

This avoids granting broad administrative privileges while enabling fully automated credential mapping.