When a client computer needs to contact a domain controller for a specific domain, NetLogon service running at the client computer tries to search the nearest Domain Controller by querying the local computer registry for DynamicSiteName.

Note If the domain being located is the same as the domain to which the computer is joined and the computer has not physically moved to a different site since the last query, the dynamically determined site name in the registry is the actual site in which the computer is located.

On the other hand, if the site name in the registry is not the current site of the computer (for example, if the computer is portable), the domain controller location process serves to update the site information in the registry.

DC Locator Service uses this DynamicSiteName entry to query DNS Server to find the domain controllers in that site. It appends the site name to the DNS query (SRV Record) and sends it to the DNS Server which in turns sends a response.
DNS must return a list of IP addresses that are sorted by priority and weight.

Client inspects the SRV record and attempts to choose the domain controller with the lowest priority. If servers have the same priority, client randomly chooses SRV records with probability proportional to the weight. The algorithm is defined in RFC 2782.

The client (Netlogon service) sends a datagram to the domain controller chosen in the step before. The datagram is implemented as an LDAP User Datagram Protocol (UDP) search.

The domain controller receives the query, which contains the IP address of the client, and passes it to NetLogon on the domain controller. NetLogon looks up the client IP address in its subnet-to-site mapping table by finding the subnet object that most closely matches the client IP address and then returns the following information:

• The name of the site in which the current domain controller is located.
• The name of the site in which the client is located, or the site that most closely matches the client IP address.
• A bit that indicates whether the found domain controller is located (bit is set) or not located (bit is not set) in the site closest to the client.
• Other pieces of information that describe the domain controller.
  
  
  

Note The site information for the forest is stored in the configuration directory partition in Active Directory, and this information is replicated to all domain controllers in the forest. Included with the configuration information is a list of IP subnets that are associated with a particular site.

The domain controller returns the information to the client.
The client inspects the information to determine whether to try to find a beter domain controller. The decision is made as follows:

• If the returned domain controller is in the closest site (the returned bit is set), the client uses that domain controller.
• If the client has already tried to find a domain controller in the site in which the domain controller claims the client is located, the client uses that domain controller.
• If the domain controller is not in the closest site, the client updates its site information and sends a new DNS query to find a new domain controller in the site. If the second query is successful, the client uses the new domain controller. If the second query fails, the client uses the original domain controller.
• If the domain that is being queried by a computer is the same as the domain to which the computer is joined, the site in which the computer resides (as reported by a domain controller) is stored in the computer registry. The client stores this site name in the DynamicSiteName registry entry in HKLM\SYSTEM\CurrentControlSet\Services\ Netlogon\Parameters. Therefore, the DsGetSiteName API returns the site in which the computer is located.

To override the dynamic site name value returned, you can fix the SiteName entry.
When a value is present for the SiteName entry, the DynamicSiteName entry is ignored.

REG_SZ

HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters\SiteName

Range : String

Searching a domain controller at a specific site

If no other site is specified, a locator searches for a domain controller in the Active Directory site at which the client is located, or was last found. If the Active Directory site of the client is not known to the locator when the search begins, it asks a DNS server for the general entries of the domain controllers in the specified domain. It then turns to one of the domain controllers found to determine the Active Directory site which the client belongs to. If the addressed domain controller is not in the same Active Directory site, the locator repeats the DNS request specifying the Active Directory site of the client in order to find a domain controller in its Active Directory site.

If the client does not receive a response from the domain controller of its Active Directory site, or if no domain controller is available at this site, the client returns again to the general list of domain controllers. In this case, the client receives a pseudorandom domain controller in return to its general request.

 

Client with no apparent site

If the client pings a domain controller 2000/2003 and the client IP address cannot be found in the subnet-to-site mapping table, then in this case, the domain controller returns a NULL site name, and the client uses the returned domain controller.

Important
The behavior on Windows Server 2008 domain is not the same.
If a domain member has an IP address that is not linked to a specific site, that computer will be placed in the Default-First-Site-Name site. Every computer that is part of a Windows Server 2008 domain must belong to a site.

