Étiquette : ActiveDirectory

Pas de commentaire

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

  de

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

Pas de commentaire

Restreindre les listes de distribution dans Exchange 2010

  de

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.

Pas de commentaire

Création d’un custom attribute dans ActiveDirectory

  de

La création d’un custom attribute dans ActiveDirectory est une opération nécessitant de modifier le schéma. Une réflexion est nécessaire en amont car il n’est pas possible de supprimer un custom attribute une fois que celui-ci a été écrit dans le schéma.

Si votre infrastructure comporte un serveur Exchange par exemple, alors votre AD contient déjà des attributs personnalisés. En effet, lors de l’installation, Exchange modifie le schéma pour y ajouter ses custom attributes lui permettant de stocker des informations dont il a besoin.

Dans cet exemple, je vais créer un custom attribute nommé CreatedBy permettant de stocker dans une chaîne de caractères le nom de l’utilisateur qui procède à la création d’un objet.

Il est nécessaire de faire partie du groupe Schema Admins pour pouvoir créer un custom attribute, le groupe Domain Admins n’est pas suffisant.

Se connecter à un serveur en RDP, puis ouvrir une console MMC vide, et y ajouter le snap-in Active Directory Schema (File > Add/Remove Snap-in). Si celui-ci n’apparaît pas, il faut alors l’enregistrer ; dans une invite de commande, saisir ceci :

regsvr32.exe schmmgmt.dll

Normalement, la MMC doit donc ressembler à ceci :

En faisant un clic droit sur Attributes puis Create Attribute, un message apparaît indiquant que la création d’un attribut personnalisé est irrémédiable ; on arrive ensuite sur une fenêtre avec plusieurs détails à remplir.

  • Le Common Name est le nom que l’on souhaite donner à son attribut ;
  • Le LDAP Display Name est le nom LDAP, c’est celui-ci qui apparaîtra lors de requêtes LDAP directes ou via Powershell par exemple, ou encore dans l’ADSI Edit ;
  • Le Unique X500 Object ID est un identifiant qui doit être généré en fonction du domaine, je vais venir sur ce point juste après ;

Ensuite, en fonction du type de données que l’on souhaite stocker dans cet attribut, il faut choisir une syntaxe. Celle-ci peut être un booléen, une chaîne de caractères, un entier, etc.

Le point le plus sensible lors de la création de l’attribut est la génération de l’identifiant unique X500. En effet, cet identifiant est basé sur une suite de chiffres qui est unique par domaine. Il n’est donc pas possible d’en choisir un au hasard. Microsoft propose ce script VBS permettant de récupérer la racine de l’identifiant unique, à laquelle on rajoutera par exemple un incrément. Par exemple, si l’OID retourné par le script se finit en 4941237, l’identifiant unique pourra finir par 4941237.1. De nombreux topics d’aide sont disponibles sur le technet en cas d’incompréhension sur ce point.

Une fois l’attribut créé, il faut le rattacher à une classe (plus communément type d’objet). Dérouler les classes, puis dans le cadre de l’exemple, ouvrir les propriétés de la classe user d’un clic-droit > Properties. Ensuite, dans l’onglet Attributes, il est possible d’ajouter l’attribut que nous venons de créer, et de définir si il est obligatoire ou optionnel.

Appliquer, la création du custom attribute et son rattachement aux objets de type user est terminée. On peut ensuite requêter via Powershell l’AD par exemple sur cet attribut :

Pas de commentaire

Powershell : repadmin sur tous les DC du domaine

  de

Je vais partager aujourd’hui un snippet qui va me servir de base pour implémenter un contrôle des réplications qui fonctionne aujourd’hui uniquement sur base d’un appel de dcdiag.

Ce snippet récupère donc les contrôleurs de domaine et récupère les timestamp des dernières réplications. Ensuite, pour chaque DC, il affiche en vert celles qui date de moins d’une heure et en rouge celles qui datent de plus d’une heure.

$dc = (Get-AdDomain).ReplicaDirectoryServers
$csvpath = "C:\temp\replications.csv"
$dc | Foreach { 
	if(Test-Path $csvpath) { Remove-Item $csvpath }
	Add-Content -Path $csvpath -Value (repadmin /showrepl $_ -csv)
	$csvcontent = Import-CSV $csvpath
	Write-Host -ForegroundColor Cyan `r`n$_
	$csvcontent | foreach {
        if(([datetime]$_.'Last Success Time').AddHours(1) -gt (Get-Date)) { Write-Host -ForegroundColor Green ($_.'Source DSA')($_.'Naming Context')($_.'Last Success Time') }
        else {  Write-Host -ForegroundColor Red ($_.'Source DSA')($_.'Naming Context')($_.'Last Success Time') }
    }
} 
if(Test-Path $csvpath) { Remove-Item $csvpath }

Si, au départ, je pensais avoir à manipuler le texte renvoyé par la commande pour extraire les bonnes informations, la commande repadmin avec l’argument showrepl accepte le paramètre -csv pour réaliser un export qui est ensuite facilement interprétable par Powershell.

Vous pouvez trouver toute la documentation nécessaire à l’utilisation de la commande repadmin sur le site de Microsoft.