Category Archives: Exchange

Manage auditing and security logs (SeSecurityPrivilege) chybí/mizí

Pokud skupině Exchange Enterprise Servers chybí právo „Manage auditing and security logs“ (SeSecurityPrivilege), což lze snadno ověřit utilitou \SUPPORT\EXDEPLOY\policytest.exe z Exchange CD, pak nám nastávají závažné potíže. Obyčejně nám začne failovat spouštění Exchange služeb, především Information Store.

Do logu můžem dostávat:

Event ID 7024, Service Control Manager:
   „The Microsoft Exchange Information Store service terminated with service-specific error 0 (0x0).“

Event ID 1121, MSExchangeIS:
   „Error 0x80004005 connecting to the Microsoft Active Directory.“

Event ID 5000, MSExchangeIS:
   „Unable to initialize the Microsoft Exchange Information Store service. – Error 0x80004005.“

Event ID 2103, MSExchangeDSAccess:
   „Process MAD.EXE (PID=2356). All Global Catalog Servers in use are not responding:“

…a podobné

Můžeme to snadno napravit setup.exe /domainprep, nicméně někdy ani to trvale nepomůže a dost krušné chvíle nám mohou nastat, pokud toto právo po čase mizí (policytest.exe nejdřív OK, později failuje).

Naštěstí už je člověk naučený, že pokud nějaké právo samovolně mizí, jsou prvním podezřelýmzásady zabezpečení (lokální, doménové, …). Je tedy potřeba ohlídat, aby nám zásady zabezpečení právo „Manage auditing and security logs“ pro doménovou skupinu „Exchange Enterprise Servers“ nelikvidovaly (je to v User Rights Assignments).

Připojení Outlooku RPC over HTTP(S) na Exchange

Na netu jsou stovky návodů, jak nakonfigurovat RPC over HTTP komunikaci Outlooku s Exchange serverem, např.

Návody jsou to celkem srozumitelné, nicméně může nastat mnoho zásadních zádrhelů, které návody nedostatečně zmiňují, či málo zdůrazňují. Některé, na které jsem narazil já:

Certifikát k HTTPS spojení musí být důvěryhodný

Pokud používáme k HTTPS certifikát generovaný vlastní certifikační autoritou (CA), pak musíme na klientském počítači zajistit, aby připojení k serveru probíhalo čistě, bez jakéhokoliv promptu Internet Exploreru na certifikát. Outlook totiž tento prompt nepodporuje a spojení zamítne.

V podstatě je potřeba nainstalovat certifikát na klienta, třeba přístupem na https://server/rpc/rpcproxy.dll. Musíme dosáhnout stavu, aby se nás to ptalo jen na heslo, na nic jiného. Nainstalovaný certifikát nám však bude fungovat jen v případě, že máme instalovaný i certifikát CA – ten je v členských počítačích domény instalován automaticky (pokud CA používá AD), na nečlenských počítačích je potřeba ho instalovat samostatně.

Pozor – narazil jsem na problém, kdy IIS mělo přidělený certifikát, ale mezi tím došlo k reinstalaci CA. Certifikát na IIS tak neodpovídal kořenovému certifikát CA. Internet Explorer to navíc pojal po svém. Místo, aby ohlásil neplatný certifikát, tak po instalaci kořenového certifikátu na jakýkoliv HTTPS požadavek vůči příslušnému serveru odpovídal chybou „Server nebyl nalezen nebo došlo k chybě v systému DNS.“ (jako kdyby server neexistoval).

Global Catalog na jiném serveru

Pokud máme scénář s jedním Exchange serverem, na kterém navíc běží i doménový řadič (DC), může se zdát, že není co řešit. Zásadní komplikace však nastane, pokud máme v doméně více DC a Global Catalog je na jiném serveru, než Exchange.

Který server je Global Catalogem poznáme v konzoli Active Directory Sites and Services, pokud si nalistujeme příslušný server, položku „NTDS Settings“ a k ní Properties – tam je zaškrtávací políčko Global Catalog. Jak přesunout GC na jiný server je mimo dosah tohoto článku.

Pokud tedy máme GC na jiném serveru, nestačí nám standardní konfigurace portů (hodnota ValidPorts), protože potřebujem na port 6004 dostat právě process lsass.exe z GC.

Jedna možnost je přesunout GC na stejný server k Exchange. Druhou možností je nastavit klíč registru „NSPI interface protocol sequences“ i na GC server a na exchange serveru nastavit v klíči „ValidPorts“ port 6004 na GC server (NetBIOS jméno i FQDN). V Outlooku pak jako server exchange vyplníme NetBIOS název GC serveru.

Pozor na to, že nám ve standardním nastavení funguje dokonce i RPCPING, protože si server s exchange na port 6004 nasadí vlastní proces lsass.exe. Nicméně Outlook zahájí komunikaci a nic se nepřipojí. V logu webové služby jsou též korektní řádky RPC_IN_DATA a RPC_OUT_DATA se success kódem 200.

Troubleshooting nástroje a doporučení

  • spouštět Outlook s parametrem outlook /rpcdiag (též Ctrl+RClick na tray-ikonu Outlooku a volba Connection Status…)
  • telnet localhost 6001,  6002, 6004 (ze serveru) dává banner „ncacn_http/1.0“
  • netstat -ano (ze serveru) nám říká, jaké procesy obsluhují jaký portu (6001-store.exe, 6002-mad.exe, 6004-lsass.exe nebo mad.exe),
  • utilita rpcping z Windows Server Resource Kitu (z klienta),
  • utilita rpcdump z Windows Server Resource Kitu (z klienta i ze serveru),
  • adresa https://server/rpc/ se musí ptát na heslo a pak odpovědět 401.3,
  • adresa https://server/rpc/rpcproxy.dll se musí ptát na heslo a pak odpovědět prázdnotou,
  • v logu webové služby musí být záznamy RPC_IN_DATA a RPC_OUT_DATA, kód 200.
  • při nastavování accountu v Outlooku musí být v základním dialogu interní jméno serveru a až v nastavení RPC over HTTPS se dávají public jména serveru (ty se musí shodovat se jménem, na které je vystaven certifikát pro SSL)

Exchange neodesílá, snaží se doručovat na divné IP adresy

Symptom

Pozoruhodné chování Exchange 2003 serveru. Neodchází maily do věšiny domén, zbytek zůstává ve frontě. Po bližším ohledání je v eventech vidět, že Exchange na některé pokusy vyhodí chybu, že mu protější strana neodpovídá. Z některých eventů je poznat, že komunikuje s podivnými IP adresami protější domény, které neodpovídají MX záznamům, ale jiným adresám v cílové doméně (nejpíš hlavní adresy domény, blíže jsem neprozkoumal).

Do domén, kde se adresa SMTP serveru náhodou shoduje s takto určenou IP adresou Exchange serveru, tak tam jsou maily doručeny v pohodě.

Příčina

Toto podivuhodné chování se projevilo na stroji Windows 2003 Server R2, který neměl na síťovém rozhraní nastaven DNS server. DNS služba však na něm běžela (to však nemusí být podstatné).

Každopádně stačilo nastavit DNS sám na sebe a vše se hned rozjelo. Čím resolvoval doposud, těžko říct. Očekával bych, že nebude resolvovat vůbec, ale nějak resolvoval…