When an application requests access to Active Directory, a domain controller is located by a mechanism called the Domain Controller Locator.
The process of location is to use DNS to identify a set of candidate domain controllers from a list, based on SRV records.
Then, the servers on the list are queried to test if they are alive.

The client is initialized with DomainName.FQDN being set to the Domain Name System (DNS) name of the domain to locate, for example mockup1.contoso.com

The general process is shown in the following diagram:

The first step is to perform the DNS discovery.
The client issues a DNS request for _ldap._tcp.dc._msdcs.mockup1.contoso. com
The DNS server returns a list of SRV records that match this request. If no records are available, then the domain location fails.
The DNS exchange is done as specified in the DNS protocols (RFC 1769 and related RFCs).
If target hosts have the same priority, the client select a return SRV record according to weighted pseudorandom order (see RFC2052).

The client then resolves the SRV record to an address, again as specified in the DNS protocols.

Once the address is known, the client sends an LDAP “Ping,” as a way of detecting that the domain controller is in fact handling requests and determining the characteristics of this domain controller. The LDAP “Ping” also known as connectionless LDAP is sent over UDP

After each packet is sent, the client waits for a response, and if no response is received, it sends a packet to the next domain controller. The client continues this process until it receives a valid response that specifies the requested services or has tried all of the domain controllers.

When a client tries to locate a domain controller after it has received the IP address from DNS, it varies the time it waits for a response based on the number of domain controllers it has already pinged. For the first five domain controllers, it waits for 0.4 seconds, and for next five domain controllers, it waits for 0.2 seconds. After 10 domain controllers have been pinged, the client uses a 0.1 second wait for the remaining requests.

The LDAP “Ping” is an LDAP rootDSE search to the domain controller, looking for an attribute called “NetLogon.”

The domain controller server inspects the query and returns the NetLogon result.
The response is typically returned in a NETLOGON_SAM_LOGON_RESPONSE_EX.

Upon receipt of the LDAP SearchResultEntry, the client validates the capabilities returned by the domain controller.

If the capabilities returned by the domain controller are incompatible with the requirements specified by the invoker of the locator algorithm on entry, the client must select another candidate domain controller from the list of domain controller SRV records returned above.

Incompatibility in this case can arise because the client requested a Kerberos KDC, but the domain controller did not indicate that a KDC was present, or the client requested a domain controller that could accept writes, but this domain controller is read-only.

These sorts of negative results are cached by the client; however, they are purged promptly (on the order of minutes).

Because the LDAP “Ping” returns a snapshot of the current state of the domain controller at the moment of the query, services such as a time server, may not be running at the moment, but may be available once the server has completely started.

If all the responses in the SRV records have been checked, and each SRV record points to a server that is either not available or does not match the requirements, then the location operation has failed.

Upon successful response from the domain controller, the location portion completes.
The DomainController element is set to the name and address of the domain controller that was selected.

ActiveX

Les contrôles ActiveX sont apparus en 1996 et se basent sur la technologie COM (Component Object Model).
COM est une spécification qui décrit comment construire des composants pouvant entre utilisés et remplacés dynamiquement. Pour cela, COM standardise les mécanismes qu’un programme doit suivre pour exposer ses fonctionnalités et qui se nomment des interfaces.

Un contrôle ActiveX est un composant logiciel COM qui implémente au minimum l’interface IUnknown.
Les contrôles ActiveX plus évolués souhaitant proposer plus de fonctionnalités implémentent des interfaces supplémentaires. Par exemple, si le développeur souhaite que le contrôle ActiveX puisse être scripté à travers une page HTML, le contrôle doit alors implémenter l’interface IDispatch.
Remarque : La lettre ‘i’ majuscule sert à indiquer qu’il s’agit d’une interface.

Pour connaitre la liste des interfaces qu’un composant COM / qu’un contrôle ActiveX expose, il suffit d’utiliser l’outil OLE/COM Object Viewer proposé par Microsoft.
Cet utilitaire, gratuit, est disponible à travers le Kit de ressources Windows 2000 ou téléchargeable directement à l’adresse suivante :
http://download.microsoft.com/download/win2000platform/oleview/1.00.0.1/
nt5/en-us/oleview_setup.exe

