Tout acteur principal souhaitant se connecter à un système Windows doit s'y authentifier. Après authentification, une session de connexion est créée, au sein de laquelle l’acteur principal va pouvoir lancer des processus.
L'authentification elle-même peut être réalisée par le système local ou déléguée à un contrôleur de domaine.
Dans le cas d'une authentification locale, le composant réalisant l'authentification est l'autorité de sécurité locale (local security authority), abrégée en LSA. Dans ce cas, la base de données utilisée est la base SAM du système local.
Dans le cas d'une authentification sur un domaine, le système local délègue l'authentification à un contrôleur du domaine, qui peut alors authentifier l’acteur principal si celui-ci appartient au même domaine ou déléguer l'authentification à un autre contrôleur de domaine dans le cas contraire.
Dans les deux cas, si l'authentification se déroule correctement, la LSA du système récupère les attributs d'autorisation de l’acteur principal, afin de pouvoir construire une session de connexion ayant le contexte de sécurité de l’acteur principal authentifié.
Les attributs d'autorisation sont récupérés à l'issue de la phase d'authentification, pour être affectés à la session de connexion et placés dans les jetons des processus rattachés à la session.
Les attributs d'autorisation sont composés de SID et des privilèges. Les SID sont utilisés pour le contrôle d'accès, tandis que les privilèges autorisent certaines actions, pour lesquelles le mécanisme de contrôle d'accès traditionnel n'est pas adapté.
Les groupes locaux et privilèges sont des attributs d'autorisation locaux, attribués au niveau du système local. En revanche, les SID des groupes globaux dont fait partie l’acteur principal sont des attributs d'autorisation globaux, qui doivent être transmis par un contrôleur de domaine à la LSA du système local.
Il y a quatre types de session de connexion possibles (logon session) pour un acteur principal : interactive, via le réseau, en tant que service et en tant que batch.
La session de connexion interactive est la plus courante : elle est créée lorsqu'un utilisateur se connecte de façon interactive, en saisissant son identifiant et son mot de passe à l'invite du programme winlogon.
Une session de connexion via le réseau est typiquement utilisée lorsqu'un acteur principal se connecte à un système distant, par exemple pour accéder à des ressources sur un serveur distant. Les sessions de connexion en tant que service sont utilisées par les services Windows tandis que les sessions de connexion en tant que batch le sont pour des serveurs lancés par le gestionnaire de services COM.
A ceci s'ajoute une session de connexion spéciale et unique, la session de connexion SYSTEM. Cette session est créée au lancement du système et regroupe les processus systèmes. C'est également dans cette session de connexion que fonctionnent par défaut les services Windows. Tout processus fonctionnant dans cette session a tout pouvoir sur le système. Ce n'est pas le cas d'un processus lancé par un administrateur, qui ne possède pas certains privilèges.
Suivant le type de session de connexion utilisée, les possibilités ne sont pas les mêmes. Par exemple, une session de connexion réseau n'a pas la possibilité d'établir à son tour une session de connexion réseau, ceci afin de protéger des connexions par rebonds successifs sur plusieurs systèmes.
Aspect intéressant pour le contrôle d'accès, un SID est affecté à chaque type de session de connexion et placé dans les jetons des processus appartenant à un type de session de connexion donné. Par exemple, le SID dont le nom en clair est INTERACTIVE se retrouvera dans les jetons des processus appartenant à des sessions de connexion interactives. Ainsi, il est possible d'autoriser des accès à certains objets uniquement aux utilisateurs connectés de façon interactive.
Une session de connexion est repérée par un identifiant localement unique. Cet identifiant est utilisé pour construire un SID désignant cette session de connexion et placé dans les jetons de processus de cette session. Il est donc possible de faire du contrôle d'accès fin, non plus sur des principaux mais des instances de ces principaux, une session de connexion devant être vue comme une instance d'un acteur principal sur le système. Cette possibilité est utilisée lorsqu'un même acteur principal a plusieurs sessions de connexion et qu'elles doivent être isolées au niveau du contrôle d'accès.