Le diagramme suivant présente les fonctionnalités anti-spam de Forefront Online Protection for Exchange (FOPE) anciennement connu sous le nom de FOSE et EHS .

• Le premier niveau de protection « Directory-Based Edge Blocking» est basé sur l’adresse e-mail du destinataire. Si le destinataire n’appartient pas à liste des utilisateurs de l’entreprise, la connexion est alors coupée et le message rejeté.
  
• Le deuxième niveau « Reputation Database » est un blocage basé sur l’adresse IP de l’émetteur. FOPE dispose d’une base de données actualisée en permanence, contenant la liste des spammeurs à travers le monde. La connexion est alors coupée et le message rejeté.
  Il est possible de mettre des exceptions en spécifiant dans une Policy Rule, l’adresse IP de l’émetteur.
  
• Le troisième niveau « Fingerprint Engine » est une analyse à base de signatures.
  Si un courrier correspond à un spam connu, celui-ci est rejeté.
  
• Le  quatrième niveau « Rules-Based Scoring » est  une analyse comportementale/heuristique attribuant un score à chaque e-mail selon plus de 20.000 règles, dont Sender Policy Framework (SPF).
  Il est possible d’activer des règles supplémentaires connues sous le nom de «Custom Spam Filter Management ».

1. Si le score dépasse le seuil maximum toléré, le message est automatiquement rejeté.

2. Si le score est borné entre le seuil minimum et maximum, le message est considéré comme un spam.
Il  peut être alors redirigé, mis en quarantaine Web,  délivré en changeant le sujet ou délivré en ajoutant un X-Header personnalisé.

3. Si le score est inférieur à un seuil minimum, le message est considéré comme légitime.

Impact sur la consommation du Paged Pool

Lorsqu’un client ouvre une session non-interactive sur un serveur, le jeton d’accès est stocké en mémoire dans une zone particulière dénommée «Paged Pool».

La ressource «Paged Pool» est une ressource limitée dont la taille maximale est déterminée dynamiquement au démarrage du serveur. Cette taille varie en fonction de la quantité de mémoire vive installée, des paramètres de boot et des valeurs dans la base de registre. L’espace mémoire de la Paged Pool est découpé en page de 4Ko. Ainsi, un jeton d’accès de taille 852 octets occupera une taille de 4 Ko.

Le tableau suivant permet de connaître l’occupation mémoire dans le Paged Pool d’un jeton d’accès en fonction du nombre de groupes d’appartenances.

Impact : Le jeton d’accès des utilisateurs appartenant à un grand nombre de groupes de sécurité occupera d’avantage d’espace dans le Paged Pool.

Lorsque le serveur ne dispose plus d’assez d’espace dans son Paged Pool pour stocker les jetons d’accès, il n’accepte plus de connexion client.

Evaluation Pratique de la limite du Paged Pool

Sur un serveur, afin de connaitre la limite du Paged Pool, exécuter la procédure suivante :

1. Télécharger Process Explorer à l’adresse suivante :

http://www.microsoft.com/technet/sysinternals/Utilities/ProcessExplorer.mspx

2. Télécharger Microsoft Debugging Tools à l’adresse suivante :

http://www.microsoft.com/whdc/devtools/debugging/default.mspx

3. Installer Microsoft Debugging Tools

4. Dans Process Explorer, Cliquer sur View puis System Information

5. Relever la valeur Paged Limit » 

Exemple avec un système x86 et 256 Mo de mémoire vive.

Rappels

La taille du jeton Kerberos est proportionnelle au nombre de groupe auquel appartient l’utilisateur. Si ce nombre est élevé, la taille du jeton Kerberos pourrait dépasser celle du MaxTokenSize, qui fixe la valeur maximale de l’espace stockage des jetons Kerberos.

La valeur par défaut du MaxTokenSize varie en fonction des plates-formes Windows comme le montre le tableau ci-dessous :

Note : Il est possible d’augmenter la valeur, par défaut, de MaxTokenSize en fixant la valeur désirée dans la base de registre:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters\
MaxTokenSize

La valeur maximum conseillée est 65 536.
Cette valeur permet à un ticket Kerberos de contenir 1600 groupes de type « domain local » ou 8000 groupes de type « global/universal ».

Impact : Si la taille du jeton Kerberos est supérieure au MaxTokenSize, l’authentification Kerberos lors de l’accès à une ressource ne fonctionne plus.

Procédure d’évaluation de la taille du jeton Kerberos

Pour de déterminer la taille d’un ticket Kerberos pour un utilisateur donné, deux méthodes peuvent être utilisées : l’estimation théorique et la mesure pratique avec l’outil Tokensz.

