Exchange 2016 telepítése AD helyett OpenLDAP-pal

Fórumok

Hello. Nemrég kaptam egy nagyon egzotikus feladatot, amiben egy már meglévő Exchange 2016 os rendszert szeretnének átemelni AD környezetből OpenLDAP ba biztonsági problémák miatt. Az egyik kollégám szerint megvalósítható a dolog, mert már csinált ilyet. Nekem viszont lövésem sincs, hogy ez mekkora szívás sorozatot vonzana magával, ha nem a saját vérével keresztezzük működés közben, ami előbb vagy utóbb úgy is bekövetkezik szokásosan. Konkrétan a googlet turkálom már egy ideje, használható leírások után, viszont nagyából egy darab értelmes sincs. Van ehhez valakinek valami használható anyaga esetleg? Mekkora szívás van a jövőben a frissítésekkel pl. cu, amikor varázsol az ad ban? Egyáltalán kivitelezhető ez a felállás? Köszönöm a tapasztalatokat, hátha más fejében is megfordul a jövőben ez a kérdés. 

Hozzászólások

Szerkesztve: 2021. 06. 16., sze – 19:37

Kérd meg a kollégád, hogy mutasson egyetlen Microsoft által kiadott dokumentumot, amelyben le van írva, hogy az Exchange 2016 támogat más címtárat a Microsoft Active Directory-n kívül.

Az Exchange Server 2016 rendszerkövetelményeit itt találod:

https://docs.microsoft.com/en-us/exchange/plan-and-deploy/system-requir…

Nem elég, hogy MS Active Directory kell, még a Forest Function Level sem mindegy:

The Active Directory forest functional level is Windows Server 2008 R2 or higher.

Elképzelhető, hogy fel lehet hákolni OpenLDAP-ra, de erősen kétlem, hogy utána a Microsoft support szóba fog állni veled. Ha pedig nem fog, akkor ilyen öntökönlövést nem tudom miért követne el az, akinek az állása függ mondjuk egy ilyen szervertől.

Őszintén: mit spórol meg vele? Mitől lesz ez nagyobb biztonságú?

trey @ gépház

Erre szerintem a kamikaze-k is csettintenének.

what ?

temelni AD környezetből OpenLDAP ba biztonsági problémák miatt. Az egyik kollégám szerint megvalósítható a dolog, mert már csinált ilyet.

what x2 ???

Szerkesztve: 2021. 06. 16., sze – 20:48

Esetleg vegyetek "HCL DOMINO"-t leánykori nevén "IBM DOMINO", ehhez nem kell AD viszont visszamentek az időben kb. 30évet :D

Hát na. Azért ez elég baszó egy ötlet.

Nem nem nem nem és nem.

Lehet openldap mapi és Outlook kompatibilis megoldással vagy lehet ms ad exchangel. Az Exchange ad integraltasaga olyan komoly szintű, hogy az upgrade még a laborban is lángoló mélytorok lehet, főleg, ha abban az ad-ban már korábban telepítettek ide oda pár Exchange verziót.

Vagy minden free és pl használtok egy zentyalt vagy ucs szervert, vagy menjetek o365-be. Onprem Exchange gyorsabb és jobb lehet, mint a felhős, de sokkal több gond vele és nem is olcsóbb.

A biztonsági kérdések meg akkor jönnek leginkább elő, hogy ha valaki előáll egy ilyen ötlettel, annak testőrök kellenek de nagyon gyorsan, vagy gyorsabbnak kell lennie nálam. 

