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.

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.

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.
  
  
  

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.

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.

SharePoint 2010 propose un mode d’authentification, appelé authentification par revendication (Claim Based Authentication).

L’authentification par revendication de SharePoint 2010 s’appuie sur un STS local développé à l’aide de WIF (Windows Identity Foundation).
WIF est un ensemble de classes .NET Framework qui permettent de créer des applications prenant en charge les revendications.
Pour rappel, une application prenant en charge les revendications créée avec WIF peut traiter des demandes d’authentification basées sur les protocoles WS-Federation et WS-Trust.  Il faut savoir que WS-Federation prend en charge différent type de jeton de sécurité, dont les jetons SAML 1.1

• Le STS local (SP-STS) est développé à l’aide du framework WIF et de ce fait supporte uniquement les protocoles de fédération suivants :
  WS-Federation, WS-TRUST
• Le SP-STS ne consomme, en entrée, que des jetons de sécurité SAML au format SAML 1.1

Il est légitime de se demander, s’il est possible de fédérer SharePoint 2010 avec un serveur d’identité ne prenant en charge que le protocole SAMLv2.
La réponse est oui : il est possible de fédérer (indirectement) SharePoint 2010 avec un serveur d’identité compatible uniquement avec le protocole SAMLv2. L’implémentation passe par un serveur de fédération disposant d’une double pile protocolaire : WS-Federation et SAMLV2.
Le logiciel ADFS 2.0 répond parfaitement à cette exigence.
 

Dans le graphique ci-dessous, j’ai consolidé l’ensemble des fiches de référence sur EFS disponible sur le site de microsoft.com
Chaque graphique est cliquable.

/>

Au menu des nouveautés d’Exchange 2010, ce qui m’intéresse plus particulièrement est le lot de fonctionnalités autour de l’intégration très poussée d’AD RMS. Il devient possible de définir des règles obligatoires chiffrant à la volée le contenu des messages et appliquant des droits d’usages.

Grâce à Exchange 2010, la protection des messages peut être appliquée :

Automatiquement au niveau du serveur Exchange 2010 (règles de transport) ou bien au niveau du client de messagerie (règles de protection Outlook 2010).

o Automatiquement sur les serveurs de transport Hub Exchange 2010
Vous pouvez créer des règles de protection du transport pour activer une protection RMS automatique des messages sur les serveurs de transport Hub d’Exchange 2010.

o Automatiquement dans Outlook 2010
Outlook 2010 permet de créer des règles de protection Outlook pour activer une protection RMS automatique des messages. Les règles de protection Outlook sont déployées automatiquement chez les clients Outlook 2010 et la protection RMS est appliquée par Outlook 2010 lorsque l’utilisateur compose un message.

Manuellement au niveau du serveur Exchange 2010 (rôle CAS, si l’utilisateur envoie son message à partir du site Outlook Web App) ou bien au niveau du client de messagerie (Outlook 2003/2007/2010).

o Manuellement par les utilisateurs Outlook 2003/2007/2010   
Les utilisateurs Outlook peuvent protéger leurs messages par RMS en appliquant les modèles de stratégie de droits d’accès AD RMS mis à leur disposition. Ce processus utilise la fonctionnalité RMS dans Outlook, pas dans Exchange. Il reste toutefois possible d’utiliser Exchange pour accéder aux messages et prendre des mesures (telles que l’application des règles de transport) pour faire appliquer la stratégie de messagerie de votre organisation.

o Manuellement par les utilisateurs Outlook Web App 
Lorsque vous activez RMS dans Outlook Web App, les utilisateurs peuvent activer une protection RMS pour les messages qu’ils envoient et afficher les messages protégés par RMS qu’ils reçoivent.

Il existe 8 modes opérationnels pour une puce TPM, définis à travers trois variables : enabled, activated et owned. Ces booléens représentent respectivement le fait que la puce est inactive et sans possibilité d’en devenir propriétaire, le fait que la puce est inactive mais que l’on peut effectuer l’opération de prise de possession (TakeOwnership) et enfin le fait que la puce ait été initialisée par un propriétaire via l’opération takeownership.

L’outil tpm.msc (inclus dans Windows 7) permet d’effectuer des actions sur la puce TPM afin de modifier son état. Ainsi, il est possible d’arriver à l’état 0, 6 ou 7 comme illustré sur le schéma précédent et la capture d’écran ci-dessous :

Le changement d'état de la puce TPM nécessite l'autorisation du propriétaire de la puce (via l'utilisation du mot de passe de propriétaire) ou bien un consentement via une démonstration de la présence physique. Ainsi, le fait de modifier l’état d’une puce TPM n’ayant encore aucun propriétaire définit impose de redémarrer l’ordinateur et d’appuyer physiquement sur une touche pour valider le changement de configuration.

Par défaut, la prise de possession de la puce TPM s’effectue en trois étapes, nécessite deux redémarrages et impose la présence physique d’un opérateur. Lors de la prise de possession de la puce TPM, le mot de passe du propriétaire est définit et la puce va créer la clef SRK (Storage Root Key).

Pour automatiser la prise de possession de la puce TPM, il faut que la puce se trouve dans état correct pour la prise de possession, c'est-à-dire dans l’état enabled et activated. Il est dans ce cas nécessaire de flasher le BIOS et la mémoire CMOS contenant la configuration du BIOS.

Note : Le fait de réinitialiser (Clear TPM) une puce TPM efface la SRK et toutes les clefs cryptographiques dérivées. Si BitLocker est activé avec un protecteur de type TPM, alors au prochain démarrage BitLocker entre alors en mode de récupération.

La mesure de l’intégrité de la séquence de démarrage s’appuie sur les registres de configuration de la plateforme (Platform Configuration Registers ou PCR) qui sont des portions de mémoire volatiles de 160 bits (pour stocker des condensats SHA-1) permettant de stocker l'état d'une plateforme. La spécification impose que les PCRs soient, au minimum, au nombre de 16 (numérotés de 0 à 15). Les registres 0 à 7 sont utilisés par la puce TPM et le BIOS TCG, ceux de 8 à 15 peuvent être utilisés par une application pour y placer des mesures d’intégrité portant sur des composants spécifiques.

Sur le schéma ci-dessous, est représenté en bleu, les mesures d’intégrité prises en compte par la solution de chiffrement BitLocker sous Windows 7. Le comportement est configurable par stratégie de groupe. A noter que la table des partitions est prise en compte lors de la mesure d’intégrité de la séquence de démarrage.