Wasa LDN ?

Le LegacyExchangeDN est le plus vieil et le seul identifiant unique d’un « destinataire »  (recipient) Exchange dans une organisation Exchange. Comme son nom l’indique, il s’agit du DistinguishedName (nom complet X500) de l’objet mailbox dans l’annuaire Exchange 5.5.

Il se trouve aussi dans Active Directory (attribut LegacyExchangeDN) renseigné sur les objets visibles dans la liste d’adresse globale (« GAL ») :

·         Contacts

·         groupes

·         Mail-Enabled Users (MEA)

·         Boites aux lettres

Le puriste notera que toute une série d’autres objets exchange ont aussi un LDN (public folders, connecteurs …)

Il s’agit d’une adresse au format X500 qui contient :

·         Le nom de l’organisation

·         Le nom du site 5.5 ou de du groupe administratif

·         Une chaine identifiant l’objet (souvent l’alias de messagerie)

Ou le trouve-t-on ?

Toutes les APIs MAPI utilisent extensivement ce legacyExchangeDN pour résoudre un nom (« check name »), soumettre un message …

De plus ce LegacyExchangeDN est celui qui est stocké dans chaque message (propriétés PR_SENDER_EMAIL_ADDRESS, et PR_EMAIL_ADDRESS pour les fans de MFCMAPI) ;

Je le prouve avec ce message que m’a justement envoyé le sieur Robain susnommé me demandant de relire la présente:

On trouve aussi ce LDN dans le « fameux » fichier .NK2 (%AppData%\Microsoft\Outlook\<profilname>.NK2)

Vous savez celui qui contient les derniers correspondants et qu’il est conseillé de « vider » quand on migre un profil utilisateur :

Un petit script powershell pour le mettre en évidence :

Ce qui donne :

Quiz : pourquoi le legDN d’ivan, est-il différent des autres legDN dans mon fichier .NK2 ? (répondez en commentaires J)

Enfin et mauvaise nouvelle on retrouve aussi le LegacyExchangeDN dans la fiche contact d’une personne appartenant à l’organisation (que ce soit un contact ou une mailbox) et sauvegardée dans mes contacts (devinez qui ? ):

Pour toutes ces raisons, il est essentiel de prendre garde au LDN lors de migrations inter-organisations pour prévenir les avis de non remise le lendemain de la migration d’une boite aux lettres … de V.I.P. … car pour résumer si Exchange ne trouve pas dans l’AD celui que votre Outlook a mis dans le message… NDR.

Je passe donc la plume à Ivan,

Guillaume

Migration et LegacyExchangeDN

Lorsque je me suis intéressé au LegacyExchangeDN (LDN), j’ai lu/posé des questions autour de moi et les réponses que j’ai obtenues m’ont fait comprendre que beaucoup de personnes avaient des raisonnements empiriques, et ne comprenaient pas les raisons techniques qui poussent à migrer cet attribut. Aussi, nous avons mené des tests, et le présent article va tenter d’éclaircir tout ça.

Ce qu’il faut savoir avant de commencer

Au ResolveP2 près, (voir plus loin) si je reçois un mail d’une personne située dans une autre organisation Exchange que la mienne, c’est l’adresse SMTP de l’expéditeur qui sera marquée dans le champ émetteur du mail

Si je reçois un mail d’une personne de la même organisation Exchange que moi (un collègue de travail m’envoie un mail par exemple), c’est le LDN de la boîte aux lettres de l’émetteur qui apparaît dans le champ émetteur du mail.

Pour les mails venant d’une autre organisation, si le ResolveP2 est actif (« résoudre la messagerie anonyme » sous Exchange 2003, ou mode d’authentification « sécurisé de l’extérieur » dans Exchange 2007), alors il y a 2 cas de figure :

a.       Il y a un contact, dans l’organisation cible, qui représente la personne émettrice. Dans ce cas, le mail reçu aura pour émetteur une adresse de type X500 correspondant au LDN du contact représentant l’émetteur

