Bruce JDC Blog

Aller au contenu | Aller au menu | Aller à la recherche

Tag - Exchange 2007

Fil des billets

2013 fév. 1

Vous n'arrivez pas à enlever une permission sur un objet : l'ACL n'existe pas sur l'objet!

Par Bruce JDC - Exchange

Dans ce billet je vais parler d'une situation frustrante lorsque l’on souhaite nettoyer les ACL des boites aux lettres. Rien de plus frustrant lorsque l’on regarde les permissions d’un BAL avec Get-MailboxPermission de voir toutes ces permissions en S-1-5-************ révélatrices de comptes supprimés.

Même si il n’y a aucun risque de sécurité (la partie RID du SID ne sera jamais réutilisée par Active Directory), j’aime bien ne voir que les permissions pertinentes pour un objet. Dans mon cas, lorsque j’essaie de nettoyer une permission, la réponse de la cmdlet powershell me laisse perplexe : « /// Can't remove the access control entry on the object "CN=John Doe,OU=Users, DC=contoso,DC=local" for account "contso\johndoe" because the ACE doesn't exist on the object. /// » Pourtant je vois bien une permission sur cette BAL. D’ailleurs c’est un pipe entre un Get et un Remove, je n’ai rien copié / coller. Je fais un Get-ADUser sur le SID indiqué, rien ; surtout que le SID que j’ai indiqué ne fait pas parti de mon domaine !

En fait c’est un sIDHistory.
Pour les migrateurs Exchange, cela ne veut pas dire grand-chose, par contre c’est mieux connu par ceux qui font des migrations Active Directory. Comme l’indique les différentes fiches Technet, le sIDHistory sert lors d’une migration entre foret, le sID de la forêt d’origine d’un compte est repris dans cette attribut pour préserver au compte l’accès aux ressources de sa forêt d’origine, même après une migration. Lors du passage de la commande Remove-MailboxPermission, celle-ci résout bien le sIDHistory sur l’utilisateur, mais n’essai d’enlever que la partie sID, et pas le sIDHistory.

Il n’y a que deux solutions de contournement :

  • Utiliser une console d’administration Exchange 2003
  • Purger le sIDHistory du compte avant d’enlever cette permission
Sources :

http://technet.microsoft.com/en-us/library/cc974384(v=ws.10).aspx

2013 janv. 28

Le proxy ActiveSync d’Exchange 2007/2010 ne communique pas avec Exchange 2003 (Event 1034)

Par Bruce JDC - Exchange

Lors d’une migration d’Exchange 2003 vers Exchange 2010, on utilise généralement une feuille de route (par exemple http://technet.microsoft.com/fr-fr/exdeploy2010/default.aspx) qui permet de ne pas oublier les grandes étapes indispensables au bon fonctionnement d’une coexistence entre les différentes versions d’Exchange.

Plusieurs tests peuvent être réalisés avant de basculer les flux Internet d’Exchange 2003 vers Exchange 2010, mais cela n’est pas toujours évident avec le flux ActiveSync. En cas de dysfonctionnement, la première démarche est d’ouvrir le journal d’évènement des différents serveurs impliqués. Dans le cas d’un problème de communication entre le proxy Exchange 2007 ou 2010 et Exchange 2003, on remarquera la présence régulière d’évènements MSExchange ActiveSync 1034 : « the proxy request to %1 has timed out » en Warning.

Pour expliquer ce dysfonctionnement, il faut se rappeler que la méthodologie de migration proposées par Microsoft se base sur des environnements « standards », mais qui ne sont pas forcément standard chez nos clients ! En effet, même si un client essaye de respecter les « Best Practices » via le BPA, certaines contraintes peuvent l’amener à sortir des rails.

Dans notre cas, il s’agit souvent d’un problème lié à la sécurité, en effet, par défaut les services web d’Exchange sont proposés en HTTP et HTTPS, dans le cas d’Exchange 2003, le répertoire /Microsoft-Server-Activesync est proposé dans ces deux protocoles, mais pour des raisons de sécurité, les administrateurs obligent la connexion en HTTPS. Hors le proxy ActiveSync d’Exchange se connecte sur le répertoire virtuel /Microsoft-Server-Activesync, mais en http, il ne sait pas négocier du https.

Pour résoudre le problème, rien de plus simple : dans la console d’administration IIS, sur le répertoire virtuel /Microsoft-Server-Activesync, il suffit de décocher dans la partie Directory Security l’option « Require secure channel (SSL) ». Un petit IISreset sur chaque serveur Exchange et le flux ActiveSync devrait reprendre sans problème.

une annexe