La figure suivante montre les interfaces exposées par le contrôle Microsoft Silverlight à l’aide d’OLE/COM Object Viewer  :

 

Sécurité d’un contrôle ActiveX

Lorsqu’un contrôle ActiveX s’exécute sur un ordinateur, celui-ci s’exécute avec les privilèges de l’utilisateur en cours.
A la manière d’un exécutable, aucun mécanisme de type bac à sable ne restreint les actions d’un ActiveX.

La sécurité est uniquement basée sur la notion de confiance. Les contrôles ActiveX peuvent être signés numériquement ou non.
Le fait qu’un contrôle ActiveX soit signé ne signifie pas que ce contrôle soit sûr, qu’il n’ait pas de vulnérabilités ou qu’il ne contienne pas de porte dérobée.
La signature garantie la provenance du contrôle, l’éditeur, et que le contrôle n’a pas subit de modification, intégrité.

Internet Explorer valide automatiquement la signature associé au fichier .cab lorsque l’utilisateur télécharge un ActiveX. Une signature valide permet de s’assurer que :

• La personne qui prétend être l’auteur du code est bien l’auteur du code. (Authenticité)
• Le code n’a pas été altéré depuis la signature. (Intégrité)

Si l’utilisateur clique sur « Toujours installer les logiciels provenant … », alors le certificat de l’éditeur est automatiquement ajouté dans la catégorie « Trusted Publisher »

 

Signer un contrôle ActiveX  : Authenticode

Microsoft Authenticode est le nom utilisé pour désigner une famille de technologie permettant de signer numériquement et de vérifier les signatures associées à du contenu exécutable. Une personne développant un contrôle ActiveX ou bien une applet Java à la possibilité de signer numériquement son package (.cab) en utilisant la clé privée associée à son certificat numérique.

Ce certificat peut être obtenu depuis une autorité de certification commercial, comme Verisign, GTE ou Thawte ou depuis un CA d’entreprise comme les services de certificats de Windows Server.

L’outil de signature de code de Microsoft signtool.exe est utilisé pour signer le contrôle ActiveX . L’outil signtool.exe, par défaut, ne signe des fichiers que si le certificat utilisé contient l'extension "Enhanced Key Usage" avec pour valeur (1.3.6.1.5.5.7.3.3).

Remarque : Il est possible de signer à nouveau un exécutable déjà signé.

SignTool permet de signer les fichiers suivants : .exe, .cab, .cat, .ocx, .dll, .stl.
Cet outil est disponible dans le Platform SDK de Windows ou lors de l’installation de Visual Studio.

La page d’aide de SignTool.exe est disponible ici :
http://msdn2.microsoft.com/en-us/library/8s9b9yaz(VS.80).aspx

Remarque : Beaucoup de documents font encore références à SignCode (SignCode.exe), cet outil est déprécié et n’est plus supporté

 

Comment Internet Explorer détermine si un contrôle ActiveX peut être utilisé ?

Internet Explorer ne permet pas d’instancier tous les objets COM qui sont installés sur l’ordinateur.

Pour déterminer si un contrôle ActiveX peut être utilisé, la notion de confiance est mise en jeu.
Un objet COM est utilisable dans Internet Explorer à condition que celui-ci ait été marqué comme sûr. Si le développeur estime que l’objet COM ne peut pas entreprendre d’action malveillante, alors il marque son ActiveX comme étant sûr.

Il existe deux façons de marquer un contrôle comme étant fiable pour l'écriture de scripts et l'initialisation :

• Implémenter l'interface IObjectSafety et les propriétés associées.
• Inscrire des clés de registre sous le CLSID du contrôle dans « Implemented Categories ».

IObjectSafety

