(Bump) Niemand die weet hoe je die in wijzigt naar https?

Zelfs niet eens een reactie van iemand die het met me eens is dat het echt niet meer kan dat instellingen standaard via http worden gedownload van buiten je domein?

https://blog.jamesbayley.com/2015/12/01/registry-hack-to-enable-outlook-2016-to-connect-to-office-365/

Hier staat wellicht iets waar je wat aan hebt.

https://support.microsoft.com/en-us/help/2212902/unexpected-autodiscover-behavior-when-you-have-registry-settings-under-the-autodiscover-key Kan je misschien helpen.

Je kunt in de registry de http redirect uitschakelen.

http redirect zet je uit, door de cname autodiscover.<jouw maildomein> weg te halen uit je DNS.
in plaats daarvan kan je een SRV-record maken in DNS met als inhoud de HTTPS url.
De gebruiker krijgt daar wel een melding van. Voor intern gebruikers is deze melding met een Outlook policy uit te zetten.

Een alternatief is alleen https//autodiscover.<jouw maildomein> zelf te hosten en daarop je redirect naar Microsoft te doen.
Paul

Als je ze op je netwerk langs ziet komen dan heb je URLs die je kan downloaden en inspecteren. Als je <bedrijfsnaam> in ziggo verandert krijg je er in ieder geval een te pakken. Er staan instellingen voor IMAP, POP3 en SMTP in, serverinstellingen voor e-mail. Zo te zien gaat het om een protocol om e-mailclients automatisch te configureren. Dit lijkt me iets dat eenmalig plaatsvindt als iemand in zijn of haar e-mailclient een account toevoegt. Hoe vaak doe je dát in de trein of in een hotel?

Ik ben het er roerend mee eens dat dit beter via HTTPS kan plaatsvinden, maar het risico lijkt me beperkt. Ik weet niet hoe die laptops worden uitgeleverd en beheerd, maar als de eindgebruikers een laptop krijgen waarin dit soort instellingen al gedaan is dan zou die hele autoconfiguratie niet geactiveerd moeten worden voor jullie eigen e-mailaccounts. Ik hoop althans niet dat Outlook instellingen die al geconfigureerd zijn telkens opnieuw gaat ophalen en overschrijven.

Aanpassing maken in je hosts file?

Dank aan Anoniem gisteren 19:56 en NedFox; ik heb beide suggesties gevolgd, zeer leerzaam. Ook dank voor alle andere antwoorden die ik zojuist zie, ik was even bang dat er nauwelijks nog serieuze bezoekers waren op deze site!

Uit https://blog.jamesbayley.com/2015/12/01/registry-hack-to-enable-outlook-2016-to-connect-to-office-365/:
Dat vind ik nou juist een security risico!

In https://johnyassa.com/tag/excludehttpredirect/ vond ik dat je door deze de (DWORD) waarde 1 te geven, http voorkomt en dat blijkt prima te werken (in de situatie bij ons).

Voor de mensen die AutoDiscover helemaal willen uitschakelen leek http://blog.aocsol.com/2015/03/28/cannot-turn-off-outlook-autodiscover-yes-you-can/ mij een interessante pagina.

In de pagina waar NedFox naar verwijst staat een link naar o.a. https://technet.microsoft.com/en-us/library/jj591328%28v=exchg.141%29.aspx met zeer veel informatie. Alleen is deze pagina voor Office 2010 en Microsoft wijzigt vaak veel tussen versies. Er wordt ook verwezen naar een pagina voor Office 2013 maar die bevat niet veel tekst. Die Office 2010 pagina beschrijft globaal welke informatie in autodiscover.xml wordt uitgewisseld:
Dat klinkt echt niet als informatie die je clients wil laten opdringen vanaf een potentieel kwaadaardige server via http.

Anoniem vandaag 08:33: "Er staan instellingen voor IMAP, POP3 en SMTP in"
Dus als een client een vervalst antwoord krijgt, met bijv. IMAP en POP3 URLs naar een kwaadaardige server, dan zal die client daar braaf username en password naartoe sturen. Totaal onacceptabel!

Ik kan alleen maar hopen dat bij https het servercertificaat goed gevalideerd wordt, maar de volgende "feature" uit https://technet.microsoft.com/en-us/library/jj591328%28v=exchg.141%29.aspx doet mij daar wel aan twijfelen:
Als dat nog waar is voor actuele Outlook versies, lopen domain-enabled clients die zich buiten dat domain begeven ook risico's als ze slechts https gebruiken.

