Favoriser la connexion d'un serveur à un DC particulier grâce aux subnets

Il existe plusieurs moyen de favoriser certains DC que d'autres lors de requêtes initiées par les serveurs clients, mais une des méthodes les plus saines reste l'utilisation de subnets dans les sites Active Directory.

En effet, en admettant que l'on ait un site principal nommé Paris et une DMZ sur laquelle est placée un RODC pour y placer par exemple un portail web, il est nécessaire que la machine hébergeant ce portail web interroge le RODC plutôt que d'interroger les contrôleurs de domaine sur le réseau interne, à moins d'ouvrir les ports nécessaires de la DMZ vers le réseau interne.

Pour se faire, il suffit d'ouvrir la console ActiveDirectory Sites and Services (dssite.msc) et de faire un clic-droit New Subnet sur le répertoire des subnets. Une fenêtre s'ouvre, il suffit d'y renseigner le sous-réseau qui sera rattaché au site sélectionné en dessous.

Par exemple, en définissant 192.168.1.0/26, tous les serveurs de ce subnet vont être lié au site sélectionné et donc interroger en premier les DC qui sont rattachés à ce site (que l'on peut voir dans cette même console).

Ensuite, sur le serveur, l'utilisation de nltest permet de vérifier la bonne application des paramètres ; le paramètre dsgetdc permet de lister les contrôleurs de domaine qui répondent aux requêtes. Le paramètre dsgetsite permet de confirmer que le DC qui répond est bien sur le même site AD que notre serveur.

Il ne reste plus qu'à vérifier que la relation d'approbation, toujours avec nltest :

nltest /trusted_domains

Failed to execute GetVersionVector Method - erreur DFSR sur 2008 R2

J'ai rencontré ce jour des dysfonctionnements sur un serveur de fichiers (A) dont certains partages sont répliqués sur un autre serveur de fichiers (B). Ces deux serveurs fonctionnent sous Windows Server 2008 R2.

En vérifiant le backlog comme ceci :

dfsrdiag backlog /sendingmember:A /receivingmember:B /rgname:shares /rfname:shares

J'obtenais cette erreur :

Failed to execute GetVersionVector Method. Err: -2147217406 <0x80041002> operation Failed.

En cause, le KB2663685. Ce hotfix change la manière dont DFSR récupère après une coupure inopinée de la réplication ; en effet, afin d'éviter que des données corrompues soit réécrites à la place de données viables, DFSR arrête toute réplication entre les machines concernées et attend une commande bien précise pour reprendre cette réplication. Ce "temps mort" permet donc aux administrateurs de vérifier l'intégrité des données ou d'analyser la raison du dysfonctionnement initial. Pour voir si cette mise à jour a été installée, une requête Powershell très simple peut être utilisée :

Get-Hotfix | Where-Object { $_.HotfixID -eq "KB2663685" }

En fouillant un peu dans le journal d'événements DFS Replication sur le serveur B, il est possible de trouver l'instruction permettant de relancer la réplication. Pour se faire, il suffit de chercher l'ID 2213, qui ressemble à ceci :

En ouvrant une invite de commande en administrateur et en y saisissant l'instruction donnée, on relance donc la synchronisation.

En attendant quelques minutes, on devrait voir apparaître des événements 2212 et 2214 indiquant que la réplication DFSR est en cours de récupération suite à une interruption anormale, puis que celle-ci s'est déroulée avec succès. On peut donc exécuter de nouveau la commande dfsrdiag backlog et celle-ci devrait retourner simplement la liste des éléments qui vont être répliqués tôt ou tard.

Restreindre les listes de distribution dans Exchange 2010

Dans cet article, je vais expliquer comment limiter les usages des listes de distribution dans Exchange 2010 :

  • implémenter un processus de modération ;
  • limiter qui peut émettre vers la liste de distribution ;
  • cacher qui est membre de la liste de distribution.

Afin de mettre en place une modération, il suffit de se rendre dans les propriétés de la liste de distribution dans Exchange, puis Mail Flow Settings, et Message Moderation.

En cochant la case, il devient possible d'ajouter des modérateurs ; ces derniers recevront une notification leur demandant de valider ou non l'envoi du mail à la liste de distribution. Il est possible d'ajouter cependant des exceptions dans la deuxième liste.

Moins flexible et plus directe, la possibilité de simplement refuser l'envoi depuis n'importe quelle adresse sauf exceptions existe. Cela se configure dans la fenêtre Message Delivery Restrictions.

Ici, on peut donc sélectionner uniquement les comptes qui ont le droit d'utiliser cette liste de distribution. Par exemple, dans le cadre d'une liste de distribution contenant tous les salariés de la société qui a pour but de relayer une communication officielle, on peut donc sélectionner les membres du service communication et donc empêcher n'importe quel utilisateur d'émettre à tous les salariés. A noter qu'il est également possible de spécifier ici des boîtes génériques : l'utilisateur doit configurer son client de messagerie pour envoyer en tant que cette boîte générique, et par essence, avoir les droits SendAs côté Exchange sur cette boîte générique. D'autre part, on peut empêcher un expéditeur non connu du serveur Exchange d'émettre vers la liste de distribution en cochant Require that all senders are authenticated, typiquement un membre externe à la société.

Cependant, sur le papier, cette restriction n'a pas beaucoup de sens puisque certains - si ce n'est tous - les clients de messagerie permettent de convertir la liste de distribution en une liste explicite de destinataires ; si la liste nommée infrasys contient les membres A, B et C, alors le client pourra faire un envoi aux trois destinataires A, B et C et non à la liste infrasys, ce qui contourne la limitation évoquée ci-dessus. Afin d'empêcher ce contournement, il est possible dans l'ActiveDirectory de paramétrer un attribut Exchange afin qu'il ne soit plus possible de dérouler cette liste.

Dans la console Active Directory Users and Computers que l'on peut appeler via dsa.msc, il suffit d'ouvrir le groupe AD qui porte la liste de distribution et de modifier l'attribut hideDLMembership (visible uniquement si les fonctionnalités avancées ont été activées dans la console).

La valeur se choisit dans une nouvelle fenêtre, la valeur Not Set étant celle par défaut, généralement équivalente à False : il est possible d'éclater la liste en destinataires explicites. En passant la valeur à True, les clients de messagerie ne pourront obtenir d'Exchange la liste des membres de la liste.

On conclut en validant simplement le choix. Ces quelques options et paramétrages permettent un meilleur usage et contrôle des listes de distribution dans Exchange 2010.

Exchange et Powershell : nettoyage des références caduques dans les ACL

Les ACL des boîtes aux lettres Exchange ne sont pas en synchronisation permanente avec l'ActiveDirectory, ce qui signifie que si l'on ajoute par exemple sur la boîte scranton@dundermifflin.inc l'utilisateur DUNDERMIFFLIN\jhalpert et que ce compte vient à disparaître de l'ActiveDirectory, alors cette boîte aura dans ses ACL une référence de type "S-1-5-***". Il se produit par exemple la même chose côté Windows si un compte de domaine est ajouté dans les profils locaux du système et que ce compte de domaine vient à disparaître.

Afin de faire un peu de nettoyage sur des boîtes aux lettres partagées, j'ai donc développé un script pour l'Exchange Management Shell (EMS) permettant de lister toutes les références à ces comptes qui n'existent plus. Cette liste est ensuite exportée au format CSV, ce qui permet ensuite de passer ce fichier si besoin dans un script supprimant ces références.

$Output = @()
$mailboxes = Get-Mailbox -ResultSize Unlimited
foreach($mailbox in $mailboxes){
	$acls = Get-MailboxPermission $mailbox | where-object { $_.User -like "S-1-5-21*" -and $_.IsInherited -eq $false -and $_.AccessRights -contains "FullAccess" }
	if($acls -ne $null){
		foreach ($acl in $acls) { 
			$obj = New-Object PSCustomObject
			$obj | Add-Member -MemberType NoteProperty -Name "Mailbox" -Value $mailbox.Name
			$obj | Add-Member -MemberType NoteProperty -Name "SID" -Value $acl.User
			$Output += $obj 
		}
	}
}
$Output | Export-CSV s1521-acl.csv -Encoding UTF8

Dans cet exemple, je ne touche qu'aux permissions qui ont été rajoutées manuellement (IsInherited -eq $false) et aux droits complets (FullAccess). Si je ne recommande pas de changer le premier critère, il est possible de changer FullAccess pour un autre valeur si besoin. Je vous renvoie vers la documentation Microsoft concernant la commande Get-MailboxPermission pour plus d'informations sur le sujet.

Une fois le fichier CSV obtenu, je peux me servir de ce snippet pour le parcourir et procéder à la suppression des entrées relevées :

$acls = Import-CSV s1521-acl.csv
foreach($acl in $acls){
	Write-Host "Processing"$acl.Mailbox"with SID"$acl.SID
	Remove-MailboxPermission -Identity $acl.Mailbox -User $acl.SID -AccessRights FullAccess -Confirm:$false
}

Ce premier script est disponible dans une version commentée à télécharger.