Autodiscover

· A mai cikkemben arról a funkcióról fogok részletesen írni ami nem is Auto és nem is kizárólag Discovery. Korábban már elhasználtam azt a közhelyes fordulatot, hogy “tanácsadóként mennyi problémát okoz” egy témakör helyes pozícionálása. De nem tudok mást mondani az Autodiscover kapcsán sem. A leggyakoribb tévhit az Autodiscover kapcsán általában az, hogy ez az automatikus Outlook profil generáláshoz szükséges “valami” ezért hát nincs is rá szükségünk. Ezen a ponton a legkiválóbb magyarázatokkal szoktam találkozni, amibe laikusként valóban nehéz is hibát felfedezni:

• • mi kézzel generáljuk a profilokat és / vagy
  • (ál)biztonsági megfontolásból nem szerencsés, hogy tudja bárki is az Exchange szerverünk nevét akár az Internet, akár a belso hálózat irányából és / vagy
  • már van egy jó kis scriptünk ami legenerálja az Outlook profilokat

De mint azt már megszokhattuk, a dolgok általában nem azok, aminek látszanak. Sokszor lényegesen összetettebbek mint azt várnánk. Ez igaz az Exchange Autodiscover szolgáltatásra is. Az Autodiscover használata az Exchange esetében nem opcionális valami “jó ha van” kategóriájú funkció. Ez a ténymondatunk ehhez a bejegyzéshez tartozóan.

Ahogy általában lenni szokott, mi is elkövettünk mindent annak érdekében, hogy ez a témakör is kicsit nehezebben legyen értheto a kelleténél. Hogy mást ne mondjak, az Understanding Autodiscover hivatalos anyagunk elso mondatai között szerepel a következo idézet: “The Autodiscover service makes it easier to configure Outlook 2007 or Outlook 2010 and some mobile phones.“. Tehát részben értheto a félreértés.

Ahogy Einstein mondta: “Mindent le kell egyszerusíteni, amennyire csak lehet, de nem jobban.”

Nézzük hát, hogyan látom a világot és tárjuk kicsit szélesebbre az ablakot, had jöjjön be több információ a külvilágból.

Miért és mikor van szükség az Autodiscover funkcióra?

Régen valamikor az idoszámítás elott az élet részben egyszeru volt. Exchange Server 2003 esetében, Outlook 2003-ig bezárólag a kommunikáció a kliens és a kiszolgáló között TCP alapú RPC volt. Természetesen a kísérletezo kedvueknek már volt lehetoségük arra, hogy a HTTP alapú RPC továbbítását használják (rpc over HTTP, vagy mai nevén Outlook Anywhere), de lássuk be nem ez volt a jellemzo. A TCP alapú RPC kapcsolathoz egyetlen információra volt csak szüksége a kliens komponensnek: Exchange Server neve (no és persze a megnyitni kívánt postaláda). Ezt azonban a modernkori technológiák kicsit átrajzolták.

Exchange Server 2007 (és újabb, késobb már nem írom ki, csak általában Exchange Server-ként hívom) és Outlook 2007 (és újabb) komponensek megjelenése óta a TCP alapú RPC kapcsolattal párhuzamosan megjelentek a natív Web Service hívások is az Exchange világában. Az Outlook kliens Web Service hívó, az Exchange Server pedig Service szolgáltatói szerepkörben muködik. Az eredeti terminológia a Web Service definíciójából származóan: Service Requester és Service Provider. Tehát az Outlook ha akarjuk, ha nem számos funkció használatánál Web Service hívásokat indít. Jó tudni, hogy az Exchange kiszolgálók egymás között is kommunikálnak Web Service hívásokkal. A Web Service hívások esetében azonban további információra is szüksége van az Outlook kliensnek. Nem elegendo csak az Exchange Server nevének ismerete. Így megérkeztünk ahhoz a ponthoz amihez a tervezok is úgy kb. 6-7 éve. Szükségünk van egy új technológiára aminek a segítségével ejutathatunk egyéb információkat is az Outlook klienshez.

