Récemment, je suis tombe sur un problème chez un client, comment manipuler un fichier texte de plus de 8GO. a l’évidence le traditionnel bloc note ne fait pas l’affaire

En fait j’ai due essayer plusieurs outils, gratuit et non. Et au bout du compte, le logiciel qui ouvre le fichier le plus rapidement et fait les changements demandé en un temps record WinHex.

Alors si vous avez souvent l’occasion de manipuler ce type de fichier pensez-y.

J

Cliquer sur la premiere etape et indiquer le groupe DA_Clients.

A la seconde etapes donner les interface connecte a chacun des reseaux: publique (internet) et privee. puiz cliquer sur Suivant.

A l’etape suivante selectionner l’autorite de certification interne (comme ci-dessous) et indiquer le certificat obtenu precedemment(edge1.contoso.com) et cliquer sur Terminer
 

A l’etape suivante entrer l’url du serveur nls : https://nls.corp.microsoft.com

A l’etape suivante s’assurer que le bon mappage est affiche et cliquer sur Suivant puis Terminer

Editer l’etape 4 et cliquer sur Terminer sans rien modifier.  Dans la console d’administration cliquer sur Enregitrer puis Terminer.
Et voila c’est fini, il suffit de tester depuis un poste client (apres avoir mis a jour les GPO biensur).

Sur le poste client, il suffit de le connecter au reseau publique et verifier l’acces automatique aux ressources internes.

Cote serveur Edge, dans la console d’administration cliquer sur monitoring:

A cote de IPHTTPS cliquer sur Details pour voir le traffic.

Cliquer 2 fois sur Suivant puis cocher Web Server.

Cliquer sur More information is required… et saisir la valeur edge1.contoso.com pour le type Common name puis sur Ajouter. Au final cliquer sur Enroll

De la meme facon, creer un certificat nomme nls.corp.contoso.com pour le serveur App1.

Sur le serveur App1, associer le certificat obtenu au site web par defaut.

Sur le serveur Inet1 creer les enregistrements DNS suivants:

A Record	@IP
crl.contoso.com	@IP publique du serveur Edge
edge1.contoso.com	@IP publique du serveur Edge
inet1.isp.com	@IP du serveur Inet1

Sur le serveur DC creer les enregistrements DNS suivants:

Ouvrir la console GPMC.msc et localiser la GPO “Default Domain Policy”. Ouvrir la GPO.

Naviguer sous: Computer Configuration/Policies/Windows Settings/Security Settings/Public Key Policies/Automatic Certificate Request Settings

Cliquer du bouton droit dans une zone libre et cliquer sur New –> Automatic Certificate Request.

Selectionner le certificat “Computer” et Valider.

Depuis la ligne de commande en mode administrateur, autoriser le ping IPv6:
netsh advfirewall firewall add rule name="ICMPv6 In" dir=in action=allow enable=yes profile=private,domain,public localip=any remoteip=any protocol=ICMPv6
netsh advfirewall firewall add rule name="ICMPv6 Out" dir=out action=allow enable=yes profile=private,domain,public localip=any remoteip=any protocol=ICMPv6

Le resultat devrait ressembler a ceci:

Il faut maintenant autoriser le serveur DNS a accepter les references ISATAP. Depuis une ligne de commande en mode administrateur:

dnscmd /config /globalqueryblocklist wpad

Voila, avant l’etape suivante executer : GPUPDATE /Force sur chaque serveur/client du domaine afin d’aquerir un certificat ordinateur.

Apres avoir installé le role CA, il faut ajouter les CRLs. Depuis la console d’administration du CA cliquer pour afficher les propriétés.

Sous l’onglet Extension cliquer sur Ajouter, et ajouter l’url interne : .crl">.crl">.crl">http://crl.corp.contoso.com/crld/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

De la même façon ajouter l’url externe : .crl">.crl">.crl">http://crl.contoso.com/crld/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