Egy helyen addig sirtak a userek, hogy vadi uj Exchange es MS kornyezett lett telepitve. Ekkor kellett elkezdenem nezegetni ezeket a dolgokat... :-( A telepitest egy profi MS csapat megoldotta, de amikor megutdtak, hogy samba4 az AD-nk akkor azonnal jott, elokerult, hogy MS AD-ba kell atkoltoztetni a usereket. Konkretan felallt a szor a pasi hatan, meg a poloja is megemelkedett. Foleg azert, mert mar volt benne egy schema kiterjesztes... Kesobb megneztem egy-ket Exchange telepitesrol szolo oktatast... Haaat... Lenne egy nyomdafesteket nem turo hasonlatom, hogy belenyul az MS AD torkaba az Exchange telepito, es nem mondom meddig tur le...

Nem. Nemö! Kizart dolognak tartom, hogy az Eschange oszzeparosithato Samba4 AD-vel, vagy OpenLDAP-al. Ugy biztosan nem hogy utana az Exchange manager felulete mukodjon.

Egyebkent igy on-premise teleppitve egy fos. Allandoan van valami nyugje a cuccnak. Ha mar egy messzirol is jol lathato nagy kazal penzt kifizet erte az ember, valahogy tobbet varnek.

Gondolom, majd a nalam jobban ertok megszakertik, de nekem a Kopano teljesen jo alternativanak tunt. Eles rendszerem nincs csak "jatsszottam" vele.

Egyebkent, ha MS akkor sajnos nagyon kemenyen terel a ceg az O365 fele. Roviden es tomoren szivas az on-premise.

Exchange 2016 óta nyílt titok, h. a msft-nak NEM célja az SMB területtel foglalkozás. Olyan gépigénye van egy 10-20 mailboxos exchg2016 szervernek, h. leülsz tőle. Pont azért, h. bizonyos felhasználószám alatt ne érje meg. Amelyik cég van eleg nagy, és elég elszánt h. neki saját levelezés kell, az az exchange 2016-al is megbírkózik. Mindenki másnak marad az exchange online ha msft-os levelezést akar outlook-al és a többi jól megszokott fícsörrel.

Aki ilyen ötlettel áll elő, arra egy, az elmúlt évben mémesedett mondat illik: "Hátra vinni, leköhögni!"

Esetleg Exchange helyett bármi, ami picit kompatibilis? Zentyal-ban és NethServer-ben van ilyesmi, de még ha plugin is kell hozzá, ha működne, kit érdekel, mi van mögötte. Tudom, copásfaktor így is, de legalább a levelezés működik, a naptárat és névjegyzéket kell gyúrni.

Ez nem jarhato ut. Amit megcsinalhatsz hogy az AD-t szonkorinzalod egy ldap-ba, de az tuti nem az openladp. Az olyan messze van egy igazi cimtartol, mint maga az AD. :D

A netscape DS leszarmazottaknak, mint pl. a 389ds-nek van sync pluginja. De ez sem arra valo amire neked kell, mert annak nincs ertelme egyszeruen. 

nem azt mondtam hogy van ertelme, hanem hogy meg lehet csinalni :D

amugy meg szamos esetben nagyobb cegeknel ha nem csak exchange van hanem mas rendszerek, amiket nem kotnek direktbe be az AD-be, hanem egy masik DS-be es onnan szinkronizalt credential-okat hasznalnak, akkor van letjogosultsaga. Mivel mondjuk nem kellenek az AD feature-ok meg, vagy specialis scheme-kat hasznalnak, meg az AD kb. cimtarnak egy jo nagy szar. :D

Ahol az AD - másik DS szinkron izél, ott a sz0pás garantált... Egyirányú szinkron (azaz replika) esetén a forrás oldali változás mikor és hogy megy át a másik oldalra, kétirányú szinkron esetén meg a mindkét oldalon változik valami, mi legyen kérdéskör a khm. kifejezetten érdekes... Vagy megoldod, hogy az egyik oldali módosítási igény az adott entitást a másik oldalon is "lockolja" a módosítás és szinkronizálás idejére (sok szerencsét hozzá!) Anno IPA-val lett volna egy replikáljunk AD-s usereket dolog - aztán a vége az lett, hogy trust, és az userek maradtak csak az AD-ben...

Namármost...

Nem használtam kevert (AD+OpenLDAP) rendszereket...

Viszont AD-ban minden jobb helyen minimum 2 AD kontroller van... Ezek általában master-master módban mennek, azaz bárhol módosítasz, azt replikálják...

És valahol az AD a leges-leges-leges-leges-legmélyebben egy LDAP alapú rendszer...

OpenLDAP alatt már dolgoztam multi-master felállásban és azok is oda-vissza szinkronizáltak. Persze kitétel volt, hogy az órák megfelelően járjanak...

Szóval szerintem lehetségesnek kellene lennie (mondom, nem csináltam még), hogy AD-OpenLDAP "master-master" rendszerben működjön...

De persze nem bíznám rá az életem :) :) :)

Debian Linux rulez... :D
RIP Ian Murdock

Hát az Exchange telepítés minden esetben egy Schema upgrade-del, már az is kérdés hogy hogyan ugrod meg...

Gondolom az a terv, hogy felhúz egy teszt AD-t, azzal összerakja, aztán az AD-t lecseréli egy openldap/389ds/akármire, az AD-ból áthúzva mindent, amire szerinte szükség lehet... Aztán folyamatos közelítéssel reményei szerint eljut a "nagyjából működik" állapotig. Csak frissíteni ne kelljen ugye...