b.      Aucun contact ne représente l’émetteur dans l’organisation. Dans ce cas, le mail arrive dans la boîte aux lettres et le champ « émetteur » de ce mail est l’adresse SMTP de l’émetteur.

Conclusion : dans ma boîte aux lettres, les mails peuvent avoir dans le champ « émetteur » soit une adresse SMTP, soit une adresse X500. Il sera possible de répondre à tous les mails (que j’ai émis ou reçus) ayant pour émetteur une adresse SMTP (pourvu que les routes/connecteurs idoines soient en place évidemment). Dans le cas de mails ayant, dans le champ « émetteur », une adresse de type X500/LDN, ça se complique…

Maintenant parlons migration

Lors d’une migration, on a typiquement :

·         Des boîtes aux lettres dans la source, qui sont remplacées par des contacts.

·         Des contacts dans la cible, qui sont remplacés par des boîtes aux lettres.

Prenons un exemple :

·         Mon organisation Contoso migre ses boîtes aux lettres dans l’organisation Exchange Fabrikam.

·         Il y a 10 000 personnes dans Contoso et je suis la 5000^ème personne à migrer.

·         Lorsque je suis migré, je me retrouve avec les 5000 premiers migrés dans Fabrikam et il me reste 5000 collègues dans Contoso.

·         Au moment de la migration de ma boîte aux lettres:

o   un contact qui me représente a été créé dans Contoso, afin que j’apparaisse toujours dans la liste d’adresses globale (GAL) de mes collègues de Contoso d’une part, et que les mails qu’ils m’écrivent soient transférés dans ma nouvelle boîte aux lettres Fabrikam.

o   Un contact a été supprimé dans Fabrikam pour laisser la place à ma nouvelle boîte aux lettres.

1^er cas de NDR (Non-Delivery Report) : Que se passe-t-il si une personne encore dans Contoso répond à un mail que je lui avais envoyé avant d’être migré ?

Comme au moment où je lui ai écrit nous étions dans la même organisation, le champ « émetteur » du mail est une adresse de type X500 correspondant au LDN de mon ancienne boîte aux lettres dans Contoso.

Par conséquent, lorsque mon collègue répondra à mon ancien mail, sa réponse sera à destination du LDN de mon ancienne boîte Contoso. Or cette boîte n’existe plus (elle a été remplacée par un contact). Mon collègue recevra alors un rapport de non remise (NDR).

La solution consiste donc à injecter, dans l’attribut ProxyAddresses du contact qui remplace mon ancienne BAL, une adresse de type X500 correspondant au LDN de mon ancienne BAL Contoso.

2^ème cas de NDR : Le ResolveP2 est actif dans Fabrikam. Des collègues dans Fabrikam répondent à un mail que j’avais envoyé lorsque ma BAL était dans Contoso.

J’envoie depuis ma BAL Contoso un mail à des personnes déjà migrées dans Fabrikam. Le ResolveP2 est actif, et un contact me représente. Le champ émetteur du mail reçu contient une adresse de Type X500 correspondant au LDN du contact qui me représente dans Fabrikam.

Lorsque j’ai migré, mon contact Fabrikam est remplacé par ma nouvelle BAL.

Lorsque mes collègues Fabrikam répondent à mes vieux mails, ils répondent à une adresse X500 correspondant au LDN d’un contact qui n’existe plus (il a été remplacé par ma BAL). Ils reçoivent un NDR.

 La solution consiste donc à injecter dans l’attribut ProxyAddresses de la nouvelle BAL Fabrikam, le LDN du contact qui la représentait avant la migration.

Evidemment,  un doublon d’adresse étant interdit, le contact doit VRAIMENT avoir été détruit pour qu’un message arrive à destination.

Références:

• How to set X500 proxy addresses for Exchange Server 2003 recipients and for Exchange 2000 Server recipients: http://support.microsoft.com/kb/313324 
• Outil de mise à jour du profil Exchange: http://support.microsoft.com/kb/873214/fr

Conclusion

La migration des legacyExchangeDN vers les proxyaddresses de la cible est devenu une fonction standard de tous les outils de migration ou de synchronisation d’annuaires (Quest, IIFP …), en revanche la traduction des données de la boites aux lettres (contacts) ou local au profil (.NK2) est une fonction que tous les outils n’implémentent pas. Nous vous invitons à bien faire attention à ces aspects lors de vos futures migrations.

N’hésitez pas à faire appel à MCS, à votre PFE, ou à votre TAM pour ces questions, ou posez des questions dans le thread.

Ivan Robain

Vous aurez peut-être remarqué en jouant avec les groupes de sécurité Active Directory, en ajoutant des ACLs sur des OUs ou autre que des permissions sautent toutes seules sur des comptes …

Je m’apprête à parler ici de l’objet AdminSDHolder dans Active Directory

Cas de figure simple
Dans votre infrastructure, vous disposez d’une hot-line dédiée à la gestion des comptes AD verrouillés, des mots de passe oubliés ou expirés etc …
Les comptes admins de base en charge de cette tâche peuvent, par exemple, avoir été regroupés dans un groupe de sécurité, lui-même positionné sur une ou plusieurs OUs.
Ce groupe de sécurité peut, par exemple, disposer de droits basiques (mot de passe, compte, …)  sur l’ensemble des comptes utilisateurs contenu dans l’OU.
Oui mais voilà, dans cette OU, vous avez de nombreux comptes utilisateurs standard mais aussi les comptes de quelques administrateurs avancés voire administrateurs du domaine.
Il est ainsi facile pour un hot-liner de changer le mot de passe de ce fameux compte admin du domaine et de faire ce que bon lui semble….  

L’objet AdminSDHolder est là pour contrôler ce type de phénomène pas forcement prévu et qui peut potentiellement créer une faille de sécurité.

Concrètement de quoi s’agit’il ?
Cet objet est stocké dans la partition Système d’Active Directory et dispose d’une ACL stricte :

Il se manifeste par un processus d’arrière plan qui tourne par défaut toutes les heures sur le DC qui héberge le rôle “PDC Emulator”. Ce processus est en charge de comparer l’ACL de l’objet AdminDSHolder avec celle de tout les comptes appartenant à des “groupes protégés”.
Si l’ACL est différente, elle est écrasée et remplacée par celle de l’objet AdminDSHolder.

Il est important de noter que cette ACL est très restrictive et qu’elle a pour effet secondaire de désactiver l’option d’héritage d’ACL qui proviendrait d’un niveau supérieur.
C’est de cette manière qu’il est possible d’observer que des permissions “sautent” périodiquement sur certains comptes.

Quels sont ces “groupes protégés” ?
Cette liste était composée de 4 groupes en Windows 2000 Server RTM. Elle a peu à peu évoluée jusqu’à en contenir 13 dans Windows 2008 R2 :

Quelle est cette ACL “restrictive” ?
Cette ACL est différente de celle appliquée au domaine.

On note que l’objectif de ce processus est de sécuriser des objets, il est donc normal que l’ACL en question soit plus restrictive qu’une autre. Celle du domaine par exemple.

Ces restrictions se manifestent par :
- L’héritage de permissions désactivé.
- Le propriétaire par défaut est positionné sur le groupe “Admins du domaine” à l’instar de la plupart des objets AD qui sont positionnés sur le groupe “Administrateurs”. Le propriétaire d’un objet est le seul à pouvoir prendre pleinement le contrôle et réinitialiser complètement ses permissions.
- Enfin, les groupes “Admins du domaine”, “Administrateurs” et “Admins de l’entreprise” sont les seuls à pouvoir modifier les attributs de l’objet “AdminDSHolder”. La plupart des objets/attributs AD nécessitent des privilèges moins élevés pour être modifiés.