L'interface IObjectSafety permet à un conteneur de récupérer les fonctions d'initialisation et d'écriture de scripts du contrôle par l'intermédiaire de sa méthode SetInterfaceSafetyOptions. Dans un premier temps, Internet Explorer vérifie si un contrôle implémente ou non l'interface IObjectSafety. Le cas échéant, Internet Explorer appelle SetInterfaceSafetyOptions pour que les interfaces IPersist vérifient si l'objet est fiable pour l'initialisation. Lorsqu'un contrôle fait tout d'abord l'objet d'un script, Internet Explorer appelle en premier lieu SetInterfaceSafetyOptions sur l'interface IDispatchEx du contrôle. En cas d'échec, il appelle SetInterfaceSafetyOptions sur l'interface IDispatch.

Si le contrôle retourne une valeur indiquant qu'il n'est pas fiable pour l'une des interfaces, Internet Explorer avertit l'utilisateur en fonction de ses paramètres de sécurité pour la zone correspondante (Internet, Intranet local, etc.).

Si le contrôle n'implémente pas l'interface IObjectSafety, Internet Explorer recherche sous la section Catégories implémentées du contrôle les clés mentionnées ci-dessus. Si ces clés sont absentes, Internet Explorer avertit l'utilisateur en fonction des paramètres de sécurité.

Remarque : l'implémentation de l'interface IObjectSafety est toujours prioritaire. Si un contrôle implémente l'interface IObjectSafety et retourne une valeur indiquant qu'il n'est pas fiable pour les interfaces IDispatch ou IPersist, les clés de Registre sont ignorées même si elles sont présentes dans la section Catégories implémentées.

Implemented Categories

La deuxième méthode consiste à déclarer que le contrôle ActiveX appartient aux catégories de composants «Controls that are safely scriptable» et «Controls safely initializable from persistent data».
Pour cela, il faut inscrire des clés de registre dans la sous clé « Implemented Categories ».

La clé ci-dessous permet de marquer le contrôle comme étant fiable pour l'écriture de scripts : {7DD95801-9882-11CF-9FA9-00AA006C42C4}

La clé ci-dessous permet de marquer le contrôle comme étant fiable pour l'initialisation à partir de données persistantes : {7DD95802-9882-11CF-9FA9-00AA006C42C4}

Microsoft recommande d'implémenter l’interface IObjectSafety pour marquer un contrôle comme étant fiable ou non fiable. Vous empêchez ainsi les autres utilisateurs de reconditionner le contrôle et de le marquer comme étant fiable alors que ce n'est pas le cas.

 

Les catégories de composants

Les types de composant sont identifiés à l’aide d’un numéro unique GUID (Globally Unique Identifier) sur 128 bits qui se nomme CATID (Category Identifier).
Par exemple, un composant implémentant le CATID {40FC6ED4-2438-11CF-A3DB-080036F12502} est un contrôle, alors qu’un composant implémentant
le CATID {F0B7A1A1-9847-11CF-8F20-00805F2CD064} est un moteur de scripts.

Les catégories de composants sont extensibles, il est possible de définir de nouvelles catégories.
Néanmoins, il est recommandé d’utiliser une catégorie de composants standards si elle répond à vos besoins. Les CATID définis sur une machine sont stockés dans la base de registre à l’emplacement suivant :
HKEY_CLASSES_ROOT\Component Categories

Les catégories de composant suivantes méritent quelques explications :

• Automation Objects : les composants COM qui déclarent implémenter l’interface IDISPATCH
• Controls that are safely scriptable : les composants COM qui déclarent ne pas implémenter d’action dangereuse pour le système et pouvant être manipulés par des sources inconnues et potentiellement malveillantes.
• Controls safely initializable from persistent data : les composants COM qui déclarent pouvant être instanciés à l’aide de données arbitraires provenant de sources inconnues sans que cela ne pose de problème de sécurité pour le système.

 

 

Instancier un contrôle ActiveX

Dans Internet Explorer, un contrôle ActiveX peut être instancié :

• à l’aide des tag HTML <OBJECT>, <EMBED> et <APPLET>.
• à l’aide d’un script avec la commande new ActiveXObject

L’instanciation du contrôle ActiveX peut se faire à l’aide de son CLSID ou de son ProgID.
Par exemple le code HTML suivant permet d’afficher un calendrier interactif :