Maintenant il faut ajouter les chemins reseaux :
.crl">.crl">.crl">\\app1\crldist$\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
et \\edge1\crldist$\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

Cette fois ci, il faut cocher, Publish CRLS to this location, comme suit:

Cliquer sur OK et valider le redémarrage de l’autorité de certification.
Il faut maintenant créer un groupe d’utilisateurs contenant les ordinateurs autorisés à se connecter en DA. Le groupe va s’appeler DA_Users.

Etape suivante, autoriser les utilisateurs authentifie a réclamer un certificat Web.

Exécuter la console certtmpl.msc, et localiser le certificat Serveur Web. Double cliquer dessus. Sous l’onglet sécurité donner au groupe Auth Users la permission Enroll.

Préparation du serveur EDGE :

Le serveur Edge va jouer 2 rôles distincts :
- Serveur Edge DirectAccess
- Point de distribution CRL

Nous allons tout d’abord nous intéresser au second point.

Sur le serveur Edge, créer un dossier partage nomme CRLDIST et partagé en tant que CRLDIST$

Il est important de s’assurer que le compte d’ordinateur de l’autorité de certification est un accès totale au dossier CRLDIST. Comme ci-dessous :

Ce partage servira de point de distribution des CRL du CA.

Une fois le partage créé, il faut le publier à travers IIS. Pour ceci dans la console d’administration IIS cliquer sur le site par défaut et sélectionner «Ajouter un répertoire virtuel » comme ci-dessous:

Ouvrir l’editeur de configuration IIS et modifier la valeur AllowDoubleSpacing de la section system.webServer/security/requestFiltering a True.

De la même façon configurer le serveur APP1, comme serveur web et point de distribution CRL.

DirectAccess supprime les limitations du VPN et permet l’établissement de connection bidirectionnelles bâties sur des standards ayant fait leurs preuves: IPSEC et IPv6.

Dans cet article nous allons démontrer le déploiement de DirectAccess avec ou sans UAG.

L’infrastructure utilisée pour cette démo est la suivante:

Details:

Afin de déployer ce lab, j’ai utilisé un serveur Hyper-V Windows 2008 R2 SP1; 2 Switchs virtuels appelés corpnet et publicnet. L’adressage ip a peu d’importance aussi vous pouvez utiliser les plages d’adresses que vous souhaitez pour symboliser les réseaux publiques et privées.

..

Récemment je suis tombé sur un problème étrange dans un nouveau domaine Windows 2008 R2. Les ordinateurs Windows 7 joignaient et se connectaient au domaine sans problème ; les postes Windows XP, eux, joignaient le domaine sans problème cependant lors de l’ouverture de session une erreur se produisait :

Event ID 5719: No Windows NT or Windows 2000 Domain Controller is available for domain. The following error occurred: There are currently no logon servers available to service the logon request.

Après investigation il apparait que le problème se produit suite à la fragmentation des paquets UDP lors de l’authentification Kerberos. Ceci est particulièrement vrai dans les environnements utilisant des connections VPN ; les grands paquets UDP sont fragmenté, et sont droppé s’ils n’arrivent pas dans l’ordre dans lequel ils ont été envoyés.

Ce problème ne se produit pas pour les postes Windows 7, car ceux-ci utilisent le protocole TCP pour la connexion Kerberos. Afin de résoudre ce problème pour les PC Windows XP, il suffit de forcer l’utilisation du protocole TCP. Pour ceci :

Dans la clé de registre : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\ Kerberos\Parameters
Créer/modifier la clé : MaxPacketSize et lui donner la valeur 1, puis redémarrer le PC en question.

Et voilà, le tour est joué

L’attribut tombstone lifetime dans active directory determine la durée de vie des objets supprimés dans active directory. Cet attribut permet la suppression des objets lors de la réplication et préviens tout retour des objets supprimés lors des opérations de restauration.