Amúgy az ilyenekre régen lelkes egyetemistákat fogtak be, akiknek végtelen szabadidejűk, és még nem befásult begyepesedett világnézetük volt ("eztnemlehetmegcsinálni"), valamint lelkesek. Ha meg tudta csinálni, akkor ott a bizonyíték h. nem lehetetlen. Ha meg nem tudta megcsinálni, akkor lám ez tényleg nem fog működni.

Az a kár, h. ma már a lelkes egyetemistákat is úgy kell lasszóval fogni, mert a bme-s tanárok meghülyítik őket már az 1. szemeszterben, h.: "kollégák maguk nettó millió ft felett fognak keresni amint átveszik a diplomájukat és másnap munkába állnak"

[..]mert a bme-s tanárok meghülyítik őket már az 1. szemeszterben, h.: "kollégák maguk nettó millió ft felett fognak keresni amint átveszik a diplomájukat és másnap munkába állnak"[..]

Na álljon meg a gyászmenet.

  • nem az első szemeszterben hülyítik meg az egyetemistákat, hanem még a felvételi előtt a mindenféle kretén ígéretekkel.. tudod napi 8óra fb nézegetés és netto millios kezdő fizu 0 tudásra :)
  • az átlag egyetemi oktató saját maga is iszonyatosan alul van fizetve (főleg ahhoz képest, hogy hány balfasz bürokratát tart még el), hozza kepest egy sima multinal egy kezdo fizu sem olyan rossz.. .. sokaknak emiatt legalább 2 állása van.

ilyen jellegű szarpofozáshoz nem kell lelkes egyetemista. lelekes bárki kell hozzá akinek vannak bármiféle alap fogalmai. a lelkesedés pont hogy kiveszik az egyetem alatt a hallgatókból. már amelyikben volt bármiféle érdeklődés a szakma iránt túl azon, hogy "ebből majd jól fog élni".

begyepesedett világnézetük volt ("eztnemlehetmegcsinálni")

vs.

Ezt nem eri meg megcsinalni, mert csak a szenvedes lesz vele. En is eljutottam arra a szintre, hogy ha lehet, akkor probalok nem visszafele haladni a rendszerekkel, ha nem muszaj, francnak sincs kedve atallas utan a munkadieje felet minden nap debugolassal, meg az adott rendszer simogatasaval tolteni, hatha majd 1-2 ev/honap mulva stabil lesz.

on-prem Exchange uzemeltetes eleve egy szep nagy falat, AD-val karoltve, nem kell meg pluszban hozza egy total experimental unsupported feature, ami persze menjen minel hamarabb productionbe, es nem allhat le.

+1

a főnim már rájött, hogy a meg tudod-e/tudjuk e csinálni helyett a van e értelme kérdéssel kell kezdeni.

A témaindító kérdés kicsit átfogalmazva: “Lábon tudod-e magad lőni egy 9mm-essel? A kollégám már csinálta”

A válasz pedig az, hogy “Hogy a pics@ba ne tudnám, de miért nem ő csinálja megint?”

Szerintem tuti nem OpenLDAP-al oldotta meg, mivel az csak egy sima LDAP, nem tudja helyettesíteni az AD-t, ami alapfeltétele az exchange telepítésének.

Egy Samba 4+al felhúzott AD-val már lehet próbálkozni, avval van némi remény.

Egy Samba 4+al felhúzott AD-val már lehet próbálkozni, avval van némi remény.

Nope, talán Exchange 2007-et még meg lehetett taknyolni rá, az utána levő verziók már Samba-inkompatibilis schema change-ket akarnak.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Ez csak related:

Biztos bennem van a hiba, de én LDAP értelmét soha az életben meg nem értettem, az LDIF egy elcseszett, semmivel nem kompatibilis formátum, de a leggázabb dolog amibe belefutottam, hogy ha LDAP auth-ot szeretnék, akkor LDAP admin password kellene minden kliensre? Ezeknek elment az eszük, vagy én "tartom rosszul"?

Külön tetszik, amikor arról papol (pl. az OpenLDAP dokumentáció), hogy ezen adatok tárolására mennyire alkalmatlan egy mezei adatbázis motor.

Hogy terjedhetett el ennyire ez a hulladék?