Körberajzoltuk az elozo bekezdésben azt, hogy miért van szükség az Autdiscover szolgáltatásra. Most nézzük a leggyakoribb funkciókat amiknek a muködéséhez elengedhetetlenül fontos az Autodiscover helyes muködése:

• • Elfoglaltsági adatok kezelése
  • Kapcsolatnélküli címjegyzék letöltése (OAB)
  • Házon kívüli automatikus válasz konfigurálása
  • Archive postaláda
  • Archiváláshoz használható levél címkék
  • OWA címének megjelenítése az Outlook-ban
  • Levél nyomon követési funkció az Outlook-ból
  • Exchange Control Panel integráció az Outlook-ban
  • Outlook Anywhere beállításai (végpont, azonosítási mód, tanúsítványhoz kapcsolódó beállítások stb.)

Architektúra

Nézzünk egy magas szintu architektúrát a kiszolgáló oldali Autodiscover szolgáltatásról:

A terminológiának megfeleloen van egy Service Requestor és egy Service Provider. A Service Provider az Exchange esetében a Client Access Server (CAS) szerepköru kiszolgáló. A Service Provider oldalon a Service Requestor-tól érkezo kéréseket az Autodiscover Service fogadja. Az Autodiscover Service kéréseit több belso szolgáltató is megválaszolhatja. Jelenleg két belso szolgáltató van használatban (Outlook és Mobile Sync), de ez tovább bovítheto, így az architektúra alaposan végiggondolt és jól skálázódik. A belso szolgáltatók ha igény van rá, akkor egy “Services discovery” interfészen keresztül, más Service Provider Autodiscover Service-vel kommunikálhat. Erre bizonyos helyzetekben szükség is van, de most ezen ne gondolkodjunk, késobb majd tárgyaljuk ezt is. Az architektúra tehát elég egyszeru, de ezek az emelkedett szintu architektúra leírások általában mindenkit untatnak. Hol vannak ezek, hogy tudom ezeket a komponenseket megérinteni?

Az Autodiscover Service az Exchange CAS szerepköru kiszolgálókon a következo helyen érheto el:

• • Fájl rendszer: %Program Files%\Microsoft\Exchange Server\v14\ClientAccess\Autodiscover
  • IIS:

Honnan tudjuk, hogy hol van az Autodiscover végpont?

Ez a “tyúk vagy a tojás” dilemmája. Az Autodiscover segíti az Outlook klienseket abban, hogy a muködésükhöz szükséges elengedhetetlenül fontos információkat megszerezzék. De honnan tudja az Outlook, hogy ki az Autodiscover végpont?

Nagyon érdekes és elég szerteágazó téma ez a kérdés. A befogadhatósági szintig fogunk ebben a kérdésben lefúrni. Ezek alapos megértésével a komplikáltabb esetek már automatikusan összerakhatóak lesznek bárki számára.

Eloször is az alapkérdés megválaszolását több részre kell bontanunk. Két paraméter jelentos mértékben befolyásolja azt, hogy az Outlook kliens az Autodiscover-t hogy használja. Ezek a paraméterek:

• • tartományi tagság – a tartományi tag gépek logikus döntésként eloször próbálkoznak az Active Directory alapú felderítéssel, késobb fognak hozzá csak egyéb módszerekhez
  • hálózati hely – hiába is tartományi tag a gépünk, ha olyan hálózaton van, ahonnan a tartomány vezérloivel (tartományvezérlo) nem tud kommunikálni, akkor egyéb módszereket kell használnia az Autodiscover végpont megállapításához

A cikkemben a fenti két pontot fejtem ki bovebben.

Tartományi tagság

Nézzük meg eloször közelebbrol a tartományi tagság alapú felderítés muködését. Amikor egy CAS szerepköru kiszolgálót telepítünk, akkor egy új IIS Virtual Directory jön létre a kiszolgálón. Ezzel együtt létrejön egy új Service Connection Point (továbbiakban csak SCP) objektum. Az SCP az Active Directory címtárban elhelyezett útjelzo táblaként fogható fel. Ez a funkció nem Exchange specifikus, a címtár lehetoséget biztosít arra, hogy ilyen útjelzo táblákat helyezhessünk el. Ha egy alkalmazásnak szüksége van arra, hogy megtalálja a szolgáltatást biztosító kiszolgálót akkor egyszeruen egy jól meghatározott LDAP kéréssel lekérdezheti azt, hogy kihez kell fordulnia.

