Exchange et Powershell : liste des permissions d'un user sur les mailbox

Ce script utilisable dans l'Exchange Management Shell prend en paramètre un nom de compte AD rattaché à une mailbox afin de parcourir toutes les ACL des boîtes aux lettres rattachées l'organisation. Il affiche les adresses SMTP reliées à la boîte aux lettres, puis les boîtes aux lettres auxquels le compte à accès ainsi que celles à partir desquelles il peut faire un envoi "en tant que" (Send As).

Une version commentée de ce script est disponible sur le lien ci-dessous.

param([Parameter(Mandatory=$true)][string]$Mailbox)
Write-Host "Processing queries, this might take a while!" -ForegroundColor "Yellow"
$localMbx = Get-Mailbox $Mailbox
$allMbx = Get-Mailbox -ResultSize Unlimited | select Alias
$sam = $localMbx.samAccountName
$validAcl = @()
$validSendAs = @()
foreach($Mbx in $allMbx) {
	$aclMbx = Get-MailboxPermission $Mbx.Alias | where-Object { $_.User -like "*$sam" -and $_.IsInherited -eq $false -and $_.AccessRights -contains "FullAccess" -and $_.Deny -eq $false } 
	if($aclMbx -ne $null) {
		$aclMbx | % { $validAcl+=$_.Identity }
	}
	$sendAsMbx = Get-RecipientPermission $Mbx.Alias | Where-Object { $_.Trustee -like $localMbx.OrganizationalUnit+"/$sam" }
	if($sendAsMbx -ne $null) {
		$sendAsMbx | % { $validSendAs+=$Mbx.Alias }
	}
}
Write-Host "Done!" -ForegroundColor "Yellow"
if($?){
Write-Host "`r`nSMTP Addresses" -ForegroundColor "Cyan"
	foreach($smtpadr in $localMbx.EmailAddresses){
		if($smtpadr.ProxyAddressString.SubString(0,5) -eq "smtp:") { Write-Host $smtpadr.ProxyAddressString.SubString(5,$smtpadr.ProxyAddressString.Length-5) }
	}
	Write-Host "`r`nAccess granted to the following mailboxes:" -ForegroundColor "Cyan"	
	$validAcl | % { Write-Host $_ }
	Write-Host "`r`nMailbox is allowed to send as:" -ForegroundColor "Cyan"	
	$validSendAs | % { Write-Host $_ }
}

Exchange et Powershell : définition de quotas en envoi et réception

Ayant récemment défini des quotas concernant la taille des mails en envoi et en réception afin de séparer une population standard et une population VIP, j'ai développé un script afin de traiter la population standard composée de plusieurs centaines de boîtes aux lettres.

La règle de transport posant la limite maximale, aucune boîte aux lettres n'avait de limite fixée individuellement. Ce script applique une règle de 10 Mo pour ces boîtes.

$UnltdMbx = Get-Mailbox -ResultSize unlimited | Where-Object { $_.MaxSendSize -eq "unlimited" -and $_.MaxReceiveSize -eq "unlimited" }
$UnltdMbx | % {
	echo $_.Alias
	Set-Mailbox $_ -MaxSendSize 10MB -MaxReceiveSize 10MB
}

Ensuite, si nécessaire, il faut ajuster la configuration globale du transport. Ici, la limite sera de 20 Mo.

Set-TransportConfig -MaxReceiveSize 20MB -MaxSendSize 20MB

De même, il est nécessaire de vérifier les tailles limites spécifiées dans les connecteurs et liens AD si nécessaire :

Get-ReceiveConnector | Set-ReceiveConnector -MaxMessageSize 20MB
Get-SendConnector | Set-SendConnector -MaxMessageSize 20MB
Get-ADSiteLink | Set-ADSiteLink -MaxMessageSize 20MB

En exécutant ces commandes, je permets donc aux utilisateurs standard d'envoyer ou recevoir des mails pesant jusqu'à 10 Mo, et aux utilisateurs n'ayant aucune limite de configurée d'envoyer ou recevoir des mails jusqu'à 20 Mo.

