dolezel.net

Co není v hlavě, je v blogu...

W2003 DC a dva prima hotfixy

Dnešní den jsem plánoval něco zcela jiného. Nakonec to dopadlo tak, že jsem se celý den snažil pochopit, co se to proboha stalo ve dvou různých firmách, ve kterých se v noci nainstalovaly na servery hotfixy. A od rána prudí uživatelé, že se nemůžou přihlásit přes RDP na server, že se jim Outlook nedokáže přihlásit k Exchange 2003 či Exchange 2010, ale přitom přes OWA vše jde. A nefunkční jsou i Outlooky na MAC OS X. Teď, po dvanácti hodinách, už samozřejmě vidím souvislost, ale ráno ani omylem. Takže co se to vlastně stalo?

Microsoft vydal hromadu hotfixů. Ti, kdo si chtějí (bláhově) ušetřit práci a mají na serverech zvolenou automatickou instalaci, se v rámci tohoto pravidelného “aktualizačního úterý” mohli se zlou potázat. Teď už vím, že to ovlivnilo jen domény, v nichž jsou coby doménové řadiče nasazeny Windows 2003 – Microsoft se zjevně připravuje na ukončení podpory a hotfixy patrně netestuje tak důkladně, jak by si zasloužily.

Prvním z prů…švihových hotfixů je KB3002657, který ošetřuje zranitelnosti ve službě NETLOGON. Druhým je pak hotfix KB3046049, který se snaží vyřešit problémy s tzv. FREAK attack. Zatímco na W2008/2008R2/2012/2012R2 se problém neprojevil, tak na na W2003 doménových řadičích se jednalo o smrtelnou kombinaci. O to záludnější, že se problém neprojevil na DC, ale na ostatních členských serverech domény. Tj. zatímco na DC jsme se přes RDP mohli připojit, na W2008-based Exchange 2010 už nikoliv – dokud jsme ze zoufalství nepřekonfigurovali RDP Security Level na RDP-based security.

Co se týče Outlooku, otestoval jsem si, že RPC over HTTPS (neboli Outlook Anywhere) přestal fungovat jak z Outlooku 2007, tak 2010 a dokonce i 2013. A naopak napřímo napojený Outlook 2007 přes MAPI jel jako z praku. Takže bylo evidentní, že je to problém na serveru a díky Exchange proxy funkci musí jít o o něco související s HTTPS, certifikáty, potažmo NTLM či Kerberos autentizací. Proto jsem si nakonec sestavil výpis všech hotfixů, které byly na servery v posledních dvou dnech automaticky nainstalovány, a začal jsem hledat v MSKB, co konkrétně se snaží opravit. Podezřelé se mi zdály dva – ty, které jsou uvedeny v předchozím odstavci. Nakonec jsem začal googlit na téma těchto čísel a “problem” a konečně jsem našel, co jsem hledal – podobného zoufalce, který napsal příhodně napsaný článek KB3002657 breaks everything! Teď koukám, že autor se trochu prospal a doplnil stránku o mnoho dalších informací, logů. Přibylo zde taktéž mnoho dalších komentářů, z nichž vyplývá, že MS support diagnostikoval, že problémem je pouze KB3002657.

Pokud tedy máte doménový řadič s W2003, tomuto hotfixu se velkým obloukem vyhněte.

Pro tisk

Komentáře (7) -

  • Kalousek E.

    13. 3. 2015 8:46:53 |

    Děkuji

  • Václav Mlejnek

    13. 3. 2015 9:24:14 |

    Ještě bych přidal vyzkoušený odkaz na serverfault.com/.../has-march-2015-patch-tuesday-broken-2003-shares kde problém řeší změnou zabezpečení sítě ve Windows 7 z výchozí nedefinované hodnoty na "Send LM & NTLM responses." Nebo, pokud to někomu pomůže, český postup:

    1. Otevřete "Start | Ovládací panely | Nástroje pro správu | Místní zásady zabezpečení".
    2. Zvolte "Místní zásady | Možnosti zabezpečení" a otevřete "Zabezpečení sítě: Úroveň ověřování pro systém LAN Manager"
    3. Nastavte hodnotu "Odesílat odpovědi LM a NTLM"

    • Radek

      13. 3. 2015 9:27:03 |

      Tohle jsem taky zkoušel, ale bylo to v prvních hodinách, kdy jsem nevěděl, že problém není na serveru, kde se to projevuje, ale na DC. Tam jsem to asi nezměnil. Pokud by někdo dokázal potvrdit, že stačí tuto úpravu zadat v Default Domain Controllers policy, dejte vědět. Bylo by to o dost jednodušší než si hlídat ten jeden pitomý hotfix.

      • Václav Mlejnek

        13. 3. 2015 9:33:31 |

        Ještě bych zdůraznil, že výše popisovanou změnu zásad zabezpečení si musí každý uživatel provést na svých Windows 7, ze kterých přes doménový kontroler Windows Server 2003 přistupuje na další servery v té doméně. U nás ve firmě zatím úspěšně ověřeno na třech klientských počítačích s Windows 7.

        • Radek

          13. 3. 2015 9:36:14 |

          Aha, takže v Default Domain Policy. A pro všechny. Hm, tak to už pak ale opravdu může něco rozbít. Určitě se mi nelíbí varianta s LM. Mohli byste otestovat NTMLv2 only? Protože best practise je se LM zbavit úplně, LM hashe hesel jsou hodně slabé.

          • Václav Mlejnek

            13. 3. 2015 9:45:21 |

            Ano, vyzkoušel jsem a volba NTLMv2 only neprojde. Nicméně je to výběr mezi dvěma riziky, zda se obejít bez důrazně doporučované záplaty nebo bez NTLMv2.  Osobně věřím, že se u Microsoftu brzy vzpamatují a nejdéle do měsíce, jak bývá v kraji zvykem, to opraví.

    • Radek

      13. 3. 2015 9:30:45 |

      Tak teď čtu ten článek a nezdá se mi to. To, co jsem včera našel já, naopak zmiňovalo nutnost posílit úroveň ověřování a ne ji ponížit. Protože pokud je default "Send NTLM only" a změníte to na "Send LM & NTML responses", tak to není moc secure. Já právě našel odkazy, že je nutné nastavit "Send NTLMv2, refuse LM". Ale jak píšu, nastavoval jsem to na špatných serverech, nikoliv na problematických DC.

Komentáře jsou uzavřeny