Estimation théorique

Elle se base sur la formule suivante:

Taille du jeton Kerberos (octets) = 1200+ 40d + 8s

• 1200 : la valeur approximativement constatée sur les environnements et qui correspond aux informations génériques d’un ticket Kerberos.
• d : correspond au nombre de groupes locaux et groupes universels définis à l’extérieur du domaine d’appartenance du compte utilisateur. Il faut également ajouter, si nécessaire, le nombre de groupes présents dans l’attribut SIDHistory de chaque groupe.
• s : correspond au nombre de groupes globaux et universels définis à l’intérieur du domaine d’appartenance du compte utilisateur.

Estimation pratique - Tokensz

Elle se fait à l’aide de l’outil Tokensz en suivant la procédure suivante :

1. Télécharger Tokensz à l’adresse suivante :

http://www.microsoft.com/downloads/details.aspx?FamilyID=4A303FA5-CF20-43FB-9483-0F0B0DAE265C&displaylang=en

2. Ouvrir une invite de commande :

tokensz /compute_tokensize /user:nono /domain:deadbeef /password:P@ssword!

3. Relever les valeurs suivante :

· MaxTokenSize : correspond à la ligne “Current PackageInfo->MaxToken:”

· Taille courante du jeton Kerberos correspond à la ligne : “MaxToken”.

Un jeton d’accès ou jeton de sécurité identifie le contexte de sécurité d’un processus ou plus précisément d’un thread.

Pendant l’ouverture de session interactive/non-interactive, un jeton de sécurité est crée pour représenter l’utilisateur qui se connecte.

Tous les programmes qu’exécute l’utilisateur héritent d’une copie de ce jeton initial.

La structure d’un  « Access Token » est représentée ci-après :

A l’aide de l’utilitaire kd (Kernel Debugger), il est possible d’afficher la structure d’un jeton de sécurité.
Pour cela, la commande dt _TOKEN doit être utilisée.

Les jetons de sécurité ont des tailles différentes car les comptes utilisateur ont différents ensembles de privilèges et groupes.
La structure d’un jeton de sécurité est « sophistiquée » et il n’est pas évident d’en connaitre la taille.
Néanmoins une approximation peut être faite en utilisant la formule suivante :

Taille (octets) = [token overhead] + [44 x (Nombre de groupes + SID utilisateur)] + [12 x Nombre de privileges]

• Token Overhead :
  représente la taille nécessaire pour stocker les informations comme Token Source, Expiration time…
  Une approximation communément admise est de 452 octets.
  
• Privilèges :
  Un utilisateur de domaine standard possède, par défaut, 4 privilèges qui sont :
  SeChangeNotifyPrivilege
  SeShutdownPrivilege
  SeUndockPrivilege
  SeCreateGlobalPrivilege
  La taille nécessaire pour stocker ces 4 privilèges est de 48 octets
  
• Groupes de sécurité :
  Un utilisateur de domaine standard appartient à 7 groupes de sécurité par défaut qui sont :

SID 0 Group: <NOM DU DOMAINE>\Domain Users(S-1-5-21-xxxx-xxxx-xxxx-513)
SID 1 Group: \Everyone(S-1-1-0)
SID 2 Group: BUILTIN\Users(S-1-5-32-545)
SID 3 Group: NT AUTHORITY\INTERACTIVE(S-1-5-4)
SID 4 Group: NT AUTHORITY\Authenticated Users(S-1-5-11)
SID 5 Group: NT AUTHORITY\NONE_MAPPED(S-1-5-5-0-1246863)
SID 6 Group: \LOCAL(S-1-2-0)
Note : Il est nécessaire de rajouter le SID de l’utilisateur qui est également contenu dans cette structure.

A l’aide de cette formule, nous en déduisons la taille d’un « access token » pour un utilisateur de domaine standard ne possédant aucun privilège particulier et n’étant membre d’aucun groupe de sécurité restreint. Cet utilisateur possédera un « access token » ayant pour taille 852 octets.

Taille (octets) = 500 + 44 x 8 = 852

Une limite connue et documentée d’un « access token » est qu’un utilisateur ne peut pas appartenir à plus de 1023 groupes de sécurité différents (comprenant les groupes Built-in par défaut).
http://technet.microsoft.com/en-us/kb/kb00322970.aspx

Si l’utilisateur appartient à plus de 1023 groupes de sécurité, l’ouverture de session est impossible et le message suivant apparait :

Il existe deux types de groupes dans Active Directory :

• Groupes de sécurité : Servent à affecter des droits et des autorisations aux groupes d'utilisateurs et d'ordinateurs.
  