Anoniem 08:57: ik ben me niet bewust van iets dat je met de hosts file zou kunnen doen om https ipv http te forceren.

Uiteindelijk heb ik nu als test de volgende instellingen gemaakt:
En dit lijkt tot zover prima te werken (nogmaals voor non-domain notebooks met Office365 die vooral buiten het pand worden gebruikt): nadat de DNS query "autodiscover.<bedrijf>.nl" als CNAME o.a. teruggeeft "autodiscover-emeacenter2.outlook.com" wordt met die laatste site meteen een https verbinding opgezet (dus geen http meer).

Als ik eens wat meer tijd heb zal ik eens kijken wat er gebeurt als ik "127.0.0.1 autodiscover-emeacenter2.outlook.com" in m'n hosts file opneem en deze een self-signed certificaat laat teruggeven.

Nogmaals dank voor de reacties!

Jawel, maar gebeurt het ook? Zitten medewerkers van jouw organisatie werk-emailaccounts op hun werk-laptop te configureren in een hotel of vliegtuig? Of is wat ze voor hun werk nodig hebben misschien al geconfigureerd voordat hun werk-laptop jullie organisatie verlaat? Wordt dat autoconfigure-protocol nog wel geactiveerd als de configuratie al heeft plaatsgevonden?

Dat zijn zaken die het werkelijke risico mede bepalen. Als die accounts al geconfigureerd zijn en autoconfigure wordt niet meer geactiveerd dan is het risico ineens een enorm stuk lager dan jij nu aanneemt. Ook als je het onacceptabel vindt dat dat protocol is zoals het is. Dat zijn dus vragen om serieus te onderzoeken en te beantwoorden, anders maak je geen goede risicoinschatting. En als jullie medewerkers inderdaad onderweg dat soort accounts nog aan moeten maken moet je daar dringend iets aan doen, dan is jullie werkwijze namelijk een beveiligingsrisico.

(TS hier) Zoals zoveel MKB's tegenwoordig wordt Office365 voor bedrijven met bijbehorende Exchange gebruikt. Hoewel je nooit weet wat users allemaal uitvreten, bedoel ik hier niet het risico dat gebruikers het initiatief nemen om e-mail instellingen te wijzigen.

Het probleem is dat Outlook bij opstarten, maar ook regelmatig tussendoor, autodiscover.xml downloadt (vermoedelijk juist om verder unmanaged accounts centraal te kunnen beheren). Zolang zo'n configuratiebestand van de bedoelde en vertrouwde server(s) afkomstig is, is dat natuurlijk prima.

Waar ik mij zorgen over maak is dat zij een vervalste autodiscover.xml terugkrijgen die hen vraagt (waarschijnlijk in een typische Microsoft dialoogbox) om hun e-mail adres en (bijv. IMAP) wachtwoord in te vullen. Ik vrees dat de meeste gebruikers dat niet goed lezen en hun Office365 wachtwoord zullen invullen, waarmee hun login gegevens eenvoudig in verkeerde handen kunnen vallen.

Dit is toegegeven wat speculeren, maar http naar een server om allerlei settings op te vragen, is vragen om moeilijkheden. En die kan ik op deze manier voorkomen (in elk geval geen belangrijke data meer via http maar slechts via https).

Ah, ik begrijp nu pas wat je ziet gebeuren. Uit wat je schreef, dat "notebooks [...] standaard een http request eruit gooien", haalde ik niet dat je met "standaard" bedoelt dat Outlook bij opstarten en tussendoor voor al lang en breed geconfigureerde accounts opnieuw configuratiegegevens ophaalt.

Het technet-artikel waar je zelf gisteren om 09:54 al naar linkte geeft trouwens relevante informatie onder het kopje "Scenario 4: Using the Autodiscover service with redirection". Dat verwijst naar een andere paragraaf die aangeeft dat twee HTTPS-URLs worden geprobeerd om dan uit te leggen dat er een fallback naar HTTP is:
HTTP wordt dus pas geprobeerd als het via HTTPS niet lukt. Je moet dan inderdaad je gebruikers instrueren hoe ze daarmee om moeten gaan, maar je vrees dat niet alle gebruikers daar goed in zijn kan natuurlijk makkelijk terecht zijn.