Biztos bennem van a hiba, de én LDAP értelmét soha az életben meg nem értettem, az LDIF egy elcseszett, semmivel nem kompatibilis formátum, de a leggázabb dolog amibe belefutottam, hogy ha LDAP auth-ot szeretnék, akkor LDAP admin password kellene minden kliensre? Ezeknek elment az eszük, vagy én "tartom rosszul"?

Te "tartod rosszul"... :)

Annyira nem hulladék, mint amilyennek gondolod. Én nagyon elmés és jó megoldásnak találom... De lehet hogy ezt meg én "tarom rosszul"... :)

Debian Linux rulez... :D
RIP Ian Murdock

LDAP admin password kellene minden kliensre?

Nope... általában két eset van: az LDAP szerverre bízod az authentikációt, ekkor odaadsz neki egy usernevet és jelszót, amit a felhasználótól kaptál; cserébe implementáció-függő, hogy mit fogad el (AD pl. simán a sAMAccountName-t is, de van olyan LDAP szerver, ami csak a teljes DN-t); a másik, hogy az azonosítást végző programod belép az LDAP szerverre a saját credjével, megkérdezi, hogy adott tulajdonságú usernek (pl. felhasználói név) mi a DN-je, lekapcsolódik, majd azt a DN-t használva felhasználói névnek és a usertől kapott jelszót használva megpróbál bejelentkezni (előbbi szvsz. szerencsésebb, de kétesélyes, hogy mi támogatja és mi nem és milyen formájú usernevekkel).

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Miután így vagy úgy autholt (akár teljes DN-nel, akár előtte másik accal megkeresve a DN-t) már tud jelszót változtatni (de ez szintén implementáció-függő, AD-nál pl. az egyik write-only attribútumot kell felülcsapnod idézőjelek közé tett - fejből - UTF-16 LE kódolású stringgel, openLDAP passz...)

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

akkor egy kis basic. egy cimtarban vannak objektumok amiknek vannak attributumaik. egy cimtarban attributum szinten meg tudod mondani kinek milyen hozzaferese van hozza (acl), pl a 'password' mezohoz csak a self-nek van read/write joga (meg meg sok, ahhoz kepest hogy mas DB szeru izek mivel randelkeznek). Igy csakis a user latja es csakis o tudja modositani.

access to attrs=userPassword
        by self =xw
        by anonymous auth
        by * none

Azt hogy mindenhova kellene admin DN nem is ertem....

Ez így szimpi, és nekem is így lenne logikus. Egy percig sem zártam ki, hogy én vagyok a hülye, csak sajnos normális leírást is vadászni kell.

Én az ilyenektől ijedtem meg:

 AuthLDAPBindDN "cn=Manager,dc=domain,dc=com"
 AuthLDAPBindPassword "your_secret_secret_password_to_ldap_admin"

Itt: https://www.howtoforge.com/linux_ldap_authentication

Illetve mint írtam, a debian is valamiért kéri a kliens konfig során az admin accountot, amit aztán le is tárol az /etc/pam_ldap.secret-ben.

hat ize...az openldap jatek cimtar maximum :D

az ember elkezd dolgozni a 389ds-el vagy barmelyik az openldap-nal 20 evvel idosebb NetScape DS leszarmazottal es rajon. :D

De amugy az openldap-ban is lehet masik usernek jogot adni hogy olvassa a tobbi user attributumat. Bar azert en szemely szerint joban szeretem azokat a termekeket, amiknek nem kell eloszor admin-nal bindolni, hogy aztan a user is tudjun authenticalni. Ez nekem kicsit eros. De en is talalkoztam mar ilyennel. Ezek a progik azt csinaljak, hogy megcsinaljak eloszor az admin auth-ot, hogy meg tudjak keresni a user-t es a passwordot es majd ok eldontik hogy ez egyezik e. De minek, ha ezt ra tudjak bizni az LDAP-ra is. Amugy ez fuggetlen milyen ldap-ot hasznalsz 389ds, openldp, akarmi. Itt a programokkal van bibi. 

LDAp admin auth-ra egy programnak akkor legyen szuksege, ha az manageli az LDAP-ot es ezert irnia kell bele. Amugy johet egy technikai user, ami csak olvasasi joggal bir a megfelelo attributumokon es kesz.

Azért a 389ds-sel láttam olyan aktív/passzív párost, ahol ha szétesett a szinkron (és időnként szétesett...), akkor a szállító munkatársai support keretben rázták gatyába az egészet - addig viszont se user módosítás, se jelszócsere, semmi nem lehetett... lett is helyette IPA (két node-dal), aktív/aktív felállásban - annak kellett picike hangolás, utána ment, mint a Doxa...