<html> <body> <object classid="clsid:8E27C92B-1264-101C-8A2F-040224009C02" codebase="http://Please.hackme.com/calendar.cab width="370" height="200"> </object> </body> </html>

CLSID

Le CLSID d’un contrôle ActiveX est un nombre unique de type GUID.

La liste des tous les CLSIDs existant sur une machine peut être consulté dans la base de registre à l’emplacement suivant :
HKEY_CLASSES_ROOT\CLSID, qui est en fait une raccourci vers HKEY_LOCAL_MACHINE\Software\Classes\CLSID.

Si le contrôle ActiveX est déjà installé sur l’ordinateur, il est possible de déterminer son numéro CLSID associé à l’aide de son nom.
Pour cela, examinez la valeur par défaut contenu dans la sous clé CLSID présente sous HKEY_CLASSES_ROOT.

ProgID

Plutôt que de mémoriser les CLSID, il existe une autre façon d’instancier un contrôle, ceci à l’aide de son nom, le progID. Le principe est le même que celui utilisé entre les adresses IP et les noms de domaines DNS.
Pour utiliser cette technique, un contrôle doit posséder une sous-clé Progid sous sa clé CLSID dans la base de registre. Le contrôle doit également posséder une clé contenant son ProgID sous HKEY_CLASSES_ROOT, une sous clé portant le nom CLSID avec la valeur adéquate permet de terminer l’association.

CodeBaseSearchPath

Dans le code de la section précédente, le Tag <OBJECT> contient l’attribut CodeBase. Cet attribut indique au navigateur où télécharger le contrôle ActiveX si celui-ci n’est pas déjà installé sur l’ordinateur.
L’information fournie par l’attribut CODEBASE référence l’URL où se trouve le composant ou le fichier CAB contenant le contrôle ActiveX et les instructions d’installation (Fichier INF).

<object classid="clsid:8E27C92B-1264-101C-8A2F-040224009C02" codebase="http://Please.hackme.com/calendar.cab width="370" height="200"></object>

Le tag <OBJECT> est utilisé pour charger un contrôle ActiveX au sein d’une page web. Lorsque le navigateur parcoure le code HTML et interprète le tag <OBJECT>, la première action est de vérifier si le contrôle n’est pas déjà installé. Pour cela, Internet Explorer parcourt la base de registres à la recherche du CLASSID référencé dans le code HTML. Si le contrôle ActiveX est installé, l’entrée du registre pointe vers le fichier à exécuter. Si le CLASSID n’est pas présent, alors IE va consulter la valeur de l’attribut Codebase. Dans l’exemple, le contrôle ActiveX peut être téléchargé sur le site web http://Please.hackme.com.

Si l’URL référencé n’est pas disponible ou si l’attribut Codebase est absent, alors une liste d’adresses alternatives est présente dans le registre :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\
Internet Settings\CodeBaseSearchPath

La valeur par défaut présente dans le registre est :

CODEBASE;<http://activex.microsoft.com/objects/ocget.dll>

La première entrée indique à Internet Explorer de toujours tenir compte de l’URL inscrite dans l’attribut CODEBASE de la page HTML. En cas d’erreur, Internet Explorer tentera de télécharger les contrôles à partir des autres entrées.

Si l’on souhaite autoriser l’exécution des ActiveX installés mais interdire le téléchargement des contrôles supplémentaires à partir d’internet, la valeur de l’entrée CodeBaseSearchPath doit être personnalisé comme l’exemple suivant :

<http://your_internal_site/get.asp>

Supprimer le mot clé "CODEBASE" empêche les utilisateurs de télécharger les contrôles ActiveX à partir d’internet. Vous pouvez également indiquer des emplacements alternatifs contenant les contrôles ActiveX autorisés à être téléchargé.
Le serveur hébergeant l’URL spécifié dans CodeBaseSearchPath recevra des requêtes HTTP POST dont le format est le suivant :

CLSID={class id}

Version=a,b,c,d

MIMETYPE=mimetype

Plus d’informations pour implémenter un site web traitant ce type de requête :
http://msdn2.microsoft.com/en-us/library/aa741211.aspx