Az SCP a címtárunkban a Configuration partíció alatt található. A teljes elérési út: CN=Autodiscover,CN=Protocols,CN=<CASSzerverNeve>,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=<ExchangeOrganizációNeve>,CN=Microsoft Exchange,CN=Services,CN=Configuration,dc=<TartományNeve>

Tehát minden telepített CAS kiszolgálóhoz tartozik egy ilyen SCP objektum. Két kiemelkedoen fontos tulajdonsága van ennek az objektumnak, amiket a következo képen is megjelöltem:

• • keywords – ez egy multi-value (több értéket felvehet) tulajdonság, amiben a CAS kiszolgáló Active Directory telephelye van és egy állandó érték. Az Active Directory telephely funkciója az, hogy ez alapján a kliens eldöntheti, hogy az adott CAS kiszolgálóval azonos telephelyen van-e vagy sem. Az állandó érték funkciója az, hogy az Outlook kliens egyszeruen tudjon szurni az LDAP kérés során, ugyanis több termékhez tartozóan is lehet SCP a címtárban. Így egyszerubb univerzálisra megcsinálni az LDAP szurot.
  • serviceBindingInformation – ez az adott CAS kiszolgálón az Autodiscover teljes elérési útja, az Autodiscover kliens ide fog csatlakozni ha ezt az SCP-t választja ki végül.

A legfontosabb építoköveit a tartományi tagság alapú felderítésnek összefoglaltuk. A folyamatot így könnyen megérthetjük amiben a következo ábra is segít minket:

• • Az Outlook csatlakozik egy Global Catalog (GC) kiszolgálóhoz és egy LDAP lekérdezést elküld. Ebben az LDAP lekérdezésben arra kéri a GC-t, hogy az összes SCP-bol, ahol a Keyword megegyezik a használt állandóval, küldje vissza a keyword és a serviceBindingInformation információkat.
  • Az Outlook kliens visszakapja az összes elérheto CAS kiszolgálót, majd azokat a következo csoportosításba rendezi:
    • velem azonos Active Directory telephelyen levo CAS-ok
    • velem nem azonos Active Directory telephelyen levo CAS-ok
  • Ha a sorba rendezés megtörtént, akkor megpróbálja a sorban elso CAS kiszolgálóhoz tartozó serviceBindingInformation nevu tulajdonságban levo teljes elérési úton található kiszolgálóval felvenni a kapcsolatot, ha az sikertelen, akkor a sorban következo CAS kiszolgálóhoz fordul.
  • Ha egyik CAS kiszolgáló sem érheto el, akkor úgy kezd el viselkedni mint a tartományon kívüli gépek, vagy mint azok a tartományi tagsággal rendelkezo gépek amik nem érik el a tartomány vezérloit. Ennek a részletes a leírását lásd késobb.

A folyamat tehát nem komplikált. Azonban ezen a ponton érdemes egy kicsit megállnunk néhány apróbb gondolat erejéig. Az egyik ilyen a keyword tulajdonság pontosítása. Megtanultuk, hogy a keyword tulajdonságban a CAS kiszolgáló Active Directory telephelye szerepel. Azonban jó ha tudjuk, hogy ez dinamikusan nem változik. Vagyis ha A telephelyrol B telephelyre áthelyezzük a kiszolgálót, akkor semmilyen háttér folyamat nem fogja ezt az értéket frissíteni. Ezt nekünk kézzel kell megtennünk! A másik fontos tudnivaló ezzel kapcsolatban, hogy ez egy multi-value típusú tulajdonság. Vagyis több Active Directory telephelyet adhatunk hozzá. Mindkét információ kritikus jelentoséggel bír akkor, ha optimalizálni szeretnénk a rendszereinket és nem szeretnénk ha Active Directory telephelyek között kereszttípusú forgalom lenne. Támogatott módon a keyword tulajdonságnak az értékeit az Exchange PowerShell segítségével a set-clientAccessServer és get-clientAccessServer parancsok segítségével manipulálhatjuk. A cmdlet-ek segítségével az AutoDiscoverSiteScope értékét kell módosítanunk (tehát keyword = AutoDiscoverSiteScope).

