According to [Access Control, 2013], “Access control refers to security features that control who [sic] can access resources in the operating system. Applications call access control functions to set who can access specific resources or control access to resources provided by the application.”

The Windows access control model is founded on two base components: access tokens and security descriptors. The relations and interactions between them are illustrated in the schema below, based on [Parts of the Access Control Model, 2013], [Access Tokens, 2013] and [Securable Objects, 2013].

Access Token visualisation

The following items of the schema were therefore further studied:

  • Security identifiers (SIDs) are unique and used to identify a trustee. SIDs are assigned by Active Directory for users within a Windows domain. Various well-known SIDs exist and while SIDs should not be used directly, they are consultable for everybody and their randomness or secrecy is not a security prerequisite [Security Identifiers, 2013]. SIDs are also used to identify logon sessions and are kept unique while a computer is running. The list of previously issued logon SIDs is reset on the reboot of the computer [Security Glossary – L, 2013].
  • Restricted tokens are copies of primary or impersonation access tokens with fewer enabled permissions. Compared to its original access token, a restricted token may contain fewer privileges, have the deny-only attribute set or specify a list of restricting SIDs [Restricted Tokens, 2013].
  • Primary versus impersonation tokens: a primary token is created by the operating system either on a user logon or when the user starts a process. An impersonation token is created when a server-side process captures the identity of a client and impersonates this client identity during the execution of the task. A server-side process using impersonation will have two tokens: first its primary token and a second impersonation token featuring details of the client. Moreover, an impersonation token has one of four different levels of impersonation: anonymous, identify, impersonate and delegate [Lebrun, 2013].

None of the above objects implement cryptography. No crypto-based verification is implemented in the checking process documented either [How AccessCheck Works, 2013].

 

Offline references

[Lebrun, 2013]: Lebrun, M. (2013, July-August). Faiblesse des mécanismes d’autentification: quelles solutions? MISC – Multi-System & Internet Securitry Cookbook(68), page 12-21.