Est-il possible de modifier la fréquence de détection ?
Par défaut, ce processus s’exécute toute les 60 minutes.
Il est possible de régler ce temps via la clé de registre :

AdminSDProtectFrequency (DWORD) en secondes

Dans le conteneur suivant :

Exemple de commande pour une exécution toutes les 10 minutes :

Est-il possible de modifier son comportement ?

Il est possible de modifier dans une certaines mesure toutefois les groupes protégés par AdminDSHolder. Ceci est possible grâce à une KB pour Windows 2000 et 2003 Server et nativement depuis Windows 2008 toutes versions.

Il est ainsi possible d’exclure du contrôle les groupes suivants :

Account Operators – Server Operators – Print Operators -Backup Operators

Cette information est contenue dans le dernier caractère de l’attribut “dsHeuristic” de la partition de Configuration du domaine. Cet attribut est partagé au sein d’une même forêt.

Ce caractère, codé en Hexadecimal, correspond au tableau suivant :

Une fois la valeur définie, il est possible de procéder à la mise à jour de l’attribut “dsHeuristic”. Suivre le KB817433.

ATTENTION - Ces modifications peuvent avoir des conséquences irrémédiables dans votre Organisation et doivent impérativement être réalisées en plateforme de test au préalable. D'une manière générale, sauf besoin explicite, il n'est pas conseillé de modifier le comportement de ce mécanisme.

Comment savoir si un compte est protégé par AdminSDHolder ?
La méthode la plus fiable pour savoir si un compte est protégé par ce processus est de regarder l’attribut Active Directory  ”adminCount”. Si ce dernier est positionné à “1″, l’objet a été modifié par AdminSDHolder.

La requête PowerShell/LDAP suivante permet de retourner la liste des utilisateurs concernés :

La requête PowerShell/LDAP suivante permet de retourner la liste des groupes concernés :

Qu’est ce que la notion d’objets AdminSDHolder Orphelins ?

Lorsqu’un utilisateur ne fait plus partie d’un groupe protégé, il est important de savoir que l’attribut “adminCount” reste positionné sur la valeur “1″. 

De plus, l’option d’héritage d’ACL parentes qui pouvait être cochée avant, ne sera pas re-cochée. L’objet ne recevra donc plus d’ACL et passera ainsi dans un mode dit “orphaned AdminSDHolder objects”.

Ces objets devront donc, après extraction d’un groupe protégé, être traités manuellement. Un script VB fourni par Microsoft permet d’aider à ré-activer cet héritage sur ces comptes. Suivre la KB817433.

Conclusion

J’espère que ces quelques lignes vous aurons permises de comprendre un peu mieux ce mécanisme de sécurité assez peu connu.
 

Pour aller plus loin :

http://technet.microsoft.com/en-us/magazine/2009.09.sdadminholder.aspx

Le client Lync 2013 vous demande une authentification au réseau ? Dans ce cas, vous avez surement un problème de votre client Lync au niveau d’un proxy.

Cet article s’adresse aux utilisateurs Lync 2013 Office 365 et On Premise.

1. Mise à jour

Deux mises à jour corrigeant ce type de problème sur le client Lync 2013 sont sorties en septembre 2013.
La première corrige une demande d’authentification lorsque le client Lync télécharge les photos des contacts externes à l’entreprise. Ce problème s’applique à tous types d’entreprises, qu’elles aient un proxy ou non. La demande d’authentification est en réalité liée au proxy de l’entreprise du contact dont vous téléchargé la photo. Cette mise à jour est décrite ici.
La deuxième corrige aussi une demande d’authentification, mais cette fois-ci lorsque le client Lync télécharge une présentation Power Point. Cette mise à jour est décrite ici.
Donc la règle d’or est d’avoir la dernière version du client Lync, qui est disponible sur le Lync Update Center.

2. Proxy et exception