További érdekesség, hogy a kliens a vele azonos telephelyen és a vele nem azonos telephelyen belül levo CAS kiszolgálókat egyaránt azok telepítési ideje alapján teszi sorrendbe! Ezt terheléselosztás szempontjából mindenképpen figyelembe kell vennünk. Hogy ennek a hatását jobban megértsük, vegyük a következo nagyon egyszeru példát: adott egy Active Directory telephelybol álló infrastruktúránk, amiben van összesen két darab CAS kiszolgáló. Az összes Outlook kliens, visszakapja mindkét CAS kiszolgálót és azonos sorrendet állítanak fel, mindenkinél az elsoként telepített CAS kiszolgáló lesz a sorban elso helyen. Mi lesz a hatása? Az, hogy az összes Outlook kliens Autodiscover lekérdezése ugyanahhoz a CAS kiszolgálóhoz megy és nincs terheléselosztásunk. Mi a megoldás erre az esetre? Alapvetoen két megoldási lehetoségünk van.

1. Az egyik lehetoség az, hogy ezt egyszeruen tudomásul vesszük.
2. A második lehetoség az, hogy az igényeinknek, pénztárcánknak megfelelo NLB technológiát kiválasztjuk és azt implementáljuk, ezzel lesz egy közös IP címünk amin keresztül elérheto lesz mindkét CAS kiszolgáló. Ehhez az IP címhez aztán regisztrálunk egy DNS nevet amit a CAS által használt tanúsítványhoz hozzá adunk. Legvégül módosítjuk a serviceBindingInformation értékét és hozzáadjuk az NLB nevet. Az érték módosításának támogatott módja az Exchange PowerShell, set-clientAccessServer. A CAS kiszolgálón a cmdlet segítségével az AutoDiscoverServiceInternalUri tulajdonságot kell módosítani, ez a címtárban a serviceBindingInformation tulajdonságnak felel meg.

Utolsó apróság, amit érdemes tudni, az a tanúsítványhoz kapcsolódik. Az Outlook 2007 az önaláírt tanúsítványt elfogadja akkor, ha a kliens tartományi tag. Az Outlook 2010-ben ez megváltozott. Hiába tartományi tag a munkaállomás, az önaláírt tanúsítványt nem fogadja el, felhasználói beavatkozásra van szükség.

DNS alapú felderítés

Az elozo fejezetben megtanultuk azt, hogy miként muködik az Active Directory telephely alapú felderítés. Most áttekintjük azt, hogy a DNS alapú felderítés hogyan muködik.

DNS alapú felderítést akkor használunk, ha az Active Directory alapú folyamat valamiért nem hoz pozitív eredményt (nem tartományi tag, nem éri el az SCP-t stb.). Ezekben az esetekben a DNS alapú felderítést fogja használni a kliens.

Az Outlook ennél a felderítési módnál igencsak nehéz helyzetben van. Nincs ott az Active Directory címtár amire támaszkodhatna. Így csak az általa már jólismert adatokra hagyatkozhat. Egy ilyen jól ismert adat a felhasználó email címe. Az email cím egy kiváló kiindulási állapot, hiszen abból az SMTP domain jól meghatározható. A felhasznalo@contoso.hu címet megadva, az Outlook máris tudja, hogy a contoso.hu SMTP tartományhoz kell megkeresnie az Autodiscover végpontot. Elore meghatározott sorrendben az SMTP domain információból építkezve az Outlook összeállít DNS neveket, amiken keresztül megpróbálja elérni az Autodiscover végpontot. A sorrend és a használt formula a következo (ha bármelyik pozitív eredményre vezet, az Outlook nem próbálkozik tovább):

• • https://<smtp Domain>/autodiscover.autodiscover.xml
  • https://autodiscover.<smtp Domain>/autodiscover/autodiscover.xml
  • https://autodiscover.<smtp Domain>/autodiscover/autodiscover.xml
  • SRV Record alapú felderítés