• Groupes de distribution : Utilisés uniquement avec les applications de messagerie et n'ont aucune sécurité activée.

Note : Un jeton de sécurité ne contient que des groupes de sécurité.

Les groupes de sécurité se caractérisent par le paramètre d’'étendue. L'étendue d'un groupe détermine si le groupe couvre plusieurs domaines ou s'il est limité à un seul domaine.

Les étendues de groupe peuvent être globales, locales de domaine ou universelles

Domain Local :

• Contient des groupes/utilisateurs de tous les domaines
• Utilisable pour le contrôle d’accès aux ressources de son propre domaine

Global :

• Contient des groupes/utilisateurs de son domaine
• Utilisable pour le contrôle d’accès aux ressources de tous les domaines

Universel :

• Contient des groupes/utilisateurs de tous les domaines
• Utilisable pour le contrôle d’accès aux ressources de tous les domaines
• Définition stockée dans le Global Catalog 

Remarque Importante : Un jeton de sécurité construit sur un serveur membre d’un domaine de ressource différent du domaine de compte ne contiendra pas les groupes de sécurité de type « Domain Local ».

La figure suivante montre l'ordre de priorité suivant lequel les objets GPO sont appliqués. 

(- 1 - étant l’ordre de priorité le plus faible et - 5 - l’ordre de priorité le plus élevé.)

Figure : Ordre de priorité lors de l'application des GPO

La stratégie de groupe est d'abord appliquée à partir de la  stratégie de sécurité locale de chaque ordinateur client. Une fois la stratégie de sécurité locale appliquée, les objets GPO sont ensuite appliqués au niveau du site puis au niveau du domaine et enfin au niveau de l’OU.

Cet ordre de traitement des objets GPO (stratégie de sécurité locale, site, domaine, OU parent et OU enfant) est particulièrement important dans la mesure où les objets GPO appliqués en dernier dans le processus écrasent ceux qui ont été appliqués précédemment. Les objets GPO utilisateurs sont appliqués de la même manière.

Pour résumer l’ordre d’application des stratégies de groupe, on peut retenir le sigle LSDOU.

• Local : la GPO d’ordinateur qui est la première crée lorsque  l’ordinateur est installé.
• Site : une GPO de site.
• Domaine : une GPO qui applique des paramètres communs à l’ensemble du domaine.
• OU : Unité d’Organisation Active Directory dans lesquelles des utilisateurs, ordinateurs, groupes et autres OU peuvent être stockés.

L'objet de stratégie de groupe (GPO) se caractérise par un identifiant numérique sur 128 bits, le GUID. Les informations définies dans une GPO sont stockées dans les deux emplacements suivants :

§ Group Policy Containers (Active Directory).

§ Group Policy Templates (Système de fichiers).

Le Group Policy container (GPC) est un conteneur Active Directory stockant différentes propriétés comme le numéro de version, le statut ou les filtres WMI. Le GPC est stocké dans l’annuaire Active Directory

Le Group Policy Template (GPT) est un dossier qui contient les modèles d'administration comme les fichiers .adm ou .admx, les paramètres de sécurité, les scripts et les paramètres liés au registre. Le GPT se trouve dans le dossier système nommé SysVol.

Les GPO sont appliqués lorsque l'ordinateur démarre et lorsqu'un utilisateur ouvre une session, puis à un intervalle régulier.

Lorsqu'un utilisateur allume son ordinateur, le système applique les stratégies de groupe liées à l'ordinateur.

Lorsqu'un utilisateur ouvre une session interactive, le système charge le profil de l'utilisateur et applique ensuite les stratégies de groupés qui sont liées à l'utilisateur.

Les trois-tiers de 802.1x sont le supplicant (client), l’authentificateur (point d’accès) et le serveur d’authentification (serveur RADIUS).

Le supplicant 802.1X est fourni avec les versions suivantes de Windows :
Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7

Pour rappel, les versions de windows mentionnées ci-dessus supportent l’emploie des méthodes EAP suivantes : PEAP-MS-CHAP-V2, EAP-TLS et PEAP-TLS

Sous Windows Server 2003, le serveur Radius se nomme IAS, pour Internet Authentication Service.
Sous Windows Server 2008, le serveur Radius se nomme NPS pour Network Policy Server. 

Pour plus d’informations, je vous conseille  vivement de lire le document IEEE 802.1X for Wired Networks and Internet Protocol Security with Microsoft Windows disponible à l’emplacement suivant : http://www.microsoft.com/downloads/details.aspx?familyid=d9aef757-f528-41be-a01f-99a60c9a855d&displaylang=en