Plusieurs choses tout de même à retenir de cela :

  • La règle de transport sera toujours prioritaire sur un quota défini au niveau d'une mailbox.
  • Mettre un quota trop élevé peut se révéler contre-productif, puisque les serveurs de messagerie sont globalement configurés pour recevoir ou émettre des mails de 20 ou 30 Mo maximum. Si les mails sont trop volumineux en sortie, les destinataires ne les recevront jamais, soit bloqués par une solution anti-spam ou bien par le serveur de messagerie lui-même !
  • Les clients de messagerie ainsi que les quotas de boîte affectés ne sont pas conçus pour recevoir des mails de 50 Mo ou plus... il est bien important de s'assurer du bon dimensionnement des serveurs de mailbox et des quotas avant d'autoriser tout un chacun à envoyer des mails volumineux, bien que ça ne soit pas nécessairement une action courante... De nombreux systèmes existent de nos jours pour partager des fichiers lourds en passant simplement par un lien envoyé dans un mail ne contenant que du texte !

Naturellement, avant une application sur un environnement de production, il sera intéressant de tester sur un environnement de recette car l'on touche bien plus qu'un simple serveur de messagerie... Il est possible qu'il ait des effets de bord sur toute la chaîne de messagerie (relai SMTP, solution antispam / antivirus, liens réseau, stockage...)

Powershell : liste des serveurs sur lesquels un user est connecté

J'ai eu un incident concernant un lock de compte AD récurrent sur diverses stations. Afin de pouvoir déterminer sur quels serveurs était connecté ce login, j'ai développé un script Powershell qui parcourt un fichier CSV contenant une liste de serveurs (facilement générable à partir de l'ActiveDirectory).

Le script utilise l'application CLI win32 quser et prend en paramètre un nom de login d'utilisateur.

param([Parameter(Mandatory=$true)][string]$Login)
$serverlist = Import-CSV server-list.csv
foreach($server in $serverlist) {
	$qo = quser /server:$($server.Name) 2>$null
	if($qo -ne $null){
		$qo | foreach {
			if($_.Contains($Login)){
				Write-Host "Logged in on $($server.name)" -ForegroundColor "Green"
			}
		}
	}
}

Perte de connectivité LDAP après upgrade vCenter en 6.7 u3f

Cette semaine, j'ai été confronté à un incident plutôt particulier suite à un upgrade d'une appliance vCenter (6.5 vers 6.7 u3f - build 15976714). En effet, après l'upgrade, j'étais incapable de me reconnecter en utilisant mon login ActiveDirectory, pas plus qu'en utilisant un autre compte lié à ce même ActiveDirectory. Cependant, la connexion avec l'utilisateur local fonctionne bien.

Les vérifications de base ne donnent rien de particulier :

  • L'appliance existe bien dans l'ActiveDirectory en tant qu'objet Computer (je n'utilise pas de compte pour faire la connexion)
  • Les entrées DNS directes et reverse sont bien correctes

La sortie et réintégration à l'ActiveDirectory de l'appliance n'ont rien donné non plus, cependant il y a du mieux : tous les comptes renseignés en dur dans les autorisations globales peuvent ouvrir une session sur le vCenter. Cependant les comptes qui sont membres des groupes étant dans les autorisations ne fonctionnent toujours pas. De plus, l'appel aux webservices SOAP est toujours impossible par un compte sur l'ActiveDirectory (Veeam utilise ces webservices pour interagir avec le vCenter afin de sauvegarder les VM).

Étant donné le caractère plutôt urgent de la résolution de cet incident puisqu'il impacte les sauvegardes, nous avons contacté le support VMware qui nous a confirmé que ce dysfonctionnement pouvait arriver de manière aléatoire lors d'un upgrade de VCSA vers ce dernier build (6.7 update 3f) et que ce bug sera corrigé lors d'une prochaine release.

Malgré tout, le support ne nous a pas permis de trouver la cause du dysfonctionnement ; en faisant jouer nos réseaux, nous avons été mis sur la piste du fichier /etc/resolve.conf, que j'aurais dû vérifier en me connectant en SSH sur l'appliance (si je peux avoir une excuse, il était plus de 22h quand je me suis penché sur le sujet en urgence !).

Pour ce faire, ouvrir une session SSH sur le VCSA, puis saisir shell dans le prompt afin d'accéder au prompt standard de PhotonOS qui est le système d'exploitation socle de vCenter (basé sur GNU/Linux), puis saisir la commande suivante :

more /etc/resolve.conf

Cette instruction doit imprimer le contenu du fichier qui doit à minima contenir l'IP loopback et les DNS renseignés, ainsi que les zones DNS dans lesquelles chercher les enregistrements. Et c'est précisément ici que ça coinçait puisque notre zone ActiveDirectory n'était pas renseignée dans le paramètre search, alors qu'elle l'était sur l'ancienne appliance.

Une fois la zone ActiveDirectory renseignée et un redémarrage complet de l'appliance plus tard, la connexion avec des comptes LDAP était fonctionnelle et les sauvegardes opérationnelles.