Je bent kwetsbaar als een MITM de toegang via HTTPS weet te blokkeren, of wanneer jouw servers door een storing uit de lucht zijn en een aanvaller daarop gokt, en Outlook dan terugvalt op HTTP zodat de aanvaller daarop in kan haken. Outlook zal met HTTPS de URLs https://<domein>/autodiscover/autodiscover.xml en https://autodiscover.<domein>/autodiscover/autodiscover.xml proberen, waarbij <domein> uit het e-mailadres wordt gehaald, en dus een DNS-request voor <domein> doen en pas als die geen autodiscover.xml oplevert een voor autodiscover.<domein>. De laatste is voor een aanvaller pas herkenbaar bedoeld voor autodiscover, en het wordt niet als eerste geprobeerd. Dat betekent dat een aanval op autodiscover al gauw meer dan alleen autodiscover beïnvloedt op een manier die zichtbaar is voor de gebruiker. Maar ook dat levert geen volledige bescherming op. "Shit, de website doet het niet, eens kijken of e-mail nog wel werkt" is een plausibele reactie van een gebruiker, ook van een goed voorgelichte gebruiker die niet voortdurend alert is.

Het werkt zoals Microsoft het bewust ontworpen heeft, en daarbij heeft gebruikersgemak een hoge prioriteit:
De deur staat denk ik niet wagenwijd open, maar er is wel degelijk een restrisico op een geslaagde aanval. Doordat het kwetsbare scenario pas aan bod komt als direct veilige verbindingen opzetten niet lukte, en doordat dan ook nog eens een herkenbaar autodiscover-domein als laatste wordt geprobeerd, denk ik dat een aanvaller die deze kwetsbaarheid wil misbruiken dat alleen kan doen met een risico dat zijn aanval nogal opvallend ook andere zaken onderuit haalt. Microsoft heeft het risico daarop zo te zien laag genoeg ingeschat om het ondergeschikt te maken aan dat gebruikersgemak.

Als je het restrisico wilt elimineren dan zou je kunnen denken aan een stateful firewall op de laptops die HTTP-requests naar de kwetsbare URL blokkeert. Als Outlook niet zelf ergens een instelling heeft die voorkomt dat HTTP nog geprobeerd wordt, natuurlijk, maar ik neem aan dat je dat al hebt uitgezocht. Dat zou wel een nuttige feature-request zijn om bij Microsoft in te dienen, lijkt me.

Als je Office 365 hebt, waarom maak je dan hiervoor geen ticket bij Microsoft voor aan? Dit zit tenslotte gewoon in je licenties?
Je hebt dan direct een specialist, je je exact kan vertellen wat de mogelijkheden zijn.

Misschien heb ik tot nu toe pech gehad met Microsoft support, maar veel verder dan een "zit de stekker erin" niveau van support ben ik nog niet tegengekomen. Ik heb daar helaas al teveel tijd aan verspild.

Ik heb dit een tijdje gevolgd met Wireshark en zag altijd als eerste een http poging. Los daarvan wil ik gewoon NOOIT http (unauthenticated+unencrypted ARP, DHCP, DNS en WiFi zijn ook echt niet meer van deze tijd maar daar liggen geen breed ondersteunde/algemeen geaccepteerde alternatieven voor op de plank, zoals bij https i.p.v. http).

Liever heb ik dan dat Outlook niet werkt, dan gaan ze vanzelf bellen en lossen we het probleem op.

Die "seamless experience" ken ik van Microsoft, dat vindt zij belangrijker dan security. In ons geval staat de deur wel degelijk wagenwijd open. Een notebook buiten het pand (zonder VPN o.i.d.) laten zoeken naar SCP in AD en/of SRV records is natuurlijk ook zinloos.

Microsoft gaat er (helaas) van uit dat elke zakelijke PC wel aan AD zal hangen, maar (A) is dat niet waar en (B) leidt dat tot problemen en allerlei security risico's als je een domain-lid-notebook buiten je netwerk aan internet hangt (vooral als je NETBIOS hostnames gebruikt, of wereldwijd-niet-unieke hostnames.local of iets dergelijks).

