none
Outlook Anywhere demande authentification RRS feed

  • Question

  • Hello,

    Depuis ce matin, outlook anywhere demande sans arrêt authentification (login/mot de passe). 

    Si je décoche l'option "se connecter en utilisant SSL uniquement" dans les paramètre de compte => paramètres supplémentaires => onglet connexion => paramètres proxy Exchange . Il demande une fois authentification au lancement d'outlook et il se synchronise bien. Et si on recoche l'option ci-dessus, rebelote.

    Auriez vous une idée d'ou ça peut venir. Jusqu'au aujourd'hui ça marchait sans problème.

    Pour info: Il s'agit d'exchange 2007 installé sur 2003 server. Outlook 2010. Et le certificat est bien valide jusqu'au 2016.

    Merci

    jeudi 12 mars 2015 13:00

Réponses

  • Je pense avoir trouvé... le problème vient de ce KB de microsoft:

    http://www.infoworld.com/article/2895900/security/microsoft-netlogon-patch-kb-3002657-woes-continue-kb-3032359-cisco-anyconnect-fix-confirmed.html

    je pense pas avoir le seul à ce problème. Pour l'instant je n'ai pas encore supprimé la MAJ de mon contrôleur de domaine. En revanche sur les PC qui ont ce problème j'ai forcé niveau d'authentification LAN Manger en LN et NTLM et ça marche.

    J'attends que si Microsoft sort un patch.

    vendredi 13 mars 2015 16:07