Qu’est ce que l’ActiveX Opt-in ?

L’ActiveX Opt-in est une nouveauté introduite dans Internet Explorer 7.0 valable pour la version Windows XP et Windows Vista.
Par défaut ActiveX Opt-in désactive les contrôles ActiveX déjà installés sur un ordinateur mais n’ayant jamais été exécutés à travers le navigateur.

Si l’on ouvre une page internet tentant d’initialiser un contrôle ActiveX désactivé, une barre d’information affiche le texte suivant :
"This website wants to run the following add-on "ABC Control" from "XYZ Publisher". If you trust the website and the add-on and want to allow it to run, click here …"

Les contrôles ActiveX qui ne seront pas impactés par cette fonctionnalité sont :

• Les contrôles précédemment utilisés avant la mise à jour vers Internet Explorer 7.0
• Les contrôles présents dans liste des contrôles pré-approuvés.
• Les contrôles téléchargés à travers IE7. Ils seront automatiquement activés durant le téléchargement et l’installation.

A noter que la fonctionnalité ActiveX Opt-In est activée par défaut seulement pour les zones de sécurité « Internet » et « Sites sensibles ».
Les sites Intranet ne sont pas impactés par cette fonctionnalité, à moins de l’activer manuellement.

La liste des contrôles pré-approuvés se trouvent dans la base de registres à l’emplacement suivant :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Ext\
PreApproved

Remarque : Les contrôles ActiveX sont identifiés par le CLSID.

 

Liste Blanche : Exécuter les contrôles ActiveX et les plug-ins approuvés par l’administrateur

Il est possible d’interdire l’exécution de tous les contrôles ActiveX sauf ceux approuvés par l’administrateur.
Ce paramétrage se fait à travers les GPOs. Lorsque la GPO est appliquée, l’emplacement suivant de la base de registres est modifiée :
HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\
CurrentVersion\Internet Settings\AllowedControls

Sous la clé AllowedControls, des entrées de type DWORD sont présentes.
L’entrée a pour nom le CLSID du contrôle ActiveX et a pour valeur 0.

[HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows\
CurrentVersion\Internet Settings\AllowedControls]
"{8856F961-340A-11D0-A96B-00C04FD705A2}"=dword:00000000

Ce paramétrage prend effet, lorsque la zone de sécurité contient le réglage suivant :

Liste Noire : Bloquer un contrôle ActiveX

A l’aide de son condensé

Internet Explorer possède un mécanisme permettant de bloquer les ActiveX signé numériquement en se basant sur le condensé. Les condensés se trouvent sous la clé HKLM\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\Restriction Policies\Hashes

A l’aide du Kill-bit

Le Kill-Bit est une entrée de la base de registre pour un CLSID particulier qui marque l’objet COM ou le contrôle ActiveX comme étant non chargeable par le navigateur internet.
Microsoft, lors des mises à jour de sécurité, publie des entrées Kill-Bit afin de bloquer des composants ayant été rapportés comme étant vulnérables à des failles de sécurité.

La mise en place du Kill-Bit s’effectue à l’aide de l’entrée « Compatibility Flags » de type DWORD avec pour valeur 0x00000400. Cette entrée doit se placer à l’emplacement suivant :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\<CLSID>

La liste des valeurs pour l’entrée « compatibility Flags » est disponible ici :
http://msdn2.microsoft.com/en-us/library/aa768234.aspx

Les applications honorant le Kill-Bit sont Internet Explorer (toutes les zones de sécurité) et toutes les applications utilisant le moteur de rendu MSHTML.
Une exception porte sur les fichiers HTA. Un fichier HTA fait abstraction des zones de sécurité, accède au système de fichiers de la machine, et charge des contrôles non sûrs.

Qu’est ce-que le « Phoenix-Bit » – AlternateCLSID ?

