Fórumok
Sziasztok!
Több ügyfelünk használ multifunkciós nyomtatóin O365 fiókot szkennelés email-be funkcióhoz. A napokban problémát jelentettek több helyről is. Az smtp kommunikáció hibára fut náluk. A gép beállításokon nem módosított senki. Kipróbáltuk az smtp-legacy.office365.com host-on keresztül, néhány óráig jó volt. Most már ismét nem működik. Hallottatok ilyen eseményről? Azt tudom, hogy az említett hitelesítési metódust szeptembertől kivezeti a Microsoft. Azt nem tudom, hogy az Entra-ban létrehozható Application password-öt érinti-e ez az intézkedés.
Hozzászólások
Detto nálunk is tegnap jelentkezett először akkor átírtuk a legacy-ra aztán jó lett. Ma ismét jelentkezett ez a probléma. (Konica bizhub)
Xerox ugyanez :)
Az smtp-legacy az nem a hitelesítés miatt legacy, hanem a TLS 1.0 és 1.1 támogatás miatt (amiben szintén szenved egy csomó MFP, nevezetesen, hogy nem tudnak TLS 1.2 és 1.3 verziókat). Ráadásul ennek használatát is engedélyezni kell tenant szinten az Exchange Online felületén vagy PS-ből.
Szerintem a kötelező 2FA miatt múlt el a küldés, amit hullámokban aktivál az MS vagy 2 éve folyamatosan. Elvileg application password-del megoldható még, 2FA bekapcsolása után (addig meg sem jelenik az app password generálási lehetőség), de csak akkor, ha a fiókon engedélyezve van az SMTP AUTH használata.
Az egyetlen tuti működő megoldás, ha csak tartományon belülre küld az MFP, mert akkor a cegnev.protection.outlook.com tcp/25-ön hitelesítés nélkül is lehet küldeni levelet (nyilván ezért kikötés ehhez a módszerhez, hogy csak tartományon belüli címre küldhet).
Nekem itthon olyan gép lett képtelen kívülre küldeni, amit 4 éve gyártottak :/
Vortex Rikers NC114-85EKLS
Akkor az egyértelműen 2FA-s dolog, nem TLS-es hiány.
Az említett MFP-k tudják a TLS1.2-t is. Azzal sem megy. A működő megoldásnál a connector-ra gondolsz? Mert az meg IP-hez van rendelve. Azzal hibátlanul működik, de nem minden partner rendelkezik fix IP-vel.
Igen, arra gondoltam. Sajnos vannak az M365-ben olyan elvárások, amiket a tenant meg kell, hogy ugorjon. Ráadásul ezek köre szépen bővül, ahogy sikerül egyre többeket behúzni a szolgáltatásban (a nem-M365 levelezés rendszeres szabotálásával pl.). Ilyen elvárás a fix IP bizonyos dolgokhoz.
Mi úgy oldjuk ezt meg, hogy az adott ügyfélnek csinálunk egy al-tartományt, a saját hosting szolgáltatásunkban teszünk rá levelezést és azon keresztül küldenek az olyan végpontok, amik az M365 jelenlegi feltételeinek nem felelnek meg. Pl. nincs fix IP, pl. tartományon kívülre is akar küldeni de nem tud OAuth2-t, pl. nem támogat TLS1.2-t, stb.
Bevallom, engem bosszant, hogy egyre több dologról kell lemondani vagy pénzköltéssel "feljavítani", hogy működjön az egyébként nem kifejezetten olcsó M365-tel. Abba pedig nagyon sok KKV csak a levelezés miatt megy be (a többi szolgáltatásról sokszor nem is tudnak, sokan később sem veszik azokat igénybe), mert rendszeresen belefutnak abba, hogy az aktuális e-mail hosting-tól az M365-ben lévő címzettjük nem kapja meg a levelet (az MS által elkövetett nem véletlen, rendszeres szabotázsok miatt). Aztán mikor trükkökkel beszippantják az ügyfelet, akkor lehet ráerőltetni újabbnál újabb hülyeségeket a biztonságra hivatkozva.
Mondjuk engem érdekelne, hogy miért nem biztonságos egy random 32 karakteres lejszó egy titkosított TLS csatornán átküldve... De ugyan ez a user a böngészőjébe elmentett sütivel mindenféle hitelesítés nélkül szerencsétlenkedhet az M365-ben akár hetekig újrahitelesítés nélkül. Ahogyan az előző (költői) kérdésemnél is, hogy ugyan ez a hitelesítési módszer miért lesz mégis megfelelő, ha egy másik, külön fizetős szolgáltatásban veszi igénybe ugyan ez az ügyfél, ugyan azon a rendszeren...
Teljesen egyetértek. Sajnos én is ezt látom.
https://techcommunity.microsoft.com/blog/exchange/exchange-online-to-re…
mikrofoséknál mostanában az a divat, hogy a megszűnésre ítélt szolgáltatásokat random rövid időre kikapcsolják, csak, hogy vedd az üzenetet, igen az app passwordos metódust érinti.
Ez valóban így szokott történni MS termékeknél és szolgáltatásoknál.
Azt viszont nem igazán értem, hogy mi értelme az egyik szolgáltatásban letiltani a basic auth-ot, ha másik kettőben elérhető marad és kb. azonos credential-lal lehet majd használni. Akkor végül is nem az adatok védelme okán lesz a tiltás...
Persze, hogy nem adatvédelem az ok, ők is tudják, hogy UPSek meg egy csomó kütyü pl nyomtató nem tud oAutholni, de a céges IT sarokkövei, csak már ebből is lehet pénzt csinálni.
Rájöttek, hogy hogyan lehet pénzt kérni a basic auth SMTPért: ott van a “high volume email” ami ingyenes a preview alatt, ami meglepő módon pont akkor ér véget mikor a basic auth ki lesz kapcsolva, de majd jó drágán abban is lehet küldni.
Vagy ott van az Azure communication services amiben nem csak darabszám de megabájt alapján is ki fogod fizetni a basic auth SMTPs emaileket.
Ez azért őszintén elég paraszt hozzáállás. Itt most tényleg az egyéb "kiegészítő" eszközök is el fognak hasalni. Pl. a riasztórendszerek sem tudnak OAUTH-ot. Nyilván az azt üzemeltető más protokollon, más csatornán csatornán csatlakozik de sok helyen (nálunk is) az is fontos, hogy email formában követhető legyenek az események.
Nem ez az egyetlen hasonló húzásuk, úgyhogy én már meg se tudok lepődni.
Megelőztél, ezt akartam bemásolni.
Mi most állítjuk át globálisan a nyomtatókat, úgyhogy épp bele futottam ebbe.
Mikor éppen nem megy akkor a connect-exchangeonline is megdöglik nálatok is?
Itt mire gondolsz?
Mikor épp nem megy az smtp.office365.com-on a basic authos smtp akkor valamiért az exchange online powershell is le van pusztulva és az istennek se akar csatlakozni, amint meggyógyul az smtp akkor az exchange PS is csatlakozik, lehet véletlen de gyanús.
Ezt nem próbáltam. De a basic auth-ra ott is írnak ilyen problémákat.
Házon belül kell egy relay szerver, az átveszi ezekről IP cím alapján auth nélkül, aztán a relay tovább tolja az M365 felé. #worksforme
trey @ gépház
Pontosan. Egyszerű, van queue (ha megfelelő szoftvert választasz), van log, offline (internetelérés nélkül) is működik.
Nekünk van én megoldom, de az ügyfélnél sok helyen nincs rá lehetőség (szakértelem). Mi a gépet üzemeltetjük, nem nyúlunk az IT dolgaiba (bár jobb lenne néha). Gondoltam, hogy csinálunk egy multi-tenant proxy-t app service-ben, de nem akarom más nyűgjét a nyakamba venni. Mint mondottam ez a probléma nem a mi problémánk, hanem biztonságtechnikai cégeké, egyéb (nem IT) üzemeltetőké is.
Off: Már bocs, de ha egy biztonságtechnikai cég nem tud megugorni egy IT biztonsági intézkedést, akkor _lehet_ hogy helyes, hogy sérülés éri az üzletét. Most ez attól teljesen független, hogy az MS hozzáállásával amúgy én sem értek egyet. Ma már szinte nincs is olyan, hogy az IT-nek nincs kihatása egy területre, de a biztonságtechnika különösen ilyen tud lenni.
On: Ami a konkrét fenti hibát illeti, én kerülnék egyet, és javasolnám a cégeknek az Amazon SES-t. Fillérekbe kerül meglepően nagy mennyiségű levélforgalom is, és a SES korrektül kezel minden DKIM-mel kapcsolatos dolgot. Ha a domaint átmigrálják Route 53-ba (szintén fillérek), akkor még a DNS beállításokkal sem kell szopni, mert a DKIM-et a SES automatikusan bemigrálja a Route 53-as domainbe, az egyetlen, amit karban kell majd tartani az az SPF rekord (mert ha nem AWS-es levelezők, azt nyilván nem tudja megugorni az AWS). Tiszta, egyszerű, meglepően sok mindent támogat.
Blog | @hron84
via @snq-
Rengeteg dedikált SMTP szolgáltatás érhető el. Az ingyeneseket figyelmen kívül hagyva (ha nem napi "1000" levelet küldesz, akkor a nem ingyenes is lehet az), havi 4000-10000 Ft között már bőven lehet válogatni. Annak a beállítása már nem hiszem, hogy bárkinek problémát okozna.
Ebből lehet pénzt keresni. Vagyis, pénzért megoldani.
trey @ gépház