Toutes les réponses

  • Bonjour,

    Il y a toujours une raison lorsque cela s'arrête de fonctionner du jour au lendemain.

    As-tu relancé tes services Exchange et IIS ?

    As-tu vérifié si la connectivité Autodiscover fonctionnait correctement (CTRL+Clic droit sur l'icône Outlook dans la zone de notification puis "Tester la configuration automatique") ?

    Peux-tu nous poster le résultat du test de configuration automatique ?


    Cordialement,

    Sylvain

    Blog : http://sylvaincoudeville.fr

    jeudi 12 mars 2015 13:04
  • Il faut configurer outlook anywhere (coté serveur CAS) d'utiliser l'authentifcation NTLM.

    ref : http://www.sysadminlab.net/exchange/outlook-anywhere-basic-vs-ntlm-authentication-explained

    "With Basic, the user will always get prompted for username/password when they start their Outlook configured for OA."

    jeudi 12 mars 2015 13:07
  • J'ai complètement rebooté deux fois le serveur.

    Comme tu as dit, j'ai testé la configuration automatique de la messagerie sur un pc qui dispose d'un compte outlook anywhere. (le pc n'est pas sur le réseau local)

    J'ai donc les erreurs:

    Autodiscover to https://mon-domine.fr/autodiscover/autodiscover.xml starting

    Autodiscover to https://mon-domine.fr/autodiscover/autodiscover.xml Failed (0x800C8203)

    Autodiscover to https://autodiscover.mon-domine.fr/autodiscover/autodiscover.xml starting

    Autodiscover to https://autodiscover.mon-domine.fr/autodiscover/autodiscover.xml Failed (0x800C8203)

    Local autodiscover for mon-domaine.fr starting

    Local autodiscover for mon-domaine.fr Failed (0x8004010F)

    Redirect check to http://autodiscover.mon-domine.fr/autodiscover/autodiscover.xml starting

    Redirect check to http://autodiscover.mon-domine.fr/autodiscover/autodiscover.xml Failed (0x80072EE7)

    Et j'ai des erreurs également dans les lignes: Guessmart POP, IMAP, SMTP

    Je ne peux pas exporter pour vous envoyer le journal.

    jeudi 12 mars 2015 13:27
  • Les erreurs sont là.

    Le poste est hors domaine, et il ne trouve pas le service Autodiscover car je suppose que les FQDN mon-domaine.fr. et autodiscover.mon-domaine.fr. sur Internet ne pointent pas vers ton serveur Exchange ?

    Pour régler ce problème, il faut ajouter un enregistrement SRV sur ton domaine Internet (mon-domaine.fr) :

    • Type d'enregistrement : SRV
    • Nom : _autodiscover._tcp
    • Priorité : 0
    • Port : 443
    • Cible : le FQDN public de ton serveur Exchange

    Cet enregistrement va permettre à l'Outlook de trouver le serveur Exchange en autoconfiguration.

    Ensuite, il faudra patienter le temps de refresh de ton domaine pour que les changements soient pris en compte par ton Outlook.


    Cordialement,

    Sylvain

    Blog : http://sylvaincoudeville.fr


    jeudi 12 mars 2015 13:31
  • En fait, notre site mon-domaine.fr était chez sfr. Nous l'avons migré juste le site chez OVH.

    Aujourd'hui si je fait un dig mon-domaine.fr A il affiche l'ip du serveur OVH qui héberge le site. (la gestion DNS reste chez SFR)

    Mais nous n'avons jamais eu d'entrée DNS autodiscover.mon-domaine.fr. Nous avons l'adresse owa.mon-domaine qui pointe toujours vers notre serveur exchange.

    donc je ne comprends pas pourquoi outlook anywhere fonctionnait  avant sans autodiscover.mon-domaine.fr ?!

    Merci

    jeudi 12 mars 2015 13:40
  • L'autoconfiguration d'Outlook teste plusieurs URL dont mon-domaine.fr et autodiscover.mon-domaine.fr.

    Mais il teste aussi la présence d'un enregistrement SRV : cet enregistrement existe t-il et pointe t-il vers owa.mon-domaine.fr ?

    Utilise la commande suivante pour vérifier :

    nslookup -q=SRV _autodiscover._tcp.mon-domaine.fr 8.8.8.8


    Cordialement,

    Sylvain

    Blog : http://sylvaincoudeville.fr

    jeudi 12 mars 2015 13:43
  • Effectivement il me retourne que google ne parvient pas à trouver _autodiscover.tcp_.mon-domaine.fr

    Mais je viens d'ajouter l'entrée ci-dessous dans mon fichier host. autodiscover.mon-domaine.fr. Ensuite quand je fait un test automatique de la messagerie je n'ai plus l'erreur au niveau d'autdiscover. Mais quand je lance outlook il me demande toujours login/mdp.

    jeudi 12 mars 2015 14:09
  • Il n'y a plus d'erreur sur l'autodiscover d'accord, mais le test de configuration automatique retourne t-il les bons noms de serveur pour OAB, ECP, etc... dans l'onglet résultat ?

    Cordialement,

    Sylvain

    Blog : http://sylvaincoudeville.fr

    jeudi 12 mars 2015 14:14
  • Je viens refaire un test, j'ai toujours des Failed au niveau d'autodiscover... (pourtant l'entrée DNS existe toujours dans mon fichier host.)

    Je peux toujours demandé à SFR d'ajouté l'entrée ci-dessus, Mais je ne comprend pas comment outlook anhywhere pu fonctionner jusqu'au maintenant ?!  Avez vous une idée ?

    jeudi 12 mars 2015 14:39
  • J'ai le même problème depuis hier après-midi. Toujours ce popup quand je lance outlook, je n'y comprends rien, encore hier matin tout fonctionné parfaitement. Le pire dans tout çà c'est que cela fonctionne uniquement avec mon compte utilisateur du domaine, mais mon compte a les mêmes droits que l'ensemble de mes collaborateurs.

    Il nous faut un miracle :)

    jeudi 12 mars 2015 14:51
  • Si tu fais pointer autodiscover.mon-domaine.fr vers ton serveur Exchange, il faut que le certificat serveur contienne bien le nom "autodiscover.mon-domaine.fr" pour que cela fonctionne.

    Est-ce que ton certificat Exchange contient "autodiscover.mon-domaine.fr" ?

    Si Oui, le fichier host permettra de contourner le problème en attendant la création de l'enregistrement SRV chez SFR.
    Si Non, il faut passer par l'engistrement SRV, pas le choix!


    Cordialement,

    Sylvain

    Blog : http://sylvaincoudeville.fr

    jeudi 12 mars 2015 14:51
  • J'ai le même problème depuis hier après-midi. Toujours ce popup quand je lance outlook, je n'y comprends rien, encore hier matin tout fonctionné parfaitement. Le pire dans tout çà c'est que cela fonctionne uniquement avec mon compte utilisateur du domaine, mais mon compte a les mêmes droits que l'ensemble de mes collaborateurs.

    Il nous faut un miracle :)

    Il faudrait que tu commences par créer une question rien que pour toi dans le Forum, afin de ne pas mélanger les diagnostics et réponses, sinon ça va devenir ingérable !

    Merci


    Cordialement,

    Sylvain

    Blog : http://sylvaincoudeville.fr

    jeudi 12 mars 2015 14:56
  • Nos problèmes sont assez liés mais d'accord je comprends.

    Cordialemenet

    jeudi 12 mars 2015 15:20
  • En affichant le certificat, j'ai bien l'entrée autodiscover.mon-domaine.fr dans le champ "autre nom de l'objet".

    J'ai bien pointé autodiscover.mon-domaine.fr vers mon serveur exchange (ip externe) au niveau de mon fichier host.

    Mais outlook me demande toujours login/mdp

    quand je fais lance un test automatique de la messagerie, j'ai:

    Protocol : Exchange RPC

    Server: URL interne de mon serveur exchange

    Login Name: mon compte

    Availability Server URL: https://url_interne_fr/EWS/Exchange/asmx

    OOF URL: https://url_interne_fr/EWS/Exchange/asmx

    OAB URL: http://url_interne_fr/EWS/Exchange/OAB/c92AA371...

    Unified message service url: https://url_interne_fr/EWS/unifiedMessaging/service.asmx

    Protocol : Exchange HTTP

    Server: URL externe de mon serveur exchange

    Login Name: mon compte

    SSL: Yes

    Mutual Authentification: Yes

    Availability Server URL: https://url_interne_fr/EWS/Exchange/asmx

    OOF URL: https://url_interne_fr/EWS/Exchange/asmx

    OAB URL: http://url_interne_fr/EWS/Exchange/OAB/c92AA371...

    Unified message service url: https://url_interne_fr/EWS/unifiedMessaging/service.asmx

    Auth Package: NTLM

    Certificate Principale Name: msstd.owa.mon-domaine.fr

    jeudi 12 mars 2015 15:26
  • Et bien, on est face à un problème classique de configuration des URL internes et externes.

    Connectes-toi sur ton Exchange, ouvre un Exchange Management Shell et saisis les commandes suivantes :

    Set-ClientAccessServer –AutodiscoverServiceInternalUri “owa.mon-domaine.fr/autodiscover/autodiscover.xml” 
    Set-WebServicesVirtualDirectory –ExternalUrl “owa.mon-domaine.fr/ews/exchange.asmx” 
    Set-OabVirtualDirectory –ExternalUrl “owa.mon-domaine.fr/oab” 
    Set-OwaVirtualDirectory –ExternalUrl “owa.mon-domaine.fr/owa” 
    Set-EcpVirtualDirectory –ExternalUrl “owa.mon-domaine.fr/ecp” 
    Set-ActiveSyncVirtualDirectory -ExternalUrl "owa.mon-domaine.fr/Microsoft-Server-ActiveSync"

    Ensuite, tu demandes à SRV de déclarer l'enregistrement suivant :

    Type : SRV
    Name : _autodiscover._tcp
    Port : 443
    Priorité : 1
    Poids : 1
    Cible : owa.mon-domaine.fr

    Après ça normalement, tu seras blindé !

    Pour info : http://social.technet.microsoft.com/wiki/contents/articles/5163.managing-exchange-2010-externalinternal-url-s-via-powershell.aspx


    Cordialement,

    Sylvain

    Blog : http://sylvaincoudeville.fr


    jeudi 12 mars 2015 15:43
  • Peux-tu m'expliquer si cela ne prend pas beaucoup de temps, pourquoi notre confrère et moi-même sommes peut-être obligé de taper toutes ces commandes powershell, alors qu'hier tout fonctionné correctement?

    Bien cordialement

    jeudi 12 mars 2015 18:31
  • Ce qui est vraiment bizarre pour moi, c'est dès fois ça marche et dès fois non ...

    Hier j'ai mit autodiscover.mon-domaine.fr dans mon fichier host et cela fonctionnait, alors que ce matin j'ai mit la même entrée sur le fichier host d'un collègue et ça ne marche pas.

    Et sur ma machine si j'enlève l'entrée autodiscover.mon-domaine.fr et ça continue à fonctionner... Donc à mon avis le problème est ailleurs ?! 

    vendredi 13 mars 2015 08:23
  • Bonjour Kveen et Latino4226,

    La question n'est pas pourquoi cela fonctionne des fois oui, des fois non, mais plutôt pourquoi est-ce que la cela a pu fonctionner ! Ca, c'est une énigme vu la configuration.

    Pour qu'une installation d'Exchange avec un domaine interne différent du domaine externe, il faut OBLIGATOIREMENT :

    • Renseigner les ExternalUrl comme indiqué dans mon post plus haut
    • Obtenir un certificat (chez Symantec, GoDaddy etc. de préférence) qui contient les noms d'hôte indiqués dans ExternalUrl et InternalUrl
    • Avoir une résolution de noms Interne et Externe impéccable (IP LAN en interne, IP WAN en externe)
    • Déclarer un "domaine.fr", "autodiscover.domaine.fr" ou un enregistrement SRV sur le domaine Externe pour que l'autodiscover fonctionne depuis Internet
    • Activer OutlookAnywhere avec le nom d'hôte Externe

    Sans cela, vous allez tout droit vers des problèmes aléatoires comme vous subissez actuellement.


    Cordialement,

    Sylvain

    Blog : http://sylvaincoudeville.fr

    vendredi 13 mars 2015 08:30
  • toujours pas mieux de mon côté ...

    Quand je tape l'url https://url-interne-de-mon-exchange/EWS/Exchange.asmx dans un navigateur, il me demande sans cesse login/mdp. Donc outlook ne fonctionne pas. Quelques minutes plus tard j'arrive à me connecter sur la page web avec login/mdp et outlook fonctionne également. Pas d'erreur dans les logs de IIS et ni observateur d'événement ...

    Je me demande si il n'y pas une limite de connexion au niveau d'exchange qui expliquerai ça ?!

    merci

    vendredi 13 mars 2015 13:50
  • Bonjour,

    Peux-tu vérifier que les paramètres d'authentification sont corrects du côté IIS avec l'article ci-après : https://technet.microsoft.com/fr-fr/library/gg247612%28v=exchg.141%29.aspx

    Et peux-tu vérifier s'il y a des erreurs dans les journaux d'événément sur le serveur Exchange aux moments où l'authentification échouait?


    Cordialement,

    Sylvain

    Blog : http://sylvaincoudeville.fr


    vendredi 13 mars 2015 13:52
  • Pardon, voici l'article version 2007 : https://technet.microsoft.com/en-us/library/gg263433%28v=exchg.80%29.aspx

    Et pour les limites de connexion, en effet : peux-tu vérifier qu'il ne te manque pas des licences d'accès client Windows Server 2003 (j'ai bien dit des CAL Windows Server, pas Exchange) ?


    Cordialement,

    Sylvain

    Blog : http://sylvaincoudeville.fr

    vendredi 13 mars 2015 13:55
  • Le Licence service est désactivé sur mon DC. Donc les Cals ne sont pas surveillés. Si je ne me trompe pas il y a des quelques windows et il y a aussi des cals exchange. J'aimerais trouvé un moyen pour vérifier si on n' pas dépassé la limite de ces de cal.
    vendredi 13 mars 2015 14:12
  • Le Licence service est désactivé sur mon DC. Donc les Cals ne sont pas surveillés. Si je ne me trompe pas il y a des quelques windows et il y a aussi des cals exchange. J'aimerais trouvé un moyen pour vérifier si on n' pas dépassé la limite de ces de cal.

    Les CAL Exchange ne sont pas déclarées dans Exchange.

    As-tu vérifié les paramètres d'authentification dans IIS : https://technet.microsoft.com/en-us/library/gg263433%28v=exchg.80%29.aspx


    Cordialement,

    Sylvain

    Blog : http://sylvaincoudeville.fr

    vendredi 13 mars 2015 14:24
  • tout est identique à l'exception de:

    RPC: J'ai que Ingetrated Windows authentification au lieu de: 

    • Windows authentication

    • Basic authentication

    Public: Dans le tableau il n'y a rien au niveau de SSL alors que j'ai:

    • SSL required

    • Require 128-bit encryption

    RPCClientCert: dans le tableau il y a que SSL required alors que j'ai:

    • SSL required

    • Require 128-bit encryption

    vendredi 13 mars 2015 14:53
  • j'ai cette erreur dans obs. d'événement:

    Inbound authentication failed with error LogonDenied for Receive connector Default SRVEXCHANGE. The authentication mechanism is Ntlm. The source IP address of the client who tried to authenticate to Microsoft Exchange is [172.16.XX.XX].

    vendredi 13 mars 2015 14:56
  • Je pense avoir trouvé... le problème vient de ce KB de microsoft:

    http://www.infoworld.com/article/2895900/security/microsoft-netlogon-patch-kb-3002657-woes-continue-kb-3032359-cisco-anyconnect-fix-confirmed.html

    je pense pas avoir le seul à ce problème. Pour l'instant je n'ai pas encore supprimé la MAJ de mon contrôleur de domaine. En revanche sur les PC qui ont ce problème j'ai forcé niveau d'authentification LAN Manger en LN et NTLM et ça marche.

    J'attends que si Microsoft sort un patch.

    vendredi 13 mars 2015 16:07
  • j'ai cette erreur dans obs. d'événement:

    Inbound authentication failed with error LogonDenied for Receive connector Default SRVEXCHANGE. The authentication mechanism is Ntlm. The source IP address of the client who tried to authenticate to Microsoft Exchange is [172.16.XX.XX].


    Ce message d'erreur concerne une tentative d'authentification via NTLM sur le Connecteur de Réception "Default SRVEXCHANGE"

    Cordialement,

    Sylvain

    Blog : http://sylvaincoudeville.fr

    vendredi 13 mars 2015 16:12
  • Je pense avoir trouvé... le problème vient de ce KB de microsoft:

    http://www.infoworld.com/article/2895900/security/microsoft-netlogon-patch-kb-3002657-woes-continue-kb-3032359-cisco-anyconnect-fix-confirmed.html

    je pense pas avoir le seul à ce problème. Pour l'instant je n'ai pas encore supprimé la MAJ de mon contrôleur de domaine. En revanche sur les PC qui ont ce problème j'ai forcé niveau d'authentification LAN Manger en LN et NTLM et ça marche.

    J'attends que si Microsoft sort un patch.

    En effet, ce patch (MS15-027) a été publié lors du patch tuesday de mars. Il s'est donc installé sur ton parc mercredi soir, avec les premiers effets jeudi (ton WSUS approuve automatiquement les nouveaux patchs sans délai je présume ?)

    Merci en tout cas d'avoir partagé la solution avec nous.


    Cordialement,

    Sylvain

    Blog : http://sylvaincoudeville.fr

    vendredi 13 mars 2015 16:17
  • Je pense avoir trouvé... le problème vient de ce KB de microsoft:

    http://www.infoworld.com/article/2895900/security/microsoft-netlogon-patch-kb-3002657-woes-continue-kb-3032359-cisco-anyconnect-fix-confirmed.html

    je pense pas avoir le seul à ce problème. Pour l'instant je n'ai pas encore supprimé la MAJ de mon contrôleur de domaine. En revanche sur les PC qui ont ce problème j'ai forcé niveau d'authentification LAN Manger en LN et NTLM et ça marche.

    J'attends que si Microsoft sort un patch.

    En effet, ce patch (MS15-027) a été publié lors du patch tuesday de mars. Il s'est donc installé sur ton parc mercredi soir, avec les premiers effets jeudi (ton WSUS approuve automatiquement les nouveaux patchs sans délai je présume ?)

    Merci en tout cas d'avoir partagé la solution avec nous.


    Cordialement,

    Sylvain

    Blog : http://sylvaincoudeville.fr

    un grand merci pour le lien, cela a solutionné mon problème comme je l'avais dit une foutu mise à jour, m'a cassée la tête durant 2 jours! ( Ah microsoft quand tu nous tiens :) )

    Un grand merci à tous et surtout sylvain, j'ai appris de nombreuse info grace à toi!!

    Bien cordialement

    vendredi 13 mars 2015 19:18