AlternateCLSID est un moyen de réviser un contrôle qui aurait reçu le Kill-bit. Ce mécanisme permet ainsi de continuer à faire fonctionner les pages Web faisant référence à l’ancien contrôle ActiveX ayant reçu le Kill-Bit.
Le Phoenix-bit permet au développeur de rediriger de façon transparente les requêtes faisant référence à l’ancien CLSID vers le nouveau CLSID

Pour implémenter le Phoenix-bit, il faut ajouter une valeur de type Texte portant le nom de “AlternateCLSID”. Un pré-requis du Phoenix-Bit est que le Kill-Bit soit également utilisé.

AlternateCLSID doit contenir la valeur : “{CLSID of alternate ActiveX control}”

L’emplacement dans la base de registre est le suivant :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\ {CLSID du contrôle ActiveX ayant le Kill-bit}

From time to time it may be necessary to create a new set of recovery information for an encrypted volume, for example, the information may have been passed to a support engineer or user to recover a laptop that had entered recovery mode. There will be no guarantee that this information hasn’t been written down and left with the computer, so to ensure the security of data on the computer a new recovery password can be generated and any previous ones deleted.

 

1. Suspend BitLocker Protection :

manage-bde -protectors -disable %systemdrive%

2. Delete Recovery Password :

manage-bde -protectors -delete %systemdrive% -type RecoveryPassword

3. Add a new Recovery Password :

manage-bde -protectors -add %systemdrive% -RecoveryPassword

4. Backup the new Recovery Password :

manage-bde -protectors -adbackup %systemdrive% -ID KeyProtectorID

5. Enable BitLocker Protection :

manage-bde -protectors -enable %systemdrive%

 

Note : When generating a new recovery password and storing the new one in AD DS; AD DS will not overwrite the old recovery password. This is by design. BitLocker recovery password entries do not get deleted from AD DS; therefore, you might see multiple passwords for each drive. To identify the latest password, check the date on the object.

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.

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 :

	Windows 2000 RTM/SP1	Windows 2000 SP2/SP3/SP4; Windows XP; Windows 2003
Valeur de MaxTokenSize par défaut, en octets :	8 000	12 000

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”.

Introduction

Une carte à puce est une carte en plastique qui intègre un circuit électronique dont la surface est limitée à 25 mm2.

Lorsque la carte est mise sous tension, elle émet une réponse au démarrage (en anglais Anwer-To-Reset : ATR).

La carte à puce utilisée dans ce post est une carte Gemalto .NET V2+, anciennement connu sous le nom Axalto Cryptoflex .Net.

A l’aide de la commande certutil -scinfo ; nous pouvons voir que l’ATR de la carte est :  3B 16 96 41 73 74 72 69 64

Windows identifie le modèle de carte à puce à l’aide de l’ATR en cherchant une correspondance dans la base de registre à partir de la clef  HKLM\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards.

Si une correspondance est trouvé dans la base de registre alors le CSP monolithique ou mini-pilote correspondant est chargé.
(ici le mini-pilote axaltocm.dll)

Support des cartes à puce dans Windows

La plateforme Windows est agnostique par rapport au système d’exploitation du support (.NET, JavaCard, MultOS, BasicCard etc.) à partir du moment où un module cryptographique (CSP monolithique ou mini-pilote) est disponible.

Concernant le lecteur de carte à puce, le pilote doit être conforme à la spécification PC/SC v1.0 du PC/SC workgroup. 

Sous Windows, le support des fonctions cryptographiques et la gestion des certificats X509 v3 sont nativement pris en charge au travers de CryptoAPI (CAPI).

CAPI2 implémente le support des certificats, comme la construction des chaînes de certificats, la signature…

CAPI1 fait référence au support des composants cryptographiques de base, tel que les fonctions de chiffrement, de déchiffrement et de hachage.

La prise en compte d’une carte à puce suppose historiquement de disposer du CSP (Cryptographic Service Provider) monolithique pour ce support.
L’infrastructure carte à puce de la plateforme Windows  a vu l’introduction d’un SmartCard Base CSP générique et d’un modèle à base de mini-pilotes pour les cartes à puce de façon à faciliter la prise en compte de nouveaux supports.
Le SmartCard Base CSP est disponible sous forme de téléchargement gratuit à partir de  Windows 2000 SP4 et supérieur.
Il est présent nativement sur Windows Vista et Windows Server 2008.