En dat iets in Microsoft documentatie staat, wil niet zeggen dat dit klopt (in https://support.microsoft.com/en-us/help/2212902/unexpected-autodiscover-behavior-when-you-have-registry-settings-under-the-autodiscover-key staat bijv. "Some documentation states that the ExcludeSrvLookup value is used by Outlook in this scenario. Unfortunately, this documentation is incorrect as the ExcludeSrvLookup value does not exist in Outlook code").

Als eerste zie je DNS-requests, als het goed is, anders is er geen IP-adres beschikbaar om een HTTP-request op te richten. Weet je zeker dat je álles hebt gevolgd?
Als het niet klopt heb je een ernstige bug te melden bij Microsoft.

Wat me aan je reactie opvalt is dat je wél reageert met wat er volgens jou allemaal mis is maar níet op de suggestie dat je met een stateful firewall op de laptops de ongewenste HTTP-requests kan afvangen. Me dunkt dat je daarmee precies zou bereiken wat je zegt te willen bereiken: dat het domweg niet werkt en 'ze' vanzelf gaan bellen. Die suggestie werkt ook als Outlook niet in de gedocumenteerde volgorde mogelijkheden afwerkt maar HTTP eerst probeert; het is een suggestie waar je een testopstelling voor kan maken om te verifiëren dat hij werkt.

Wil je het eigenlijk wel oplossen? Of wil je vooral redenen blijven aandragen waarom er van alles niet deugt?

Ik heb ondertussen contact gezocht met Microsoft omdat ik vermoed dat niet alleen wij hier risico's door lopen (ik heb nog geen antwoord ontvangen maar zal jullie in deze pagina op de hoogte houden).

??? Het lijkt mij knap lastig om met een (al dan niet stateful) firewall op elke notebook http verkeer naar onvoorspelbare IP-adressen van Microsoft te blokkeren, zonder daarbij mogelijk andere dingen kapot te maken.

Maar ik heb al een oplossing voor ons probleem, dus firewall aanpassingen zijn helemaal niet aan de orde (op 19-06-2017 om 09:54 schreef ik dat ik, aan de hand van tips van anderen, had gezien dat ik ons probleem relatief eenvoudig kan oplossen met een registry entry namelijk ExcludeHttpRedirect = 1). Vervolgens heb jij (en wellicht anderen) bijdragen gepost die ik zo goed en zo netjes mogelijk heb geprobeerd te beantwoorden.

Jouw constatering dat ik daarbij moeite heb om mijn Microsoft-frustraties te verbergen is juist, vervelend als je daar problemen mee hebt maar ik ga mijn gedrag niet aanpassen. Niet dat ik een "Linux-adept" ben of zo (ik ben daar ook niet vies van, use the right tool for the job) maar wij betalen Microsoft voor producten met een kwaliteit die echt stukken beter kan. Waarom loop ik tegen dit soort fouten aan die Microsoft zelf eenvoudig kan detecteren (door http requests naar Autodiscover.xml op hun servers te monitoren, naast alle telemetrie die onze notebooks naar Redmond sturen)? Hoe kan bijvoorbeeld mjurczyk van Google Security Research in zo korte tijd zoveel bugs vinden waar Microsoft kennelijk niet zelf eerder naar heeft gezocht (bij voorkeur vóór het uitrollen)? Gisteren 34 gepubliceerd, zie https://packetstormsecurity.com/files/author/11978/.

HTTP-verkeer is onversleuteld, en de request bevat de naam van de host en het pad binnen de host dat wordt opgevraagd. Je kan dus zonder je druk te maken om IP-adressen de URL herkennen.

Oeps, mijn fout. Excuses voor de manier waarop ik reageerde.

Geen enkel probleem! Ik ben ook wel eens bot...

Overigens (helaas) nog geen antwoord van Microsoft.

Misschien inmiddels niet meer relevant, maar toch even vermeld:

Het aanmaken van een SRV is 1. hier wordt namelijk al protocol meegegeven.

Name: _autodiscover._tcp
TTL: 3600
RR Type: SRV
Value: 0 443 mail.company.com.

Verder kan je natuurlijk op je eigen www het autodiscover folder met autodiscover.xml aanmaken. https wordt hierin ondersteund (volgens de activesync analyser steps)
Zelf zou ik, indien DNSSEC ondersteund wordt door de provider hier nog TLSA records op aanmaken, gekoppeld aan het domein certificaat.

stappen welke de analyser doorloopt:
1 Attempting to test potential Autodiscover URL https://
2 Attempting to test potential Autodiscover URL https://
3 Attempting to contact the Autodiscover service using the HTTP redirect method.
4 Attempting to contact the Autodiscover service using the DNS SRV redirect method.
5 Attempting to locate SRV record _autodiscover._tcp.
The Autodiscover SRV record was successfully retrieved from DNS.

Additional Details
Attempting to test potential Autodiscover URL https://