Know thy SELF…

Windows has a special security principal know as SELF (also Principal Self and NT AUTHORITYSELF).

Here’s the definition of SELF from KB243330:

SID: S-1-5-10
Name: Principal Self
Description: A placeholder in an inheritable ACE on an account object or group object in Active Directory. When the ACE is inherited, the system replaces this SID with the SID for the security principal who holds the account.

And here’s one from KB296479:

SELF is not an actual SID, but a way to reference the objectSid for the object on which it is set, which will always be unique.
The hexadecimal value of the Self SID is: 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x05 0x0a 0x00 0x00 0x00

And from TechNet:

Principal Self

Attribute Value
Well-Known SID/RID S-1-5-10
Object Class Foreign Security Principal
Default Location in Active Directory cn=WellKnown Security Principals, cn=Configuration, dc=<forestRootDomain>
Description A placeholder in an ACE on a user, group, or computer object in Active Directory. When you grant permissions to Principal Self, you grant them to the security principal represented by the object. During an access check, the operating system replaces the SID for Principal Self with the SID for the security principal represented by the object.

So what does all this mean?

It means that if you want to grant a security principal permissions to itself, or more accurately; the object representing itself, you can use SELF as a placeholder. Whenever the security subsystem encounters the SELF SID in an ACL it replaces it with the SID of the object that the ACL is set on.

Why use SELF?

Using the SELF principal can greatly simplify administration and cut down on ACL sizes. Let’s say you have an OU in Active Directory where you want every user to be able to update their own telephone number. Instead of editing each user object and that user permissions to its own telephone number attribute, you would just give SELF that permission, but at the OU level and each user object would inherit it. When a user wants to change his or hers telephone number the access check in Active Directory will encounter the SELF principal and replace that with the SID of the actual account.


One thing I could not figure out while putting this together is what happens when you use SELF in an ACE on an object that is not a security principal, a file for instance. The file does not have a SID (because it is not a security principal) so there is nothing for SELF to point to. I thought that maybe SELF would point to the SID of the owner of the file, but that is the job of the CREATOR OWNER SID, not SELF. I guess that SELF, when used in such a scenario, does not do anything.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.