La plupart des proxys requièrent une authentification. Cela génère une fenêtre d’authentification ou parfois bloque le client Lync.

1. Pour un environnement On Premise
Pour répondre à cet incident, ajoutez dans vos exceptions proxy les URLs suivantes :

•  Les Simples URLs
•  Les domaines SIP
•  Les web services des pools Front-Ends et Directors
•  Les web services Exchange (EWS)
•  Les web services du serveur Office Web Apps
•  Les URLs de découverte automatique : 

• •  lyncdiscoverinternal.<domaineSIP>
  •  lyncdiscover.<domaineSIP>
  •  autodiscover.<domaineSMTP> pour la découverte automatique Exchange

2. Pour un environnement Lync Online
Si vous ne voulez pas que votre client Lync passe par un proxy, vous devez ajouter dans les exceptions de votre proxy les URLs décrites sur ce lien http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh373144.aspx

3. Le proxy PAC
Vous avez un proxy PAC renseigné dans Internet Explorer et une demande d’authentification au réseau du client Lync 2013 ?
Il est possible que votre client Lync 2013 ignore les règles sur le fichier proxy PAC. Certains enregistrements sont respectés par Internet Explorer mais ne le sont pas par Lync 2013. Dans ce cas, Lync 2013 continue de passer par le proxy alors qu’il devrait aller directement sur l’adresse spécifiée. Si le proxy requiert une authentification, le client Lync reçoit alors une demande d’authentification au réseau.
La solution de contournement dans ce cas, est de rajouter les lignes suivantes au début de votre script PAC. Cela permet de se connecter directement aux services web de découverte automatique Lync, sans utiliser de proxy.

if (url.substring(0, 28) == "http://lyncdiscoverinternal.") {                 return "DIRECT";                 }     if (url.substring(0, 29) == "https://lyncdiscoverinternal.") {                 return "DIRECT";                 }     if (url.substring(0, 21) == "https://lyncdiscover.") {                 return "DIRECT"; }

Suite à cet ajout, le problème devrait être résolu.
Pour vérifier que vous utilisez un proxy PAC, allez dans les options d’Internet Explorer, puis dans connexion et enfin dans les propriétés du LAN. Vous devriez avoir un adresse dans la configuration automatique d’un script comme ci-dessous.

Natacha MIKO, Premier Field Engineer, Microsoft France Ingénieur Conseil Grands Comptes chez Microsoft depuis 2011. Je suis spécialisée sur les technologies de Communication Universelle (Lync/OCS). J'interviens pour des missions réactives et proactives de courtes durées dans toute la France sur des sujets d’expertises techniques pour les clients Premier. Je fais du conseil, des formations, des installations, de la résolution d'incident, des audits... J'ai suis en charge d'une dizaine de clients différents par mois.

Office 365 permet plusieurs gestions de l’identité pour les utilisateurs. Les évolutions étant régulières, il est intéressant de faire un point sur ces méthodes et leurs mécanismes. Cet article a pour objectif de décrire brièvement les trois méthodes disponibles, de rappeler les concepts de l’authentification multi-facteurs et présenter les deux solutions de Microsoft : Windows Azure MFA et MFA for Office 365.

1° Quelles sont les méthodes de gestion des identités avec Office 365 ?

Il existe plusieurs moyens de gérer les identités dans Office 365 :

Les trois modèles de gestion de l’identité dans Office 365 peuvent être décris comme suit :

• Identité Cloud : Compte dédié et spécifique avec mot de passe géré dans Windows Azure Active Directory (WAAD). Note : le service WAAD est inclus avec les licences Office 365 mais son utilisation reste dans ce cas limitée à Office 365.
• Identité Cloud + Synchronisation d’annuaire : Utilisation de DirSync pour synchroniser les identités. La fonctionnalité de PasswordSync permet de synchroniser les mots de passe des comptes depuis l’Active Directory on-premises vers le WAAD.
• Identité Fédérée : utilisation d’un système de fédération et de la synchronisation de l’annuaire : les comptes sont synchronisés dans le cloud et l’authentification est réalisée par le système de fédération on-premises (à demeure)