hat akkor ott a szallito volt a hibas. Olyan 2006-2007 tajekan atomstabilan ment mar oracleDs-el (szinten Netscape ds), de asszem 389ds-el is, bar akkor meg lehet Netscape ds volt a neve). Mar nem emlekszem mikor csinaltam meg az egyik legnagyobb mobilszolgaltatonal 389ds-el, de valamikor 2008 kornyeken.

az az LDAP admin resz egy eleg elcseszett dokumentacios "eliras", es eleg sok helyen ezt vettek siman at.
Ez hasonlo, mint amikor ugyfelnel rakerdeztunk, hogy Oracle db-hez kaphatunk-e extra jogosultsagokat, es mondtak, hogy persze, csak ne DBAdmin-t kerjunk. Mert ugye ott is az a legegyszerubb, hogy DBAdmin, es akkor nincs semmilyen jogosultsagi problema.
Valamint ugyanez webszerverek altal kiszolgalt oldalakkal:

chmod -R 777 .

Igy tuti nem lesz access denied problema.

Ami még eszembe jutott a témáról:

Kellene ez még a hátra púpnak, mert nincs egyébként elég szopás a támogatott Exchange telepítésekkel ...

trey @ gépház

Na ettol az FBI-os huzastol rendesen hanytam en is!!

Visszakanyarodva az eredeti temahoz/problemahoz. Nem tudom, szigoru feltetel-e az OpenLDAP. Nalam tobb helyen is megy sima samba4 AD (debian csomagbol) Parban vannak, lehet athentikalni. Nem heggesztettem tovabb, hogy BIND-et integraljak vagy OpenLDAP backend... Lan-on belul egy kis ketchuppal elmegy Samba4 alatt minden. Mukodik, akkor minek bonyolitsam? Windows-ok beleptetve a domainbe. Ezekrol a gepekrol siman lehet jelszot cserelni a windows-on modon. Akiknek nincs domain-es gepuk, ok kapnak egy web feluletet a jelszo csere: https://ltb-project.org/start Sikerult illeszteni. Ennek web feluletet ugy veded meg akar rev proxyval, fail2ban-al ahogy csak akarod.

Az Exchange 2016 domain level minimum kovetelmenye 2008R2. Ezt meg eppen megugorja a Samba 4. Mint mondtam Exchange 2019 telepiteset lattam. Amit ott ossze koburalt a telepito, azt a Samba 4 tuti nem viseli el. Schema kiterjesztesek specialis userek...

Alternativanak neztem a Kopanot. Az biztos, hogy Samba4-bol popec ment az authentikacio, csoportok kezelese. A Samba4-ben a Kopano Schema modositasa siman felment. Outlook kapcsolodott, naptarak, levelek, kozos mappak, jottek mentek. Sajnos nem vittem tovabb a projektet, mert nem volt ra igeny, igy a hasznalatbol eredo esetleges buktatokrol nem tudok beszamolni. De Exchange alternativanak szamomra igeretesnek tunt. Az ltb-projekt oldalat be lehetett integralni a Kopano feluletebe. Helybol ment a jelszo csere.

"Na ettol az FBI-os huzastol rendesen hanytam en is!!"

Miért? A Windows se a tied, az Exchange sem, elvégre vagy frissítesz vagy frissítesz. És mint tudjuk az Update egy külföldi szó, ami Magyarul azt jelenti, hogy: "Ismert hibák lecserélése ismeretlenekre.". Szóval az, hogy most nem a Redmontban nyomták meg a gombot hanem Washingtonban, szerintem részletkérdés.

Jó, persze jogilag támadható, de az erősebb fél (MS, FBI, NER) többnyire nem fél a jogi procedúráktól, sőt, szereti, csak annyi a tiszteletteljes kérésük, hogy a feljelentést puha papírra nyomtatva tessék leadni a gazdasági igazgatóság készletraktárában.

Ez az Exchange cluster hány postfiókot szolgál ki?

Ha mégis nekiálltok, mindenképpen blogolj róla plz. Vagy tanulunk belőle valamit, vagy jó lesz elrettentő példának. :)

Az egyik kollégám szerint megvalósítható a dolog, mert már csinált ilyet

Van ezekre egy nagyon jó kezelési módszer: meg kell kérni a kedves kollégát, hogy akkor mutassa már meg, mert tanulni szeretnél tőle.