CNG (Cryptographic Next Generation) est le successeur de CAPI1 qui est un bus cryptographique ouvert (Open Cryptographic Interface) disponible à partir de Windows Vista et Windows Server 2008.

La prise en compte avec CNG d’une carte à puce suppose de disposer d’un KSP pour ce support. Windows Vista et (Windows Server 2008) intègre nativement un SmartCard KSP qui est le pendant du SmartCard Base CSP pour CryptoAPI 1.0.
Le SmartCard KSP s’appuie sur le même modèle à base de mini-pilotes pour les cartes à puce de façon à faciliter la prise en compte de nouveaux supports. Il est ainsi possible de développer des mini-pilotes pour CryptoAPI, pour CNG, ou duals pour CryptoAPI et CNG.

Ce billet est l’occasion de présenter le fonctionnement de la protection Anti-spam incluse dans Exchange 2007.
Ainsi ce billet se veut être le plus synthétique possible afin de bien faire comprendre les différents niveaux de filtrage.

 

 

• Le premier niveau de protection « Filtrage de connexion » est un filtrage basé sur l’adresse IP de l’émetteur. Microsoft dispose d’une base de données actualisée en permanence, contenant la liste des spammeurs à travers le monde « Block List».
  Cette liste alimente la fonctionnalité « Réputation de l’expéditeur » qui en fonction des réglages ajoute ou non temporairement l’expéditeur dans la « liste rouge IP ».
  La connexion est alors coupée et le message rejeté.
  Remarque : Il est possible de définir manuellement des adresses IP supplémentaires dans la liste « Liste Rouge IP ou bien d’ajouter des exceptions en spécifiant l’adresse IP de l’émetteur dans la « Liste Verte IP ».

 

• Le deuxième niveau de protection « Filtrage des destinataires » est basé sur l’adresse e-mail du destinataire. Si le destinataire n’appartient pas à liste des utilisateurs de l’entreprise (liste d’adresses globale), la connexion est alors coupée et le message rejeté. Il est possible de proscrire manuellement des destinataires dans l’onglet « Filtrage des destinataires ».
  La connexion est alors coupée et le message rejeté.

 

• Le troisième niveau « Filtrage des expéditeurs» est basé sur l’adresse e-mail de l’expéditeur.
  La liste des expéditeurs proscrits se renseigne en ajoutant manuellement des adresses e-mail ou bien des domaines de messagerie. De plus, il est possible de rejeter les messages sans expéditeur. La connexion est alors coupée et le message rejeté.

 

• Le quatrième niveau « Sender ID » (RFC 4407) permet de détecter l’usurpation d’adresse e-mail. La vérification s’effectue en comparant l’entrée DNS SPF (Sender Policy Framework) au sein des DNS publiques avec l'adresse IP du serveur SMTP émetteur. Cette entrée définie les adresses IP autorisées à envoyé des messages pour le domaine en question. En cas d'échec de vérification, il est possible de « Rejeter le message », « Supprimer le message » ou bien « Continuer le traitement en augmentant la note SCL »

 

• Le cinquième et dernier niveau « Filtrage de contenu » est une analyse à base de signatures anti-spam complétée par une analyse heuristique (moteur de règles).

o Si un courrier correspond à un spam connu, celui-ci se voit attribuer la note SCL (Spam Confidence Level) maximum 9.

o Sinon, le message est confronté au moteur de règles SmartScreen/IMF (filtre de contenu) qui attribue une note SCL comprise entre 0 et 9.

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

2. Si le score est borné entre le seuil minimum et maximum, le message est considéré étant probablement un courrier indésirable.
Il peut être alors redirigé dans un BAL administrateur, délivré en changeant le sujet, délivré en ajoutant un X-Header, ou bien redirigé dans le dossier « Courrier Indésirable » de la BAL utilisateur.

3. Si le score est inférieur à un seuil minimum, le message est considéré comme légitime et délivré dans la boite de réception utilisateur.