2° L’authentification multi-facteurs, kézako ?

Une description très académique de l’authentification multi-facteurs (MFA en anglais) peut être faite par : l’utilisation d’au-moins deux des éléments suivants :

• Quelque chose que l’on connait : un mot de passe ou un code PIN
• Quelque chose qui nous appartient : un téléphone, une carte de crédit ou un token
• Quelque chose que l’on “est” : empreinte digitale, rétinienne …

La MFA est dite renforcée quand on utilise deux modes différents :

3° L’offre MFA de Microsoft

Microsoft fournit un service d’authentification multi-facteurs à travers deux offres différentes :

• MFA for Office 365
• Windows Azure multi-factor Authentication

Les deux services utilisent PhoneFactor, société acquise par Microsoft en 2012

MFA for Office 365:

• Authentification d’entreprise à l’aide de tout téléphone/smartphone
• Disponible gratuitement pour les administrateurs Office 365 et pour tous les utilisateurs Office 365 depuis février
• Fonctionne avec tous les services Office 365 de type Web
  • Outlook Web App, SharePoint Online
• Requiert des mots de passe applicatifs pour les clients riches
  • Non disponibles pour les administrateurs
  • 16 caractères générés

Il faut noter que MFA for Office 365 est disponible dans tous les plans de licences Office 365 et ne permet de sécuriser que les ressources Office 365.

Windows Azure MFA:

• Utilisé par des milliers d’entreprises pour authentifier les employés, clients et les partenaires
• Utilisé pour sécuriser les applications et les identités dans le Cloud et On Premise

4° Eléments de comparaison entre Windows Azure MFA et MFA pour Office 365

Globalement on peut noter que MFA for Office 365 est fourni gratuitement dans le cadre d’un plan de licence Office 365 et Windows Azure MFA est un service payant offrant un panel plus étendu de fonctionnalités. Voici un tableau comparatif des deux services :

La différence majeure entre les deux solutions est que Windows Azure MFA permet de fournir un service de multi-authentification pour les applications on-premises, qu’elles soient développées en interne ou commerciale (sous réserve de compatibilité bien-sûr). Alors que MFA for Office 365 est cantonné au cadre d’Office 365.

Voici quelques éléments de décision quant à la solution à adopter :

Cet article vous a présenté les méthodes de gestion de l’identité dans Office 365 et les solutions possibles pour implémenter une authentification multi-facteurs. Pour aller plus loin, je vous encourage à monter votre plateforme de tests et consulter la documentation disponible en ligne :

Windows Azure MFA :

http://technet.microsoft.com/en-us/library/dn249471.aspx

MFA for Office 365 :

http://technet.microsoft.com/en-us/library/7a9c56cf-72f1-4797-8e86-a9a2d9569ef6#whatareapp

Dans ce second article, je vous présente la mise en place et l'utilisation de "MFA for Office 365" :

Office 365 & Identités – Partie 2 – MFA pour Office 365

Jérôme BRUNELET, Consultant Communication Universelles, Microsoft Consulting Service France Un début de carrière dans l’écosystème des partenaires Microsoft m’a naturellement conduit à intégrer MCS en 2012. Depuis j’interviens en tant que Consultant Communications Universelles, plus spécifiquement sur les solutions de messagerie on-premises et Cloud de Microsoft.

Une page Technet assez méconnue récapitule l'intégralité des numéros de build pour Exchange 2007 et 2010 :

http://social.technet.microsoft.com/wiki/contents/articles/240.exchange-server-and-update-rollups-build-numbers.aspx

Et celle dédiée à Exchange 2013:

http://social.technet.microsoft.com/wiki/contents/articles/15776.exchange-server-2013-and-cumulative-updates-cus-build-numbers.aspx

:)