Par défaut cette valeur et de 180 jours pour les domaines 2003 SP1 et ultérieur. Cependant cette valeur peut être modifiée et pour en connaitre la valeur dans votre domaine il suffit d’exécuter la commande:

dsquery * “cn=directory service,cn=windows nt,cn=services,cn=configuration,dc=<forestDN>” –scope base –attr tombstonelifetime

Tout ceci pour en venir à un problème que j’ai rencontré récemment. Un jour, sans crier gare, deux des contrôleurs de domaines racine de la forêt se sont mis à ne plus répliquer en affichant dans le journal d’évènement l’erreur 2042 : It has been too long since this machine last replicated with the named source machine. The time between replications with this source has exceeded the tombstone lifetime. Replication has been stopped with this source...

Biensur ceci s’est produit du jour au lendemain, donc impossible d’avoir dépassé la durée de vie tombstone, en fait le problème s’est déclenché suite à une perte d’électricité qui a duré toute la nuit (même les onduleurs ont rendu l’âme) et au redémarrage les horloges internes des serveurs avaient reculé de 2 ans en arrière (certainement à cause d’une batterie morte).

Dans ce cas de figure 2 possibilités s’offraient à moi: 
                  - Reconstruire les DC from scratch : le hic ici c’est que je n’avais pas de 3ème DC d’où régénérer mes contrôleurs de domaines.
                  - Autoriser la réplication depuis des partenaires divergent

J’ai opté pour la deuxième solution.

Avant tout il faut supprimer les objets persistant (Lingering) pour ceci depuis le contrôleur de domaine posant problème exécuter la commande:
repadmin /removelingeringobjects ServerName ServerGUID DirectoryPartition  (Pour plus de détails se référer à l’article technet: http://technet.microsoft.com/en-us/library/cc780362(WS.10).aspx)

Ensuite il suffit de positionner la clé de registre permettant la réplication avec les partenaires divergents :

Dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters créer une valeur DWORD “Allow Replication With Divergent and Corrupt Partner” et lui donner la valeur 1.

Et le tour est joué.

ps: Une fois la réplication terminé il faut s’assurer de remettre la valeur précédant à 0.

En Pratique:

Avant de pouvoir publier un calendrier sur le Web il faut que l’administrateur ait au préalable autorisé ce type de publication, en activant cette fonctionnalité au niveau des serveurs CAS et en créant une Stratégie de Partage ”Sharing Policy”.

La commande Set-OWAVirtualDirectory –identity “owa (Default Web Site)” –CalendarPublishingEnabled: $true permet d’activer la publication au niveau OWA

Il faut ensuite créer une stratégie de partage qui pourra être attribué: Set-SharingPolicy –Identity “Default Sharing Policy” –Domains “Anonymous:CalendarSharingFreeBusyReviewer” 

Ici nous créons une Stratégie de Partage qui autorise un accès maximal à l’utilisateur Anonymous(Public).

Avant que nos utilisateurs puissent publier leur calendrier, il faut leur attribuer la stratégie créée précedement: Get-MailboxDatabase –Identity “DB01” | Get-Mailbox | Set-Mailbox –SharingPolicy “Default Sharing Policy” 

Ici nous attribuons à tous les utilisateurs de la base de données DB01 la stratégie “Default Sharing Policy”

Et le tour est joué. Les utilisateurs peuvent maintenant publier leur calendrier.


Coté Utilisateur:

Un simple clic sur le bouton de partage.

Il suffit de selectionner les détails à partager et cliquer sur “Save” pour que le calendrier soit instantanément partagé.

Pour transmettre le lien vers le calendrier au personne devant y accèder il suffit de choisir “Send Links to This Calendar”

Attention:

Vous aurez noté que le lien généré est de type HTTP, et si, comme recommandé, vous publiez Exchange au travers d’un pare-feu ISA ou TMG, il faut créer une règle de publication séparé pour le traffic de partage de calendrier sur le port 80.