I check the process token and extract SID and other information about the process in Process Notify Callback. now my issue is how can identify that process was created by the user in the workgroup or domain group?
briefly, how can I identify a user name in a workgroup or domain?
I don’t want to use SecLookupAccountSid or any function that interact with user mode
In my observation the SID of user or group in workgroup always starts with computer SID on that it was generated.
For example, user S-1-5-21-11111-22222-33333-1001 of computer S-1-5-21-11111-22222-33333.
Similarly, the SID of user or group in domain environment always starts with domain SID. For example,
user S-1-5-21-44444-55555-66666-3005 belongs to domain S-1-5-21-44444-55555-66666.
So to distinguish between workgroup and domain you need to know your computer SID: if the user SID is
computer-prefixed or if it not started with S-1-5-21 (like S-1-5-18 - LocalSystem or S-1-1-0 - Everyone), then
the user is local or it belongs to workgroup. Otherwise the user belongs to domain. Unfortunately, there are no
documented ways to obtain the SID of computer in kernel mode. But you can do this during installation
procedure of your driver and then save it to appropriate persistent location - registry, file, etc.
Alternatively, you may check ACCESS_TOKEN for additional SIDs - S-1-5-113 and S-1-5-114 (introduced in
Windows 8.1 and Windows Server 2012 R2; available on Windows 7 and Windows Server 2008 R2 after
installing KB 2871997):
Security identifiers
https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/security-identifiers
S-1-5-113 Local account
You can use this SID when restricting network logon to local accounts instead
of “administrator” or equivalent. This SID can be effective in blocking network logon for local users and
groups by account type regardless of what they are actually named.S-1-5-114 Local account and member of Administrators group
You can use this SID when restricting network logon to local accounts instead of “administrator” or equivalent.
This SID can be effective in blocking network logon for local users and groups by account type regardless of
what they are actually named.
1 Like
can we consider well-known sid like SYSTEM, Local Service, IEUser as workgroup?
@Alis00n said:
can we consider well-known sid like SYSTEM, Local Service, IEUser as workgroup?
Yes, may be. But may be not 
It depends (of your software requirements).
Perhaps it makes sense to enter three different categories: local users, domain users and all others.
1 Like
Something to consider
Every windows machine runs a local database of users and passwords. a stand alone windows machine will authenticate all users using this database, but a domain joined machine will authenticate some users locally and some via requests to the domain. In a federated environment, which is very common now with hybrid cloud, the domain controller may forward that request on to a further domain. But eventually the result will come back to the client machine
some well known security principals like local system are always authenticated locally by the SAM. Other well known security principals like domain administrators are always domain authenticated.
the SID structure is not easy to use. SIDs come in two forms - standard and self relative. The self relative form has one single blob of memory and all the pointers point to spots within that blob. and the standard kind has pointers that point to anywhere in the address space
within the SID, the authority and sub-authority information will tell you where the authentication should be done - either local or via a domain or federated domain. UM functions like LookupAccountSid can interpret the SID structure, but the format is also documented on MSDN
1 Like
@MBond2 said:
within the SID, the authority and sub-authority information will tell you where the authentication should be done - either local or via a domain or federated domain. UM functions like LookupAccountSid can interpret the SID structure, but the format is also documented on MSDN
so you say we can reimplement UM like LookupAccountSid function in KM?
Well it would be far simpler to implement the sid functions in a UM service and (optionally) cache the results in your driver. Everything would be documented and would just work.
The format of SID is documented and has not changed in a LONG time. If all you want to know is if a user is a local user (SAM), a well known ‘built in’ user (SAM) or an AD user, that’s simple to do from the SID structure
https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-sid_identifier_authority
it is much more complex if you need to know the name of the domain or computer
1 Like
@Mark_Roddy said:
Well it would be far simpler to implement the sid functions in a UM service and (optionally) cache the results in your driver. Everything would be documented and would just work.
My problem is when the system boots
When the system boots all user(s) are local. There has to be enough user
mode present to process domain security stuff before a domain user can run.
So you can certainly put your service in the service dependency chain so
that it too is running before any domain user can run a process.
Mark Roddy
1 Like