Álljunk meg néhány szóra és mindegyik pontnál helyettesítsük be a contoso.hu-t.

Így az elso URL-nél azt kapjuk, hogy https://contoso.hu/autodiscover/autodiscover.xml . Ez maga a DNS domain és nem egy DNS rekord. Hogy kell bekonfigurálnunk a DNS-t ahhoz hogy ez muködjön? Ugyanis alapértelmezésben ha létrehozunk egy DNS zónát, akkor az “nem pingelheto”. Technikaiabban megfogalmazva: a zónához alapértelmezésben nem tartozik A rekord. Ezt úgy oldhatjuk fel, hogy a DNS zóna alatt egy új A rekordot hozunk létre, de nem adunk neki nevet.

Ennek a hatása az lesz, hogy a rekord a SOA és NS rekordhoz hasonlóan úgynevezett “same as parent folder”-ként jön létre és így már feloldható lesz a contoso.hu mint A rekord. Vagyis egybol muködhet az elso próbálkozása az Outlook-nak.

Ha nem elérheto az https://contoso.hu/autodiscover/autodiscover.xml abban az esetben az Outlook a sorban halad tovább és megpróbálja elérni a https://autodiscover.contoso.hu/autodiscover/autodiscover.xml elérési utat. Ennek a muködéséhez a contoso.hu tartományban egy Autodiscover nevu A rekordot kell felvennünk. Ez nem komplikált, ehhez sok hozzáfuzni való nincs.

Ha ez sem érheto el, akkor megpróbáljuk elérni a https://autodiscover.contoso.hu/autodiscover/autodiscover.xml elérési utat. Ahol a hangsúly a HTTP-n van, S nélkül. Ez egy elég ritkán és speciális környezetekben használt megoldás. Hogy jobban megértsük, képzeljük el a következo helyzetet: email szolgáltatók vagyunk és naponta “jönnek-mennek” az SMTP névterek. Új ügyfelek jönnek akiknek saját SMTP névterük van, régi ügyfelek elmennek tolünk. Ez teljesen normális üzletmenet. Minden új SMTP névtérhez tartozóan a DNS-ben felvesszük az autodiscover A rekordot és elvégezzük a tuzfalon a publikációját. Azonban van itt egy fontos pont. Az pedig nem más mint a tanúsítvány. Minden alkalommal új tanúsítványt állítunk ki amikor egy új SMTP névteret kell kiszolgálni, vagy megszüntetni (hiszen ne tévesszük szemelol azt, hogy az Autodiscover célja az, hogy HTTPS-en keresztül menjen)? Ugyanis az Outlook ebbol a szempontból könyörtelen. Ha a tanúsítványban szereplo Subject, vagy Subject Alternate Name mezoben nem szerepel az a DNS név, amin keresztül csatlakozni szeretnénk az Autodiscover végponthoz, akkor figyelmeztetést fog visszaadni a felhasználónak. Mint tudjuk a felhasználó is könyörtelen és ezen a ponton el is vesztettük a játékot. Tehát azért, hogy a surun változó környezetekben ezzel ne kelljen szembesülnünk, megtehetjük azt, hogy HTTP portokollon keresztül fogadjuk a kérést és egy standard HTTP redirect segítségével (amit az IIS-ben könnyen beállíthatunk) átirányítjuk a bejövo kérést egy általunk meghatározott HTTPS elérési útvonalra, aminek a neve fix és nem változik. Így megússzuk azt, hogy a tanúsítványt minden alkalommal újra igényeljük és terítsük. Nézzünk egy példát, hogy miként muködik ez:

• Van egy tanúsítványunk amiben szerepel az autodiscover.fabrikam.hu DNS név. A tuzfalunkat beállítottuk és a bejövo HTTPS forgalmat továbbítjuk a CAS kiszolgálónak.
• Új megbízásunk az, hogy a contoso.hu tartományhoz tartozóan is be kell állítanunk és elérhetové kell tennünk az Autodiscover szolgáltatást. Választhatnánk azt, hogy új tanúsítványt igénylünk amibe az autodiscover.contoso.hu is bekerül, de lássuk be ez nem életszeru.
• Felvesszük hát a DNS-be az autodiscover.contoso.hu A rekordot. A tuzfalat beállítjuk úgy, hogy HTTP protokollon keresztül egy IIS-hez irányítjuk ahol beállítjuk, hogy irányítsa át a kérést a https://autodiscover.fabrikam.hu/autodiscover/autodiscover.xml elérési útra

Az átirányítást természeténél fogva ha a tuzfalunk képes rá, elvégezheti. A megoldás szép és jól is muködik. Azonban mint mindennek, ennek is ára van. Az átirányítást az Outlook alapértelmezésben (secure by default) jelzi a felhasználónak és rábízza a döntést, hogy azt elfogadja vagy sem. Ez lehet zavaró bizonyos esetekben, ezért lehetoséget adunk ennek a beállításnak a módosítására kliens oldalon. Errol bovebb információt a következo cikk tartalmaz: https://support.microsoft.com/kb/956528/

Legvégül ha a HTTP protokoll alapú átirányítós módszer sem hoz eredményt, akkor az Outlook megpróbálkozik az SRV rekord lekérdezésével. Az SRV rekord alapú lekérdezési módszer sikeréhez minimum két elofeltétel szükséges:

• • Outlook 2007 + 2007-ben megjelent Rollup csomag vagy újabb verzió szükséges
  • Fel kell vennünk az SRV rekordot a DNS zóna alá
    • Az SRV rekord egy olyan speciális DNS rekord, ami egy szolgáltatást jelöl és a CNAME-hez hasonlóan muködik, vagyis a DATA nem egy IP cím, hanem egy másik A rekord. Lássuk be, hogy az elozo példánál maradva, lényegesen egyszerubb ennek az implementációja, mint a komplikált redirect típusú kialakításé

Az SRV rekordot a következo adatokkal kell felvenni:

• • Service: _autodiscover
  • Protokoll: _tcp
  • Port number: 443
  • Host: <ahova szeretnénk hogy mutasson>

A következo ábrán látható konfigurációban a contoso.hu DNS tartományban az SRV rekord a mail.contoso.hu-ra mutat.

Vagyis ha az SRV rekord alapján találja meg az Outlook kliens az Autodiscover végpontot, akkor ennél a példánál maradva legvégül a https://mail.contoso.hu/autodiscover/autodiscover.xml elérési úthoz fog csatlakozni.

Utószó

Ezzel eljutottunk arra a pontra ami már elég háttér információ ahhoz, hogy fejben a komplikáltabb helyzeteket összerakjuk magunk is. A zárszóként néhány apróságot még szeretnénk megjegyezni, felsorolás jelleggel:

• Ha egyik lehetoség sem alkalmas az Outlook kliensek megfelelo konfigurálására, akkor lehetoségünk van arra, hogy Local XML fájlon keresztül menjen az Autodiscover. Erre általában nincs szükség, tehát alaposan gondoljuk végig, hogy valójában kell-e ez a módszer nekünk. Ennek részleteit itt dokumentáltuk: https://technet.microsoft.com/en-us/library/cc511507.aspx
• Mint mindent, próbáljuk az Autodiscover kialakítást is a leheto legegyszerubben megoldani. A leginkább kézenfekvo és egyszeru megoldás az, ha az Internet irányából az SRV rekord alapú kialakítást választjuk. Ennek elofeltétele, hogy a DNS szolgáltatónk képes legyen SRV rekordot felvenni. Ha ez 2011-ben probléma és nem lehetséges, akkor váltsunk DNS szolgáltatót vagy DNS szervert.
• A konfigurálás elott szenteljünk idot annak, hogy alaposan végig gondoljuk a környezetünket és megtervezzük a kialakítandó rendszert. Lássunk tisztán mielott bármilyen konfiguráláshoz hozzáfogunk.
• A témában egy kiváló WhitePaper már született, amit érdemes átolvasni akkor ha a fentieket megfeleloen értjük: White Paper: Exchange 2007 Autodiscover Service