>From Schema: Windows Definition trustee_name oval-def:EntityStateStringType The unique name associated with a particular security identifier (SID). In Windows, trustee names are case-insensitive. As a result, it is recommended that the case-insensitive operations are used for this entity. In a domain environment, trustee names should be identified in the form: "domain\trustee name". For local trustee names use: "computer name\trustee name". For built-in accounts on the system, use the trustee name without a domain. I have a question about the last sentence: "For built-in accounts on the system, use the trustee name without a domain." Currently the SCC tool follows this rule based on the sid format and I noticed that in SCC code we actually do this operation for built-in groups as well. This seems like it violates what is defined above since it specifically says "built-in accounts". If we are only talking about built-in windows accounts there aren't a lot of them, administrator and guest account are the two most notable. Am I reading / interpreting this correctly? If so, I need to tweak the SCC code so this can be fixed in SCC 5.2. Furthermore there has been a bug reported on our tool reporting findings for deny user rights and domain admins and enterprise admins. This bug and research led me to this observation.

Hi Bryan, We also found this a little confusing, so in Joval, we followed some ancient logic we found in ovaldi to print the trustee_name where applicable: If the SID is a domain (or machine) SID, we return just the principal name. If the SID is the machine's built-in Administrator ([machine SID]-500) or Guest ([machine SID]-501) account, we return “Administrator” or “Guest”, respectively. If they’ve got the -500 or -501 SIDs but different names, we return MACHINE_NAME\[Whatever the name is]. If the domain string is “” (empty), “BUILTIN” or “NT AUTHORITY”, we return just the name (no domain). This applies to both user and group principals. Otherwise, we return [DOMAIN NAME]\[PRINCIPAL NAME]. This is consistent with what ovaldi used to do, which seemed (and still seems) to be what content expects. Generally speaking, it’s a bad idea to rely on any trustee_name value; content should be written to rely on SIDs instead, if possible. Best regards, —David Solin > On May 14, 2019, at 12:49 PM, Wilson, Bryan L CIV USN SPAWARSYSCEN LANT SC (US) via OVAL_Developer <oval_developer@lists.cisecurity.org> wrote: > > From Schema: Windows Definition > > trustee_name oval-def:EntityStateStringType > The unique name associated with a particular security identifier (SID). In Windows, trustee names are case-insensitive. As a result, it is recommended that the case-insensitive operations are used for this entity. In a domain environment, trustee names should be identified in the form: "domain\trustee name". For local trustee names use: "computer name\trustee name". For built-in accounts on the system, use the trustee name without a domain. > > I have a question about the last sentence: “For built-in accounts on the system, use the trustee name without a domain.” Currently the SCC tool follows this rule based on the sid format and I noticed that in SCC code we actually do this operation for built-in groups as well. This seems like it violates what is defined above since it specifically says “built-in accounts”. If we are only talking about built-in windows accounts there aren’t a lot of them, administrator and guest account are the two most notable. > > Am I reading / interpreting this correctly? If so, I need to tweak the SCC code so this can be fixed in SCC 5.2. Furthermore there has been a bug reported on our tool reporting findings for deny user rights and domain admins and enterprise admins. This bug and research led me to this observation. > _______________________________________________ > OVAL_Developer mailing list > OVAL_Developer@lists.cisecurity.org <mailto:OVAL_Developer@lists.cisecurity.org> > http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org <http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org>