Microsoft brengt Defender for Business uit voor bestaande Business-klanten

Microsoft heeft zijn beveiligingspakket Defender for Business uitgebracht voor bestaande Microsoft 365 Business Premium-klanten. Dat endpointpakket voor kleine bedrijven was er al als preview, maar is nu algemeen beschikbaar.

Klanten met een Microsoft 365 Business Premium-abonnement krijgen Defender for Business automatisch te zien in hun Endpoint-securityportal, schrijft Microsoft. Daarvoor hoeven gebruikers geen extra configuraties door te voeren. Ook nieuwe klanten van 365 Business Premium kunnen per direct van de functie gebruikmaken. Defender for Business vervangt Defender for Endpoint P1 automatisch als gebruikers daar al een licentie voor hebben. Defender for Endpoint P2 blijft wel bestaan zolang de licentie van een gebruiker doorloopt.

Microsoft bracht het beveiligingspakket Defender for Business eind vorig jaar al uit als losstaande bètaversie. Het is een goedkopere versie van Defender for Endpoint en is bedoeld voor het midden- en kleinbedrijf, met name bedrijven met maximaal 300 werknemers. Het bedrijf bracht het pakket naar eigen zeggen uit omdat het zag dat voornamelijk deze kleine bedrijven werden getroffen door cyberaanvallen, maar een beveiligingspakket vaak te duur vonden.

De stabiele versie van Defender for Endpoint is voorlopig alleen te gebruiken voor de Defender for Business-klanten. Microsoft test daarnaast nog steeds de bèta van het losstaande pakket. Dat pakket komt 'later dit jaar' beschikbaar, maar is nog wel als preview uit te proberen.

Reacties (73)

[fRiEtJeSaTe]

Hoe verhoudt zich deze oplossing t.o.v. bijv. een ESET Endpoint Protection?
Het klinkt aantrekkelijk om die er dan maar uit te gooien gezien we toch al Business Premium licenties hebben.

[Reactie gewijzigd door fRiEtJeSaTe op 24 juli 2024 11:14]

[Cergorach]

Je zal zelf even moeten kijken welke feature set je gebruikt onder ESET Endpoint Protection en die vergelijken met die van MS Defender for Business.

Realiseer je dat veel Enterpise omgevingen de hele MS Defender stack in gebruik nemen (ipv. third party leveranciers) omdat de hele stack heel mooi integreert. Dit is meer dan alleen AV, het doet een hele sloot aan detectie en preventie, maar dat ligt er een beetje aan of je er ook wat mee doet als beheerder. Je kan bv. heel mooi nagaan in de hele chain van events, op welk device dat phishing mailtje wanneer is geopend, wat ermee is gebeurd, etc.

Waar je dan verder naar kan kijken is iets als Azure Sentinel, maar dat is vaak buiten budget voor de kleine MKB, maar dat waren dit soort producten eigenlijk ook tot voorkort.

[Razwer]

Defender heeft een twijfelachtige reputatie op gebied van beveiliging.
Daarnaast is een signature based AV niet meer van deze tijd. BlackBerry/Cylance, SentinelOne en Crowdstrike lopen mijlen ver vooruit als next-gen AV.

Defender zal elke bake-off verliezen van deze producten. "het integreert makkelijk samen" is een leuk verhaal totdat je een breach hebt, just saying..

[Reactie gewijzigd door Razwer op 24 juli 2024 11:14]

[Zwarte_os]

Bron? Naar mijn weten doet Defender het prima.

[Razwer]

ignorance is bliss?
Als je bewijzen wilt stel ik je voor om de sales afdelingen van de genoemde bedrijven te contacteren en vragen of een sales engineer een bakeoff wil doen met hun product vs defender.
Ik heb veel bakeoffs gezien, ook recent, en Defender verliest altijd.

[sendoake]

Dus je kan geen bron geven. Genoteerd.

[Razwer]

Genoteerd.

oh jee, krijg ik nu straf?
Ik ben een bron en heb de credentials. Helaas mag ik zonder NDA of sales opportunity niets publiek delen. Zoals je op av-test niet kan zien delen de enterprise EPP vendors weinig tot geen data aan particulieren.

[Reactie gewijzigd door Razwer op 24 juli 2024 11:14]

[Pwigle]

Is er iets wat je wel kan en mag delen? Ik ben namelijk (oprecht) erg benieuwd naar verdere onderbouwing.
Misschien goed om te weten, dit artikel gaat over de "MKB variant" van Defender for Endpoint wat een volwaardige EPP/EDR oplossing is. Daarnaast is Defender AV al heel lang geen signature based only AV meer.

[Razwer]

Een bakeoff is meestal EPP product A vs EPP product B op exact dezelfde config machines, detonate X aantal malware/ransomware (crypted files) op beiden machines en pak popcorn.

Afhankelijk van de use case verschillende bepaalde aspecten in de bakeoff, maar dit is meestal wat het is. Defender ATP/for Endpoint trekt vooral offline aan het kortste eind. Offline is Defender nog steeds signature based.

[jotheman]

Je geeft ontzettend af op Defender op allerlei manieren, maar zonder bronnen. Als je Gartner bekijkt staat MS op een leader-positie, qua beoordelingen staan alle producten die jij noemt nog niet eens in de top 3. Tuurlijk kijkt Gartner naar andere zaken, dat snap ik, maar feit is wel dat je gemiddelde Enterprise wel altijd even zal kijken waar een oplossing zich bevindt bij Gartner.
Eens dat Defender for EndPoint een deel van de oplossing is, maar de kracht zit 'm juist in de breedte van het Defender platform, niet alleen endpoint, maar intelligentie en correlatie across the board. Het argument "offline" vind ik niet sterk in deze tijd. We leven in een always online wereld, daar komt juist de kracht van veel van deze platforms vandaan. Producten moeten natuurlijk overeind blijven "on their own" en ik geloof je als je zegt dat het op zichzelf staand wellicht niet het meest krachtige product is tegen concurrenten, maar de kracht zit in de suite en de totaaloplossing.
Zoals anderen ben ik ook (oprecht) geïnteresseerd in bronnen, ben benieuwd naar de achtergrond-info.

[Magyku30]

Defender for Endpoint is niet het Defender zoals we dat kennen van het ingebakken op virusdefinities gebaseerde AV product. Het is een product gebaseerd op het voormalig ATP P1 en ATP P2. Het combineert EDR met Next Gen AV en wordt in de laatste Gartner onderzoeken als het meest vooraanstaande product (meest rechtsboven in het quadrant) gepositioneerd. Het is daarmee een zeer volwassen concurrent van de producten die jij noemt.

[Razwer]

https://docs.microsoft.co...virus?view=o365-worldwide
https://www.microsoft.com/en-us/wdsi/defenderupdates
"Security intelligence updates" zijn nog steeds signatures. Het update commando is dan ook MpCmdRun.exe -SignatureUpdate

En mijn bericht hier onder

Gartner een populariteits wedstrijd en absoluut geen kwaliteits maatstaaf. Ik geef zelf jaarlijks MQ presentaties aan Gartner voor mijn werkgever. Het is schrijnend om te zien hoe de Tweakers MCSE systembeheerdertjes het hier allemaal zoveel beter lijken te weten.

[Magyku30]

Ja natuurlijk gebruikt het nog steeds signature updates. Dat deel is niet weg ofzo. Het gaat vooral om dit deel:
"-Behavior-based, heuristic, and real-time antivirus protection, which includes always-on scanning using file and process behavior monitoring and other heuristics (also known as real-time protection). It also includes detecting and blocking apps that are deemed unsafe, but might not be detected as malware."
"Cloud-delivered protection, which includes near-instant detection and blocking of new and emerging threats."

Next Gen AV producten kunnen detecteren op gedrag en patronen. Daar hebben ze geen siganture updates voor nodig.

[Razwer]

Gartner een populariteits wedstrijd en absoluut geen kwaliteits maatstaaf. Ik geef zelf jaarlijks MQ presentaties aan Gartner voor mijn werkgever. Het is schrijnend om te zien hoe de Tweakers MCSE systembeheerdertjes het hier allemaal zoveel beter lijken te weten.

Offline is zeer zeker wel relevant. Als je je een beetje bezig houd met threathunting zal je zien dat de meeste malware/ransomware de EPP oplossing per direct offline probeert te halen als het deze niet uitgeschakeld krijgt. En ja we leven in een online wereld, maar dat vergroot het risico op exploitation alleen maar. Daarnaast zijn in de meeste enterprise omgevingen nog steeds de servers nog steeds afgesloten (of deels via proxy/SWG) van het internet. Daarnaast zijn veruit de meeste breaches via c2 lateral movement. https://bfy.tw/Sf6R
De trend is juist de attack surfaces te reduceren en juist NIET alle (kwetsbare) resources lekker aan het internet te hangen. Dat is namelijk niet Zero Trust...
Zero Trust is niet alleen een "buzz word" of een product wat je koopt. Als je Gartner en Forester volgt weet je ook dat Zero Trust de filosofie is waar iedereen nu naar toe werkt.

En je wilt bronnen, ik zeg dat ik als professional een bron ben. Stel ik zou als Microsoft MVP een blog hebben neem je me wel voor vol maar een comment op Tweakers is het ineens niet geloofwaardig? Ik mag van mijn werkgever niet online posten over mijn werkzaamheden noch het bedrijf waar ik voor werk. Ik behoud liever mijn baan dan dat ik een internet discussie win. Dus trek verder je conclusies.

Overigens lijkt de moderatie hier op Tweakers ook een populariteitswedstrijd ipv een echte moderatie.

[Reactie gewijzigd door Razwer op 24 juli 2024 11:14]

[bakkerken]

En je wilt bronnen, ik zeg dat ik als professional een bron ben.
source: Dude, trust me.

Waardeloos gewoon als dit je enige staving is.

[Razwer]

Ja is goed met je. Als ik zeg dat Defender ATP bakeoffs verliest van andere producten, moet ik dan volgens jou iedereen die het hier niet mee eens is een demo gaan geven? Of demo video's gaan delen?
Ivm Competitive Intelligence is dat geen goed idee. Dus prima vind wat je vind en denk wat je denkt. Fijne dag betweter.

[bakkerken]

Je geeft een mening zonder dat je enig bewijs aanlevert om ze te staven. Het is gewoon waar omdat jij ervan overtuigd bent? Je hebt er blijkbaar geen idee van hoe ongeloofwaardig je over komt op die manier.

Moeten we dan ook elke facebook post geloven? Misschien is de aarde dan wel echt plat? Want iemand op facebook claimt bij nasa te werken en zij is er sterk van overtuigd.

Lever iets aan om je mening te staven, of aanvaard dat mensen ze afschrijven als waardeloos. Ik ben zeker geen betweter zoals je mij dan wil afschilderen. Beledigen rondgooien is altijd the easy way out en dat doet je zeker geen goed als je een punt wilt maken.

[Razwer]

Kom maar met een EPP sales opportunity en er gaat een wereld voor je open. Er is geen vendor die een andere vendor publiekelijk te kijk zet, dat is not done. Dus ja tot die tijd mag je me ongeloofwaardig vinden, jij je gelijk, ik mijn rust.
En succes met de ransomware aanvallen.

[Cergorach]

Het is lastig dat je endpoint een virus heeft, maar als de rest van de integratie vervolgens wel je endpoint blokkeert doordat activiteit ziet die daar niet hoort. Geen enkele AV kan 100% garanderen dat het beschermt tegen elke infectie, wat belangrijk is dat wanneer je toch geinfecteerd bent, hoe je daar op reageert en hoe snel je daarmee wat kan doen in je endpoint protection.

Voorkomen is beter dan genezen, maar alles op voorkomen gooien zorgt ervoor dat zodra je toch ziek wordt je er helemaal niets meer tegen kan doen. De vraag is namelijk niet of je ziek wordt, maar wanneer je ziek wordt.

[Razwer]

exact en daarom zijn EPP/EDR oplossingen van andere partijen tot nu toe bewezen beter dan Defender.

[Jelmer]

https://www.av-test.org/e.../business-windows-client/
Windows Defender loopt mee met de meute.

Defender for Endpoint voegt juist zaken toe die de producten die je aanhaalt ook doen - meer op gedrag analyzeren.

Cylance legt het overigens behoorlijk af tegen de competitie als je av-test.org mag geloven. Sentinel-one is alleen voor MacOS getest - laatste keer december 2018: https://www.av-test.org/e...manufacturer/sentinelone/), idem voor CrowdStrike (Falcon) - ook alleen voor MacOS en wordt sinds december 2019 niet meer getest (https://www.av-test.org/e...manufacturer/crowdstrike/).

[Razwer]

avtest heeft cylance smart-av getest. Verder hebben ze nooit enterprise versies getest van cylance. av-test is vooral gericht op consumenten oplossingen. Vandaar dat je ook weinig recente tests ziet van de grote enterprise producten.

[Icedustbin2]

Windows Defender is niet hetzelfde als Windows Defender for Endpoint.

Wel degelijk een 'Next-Gen AV' dus. En dus ook zonder de twijfelachtige reputatie. Sla Mitre er maar eens op na, ze doen het echt wel goed.

Wij gaan de overstap maken van SentinelOne / DeepInstinct in ieder geval. Temeer ook vanwege de integratie waar @Cergorach het over heeft.

[Razwer]

Wanneer ik spreek over Defender doel ik idd op Defender ATP of nu Defender for Endpoint.

Mijn advies is, hou een red team van een andere vendor op speed dial mocht je deze toch nodig hebben. Gezien de huidige situatie in de wereld roepen verschillende NCSC's op extra op te letten.
Voorbeeld: https://www.ncsc.gov.uk/n...urged-to-bolster-defences

[AlainG]

Dus jullie stappen af van SentinelOne ? Heb geen ervaring maar heb 2 jaar geleden uitgebreide Demo meegemaakt en leek me wel erg goed. Interessant

[Icedustbin2]

Puur vanwege de integratie met GFI/Solarwinds/N-Able. Die is namelijk ruk, waardoor veel PC's zonder AV zitten en je handwerk moet doen om hun installatiescripts te fixen.

Vandaag echter een 'n klant die niet kan werken (crypto); ondanks een volledig netwerk met SentinelOne.. Ook dat huisje is niet heilig ;-)

[sourcecode]

tja ik denk dat je moet kijken naar features van beide oplossingen

beheers console, botnet protectie, meerlaagse beveiliging etc...

mijn voorkeur gaat uit naar ESET, als je ziet wat er allemaal kan met ESET protect console, heel krachtig.

[Padje]

Nou ESET kan niet eens execuatables blokkeren op reputatie

[Whis!]

Binnen ons bedrijfje hebben we 10 medewerkers met elk een 365 Business Premium licentie. In Windows loggen we echter in op een lokale AD. Om volledig gebruik te kunnen maken van deze optie moeten we dan niet eigenlijk allemaal met onze pc inloggen op de AAD? Of heeft dit alleen betrekking op de online diensten zoals exchange/e-mail, onedrive etc.?

Edit: via je security dashboard kun je een eenvoudige 'onboarding' script downloaden. Deze run je op je endpoint device en deze verschijnt dan netjes in het overzicht in je 365 security dashboard. Lees ook: https://docs.microsoft.co...igure?view=o365-worldwide

[Reactie gewijzigd door Whis! op 24 juli 2024 11:14]

[kroegtijger]

Waarom zou je een business premium nemen als je toch met je lokale accountje inlogt? Dan kan je ook af met een business standard; is een scheutje goedkoper dan. Het grote voordeel van premium zit juist in Endpoint Management en dat kan je niet gebruiken nu... Vrij onzinnige licentie óf vrij onzinnige inrichting dus

[Whis!]

Volgens mij zit er bij de premium advanced threat protection op de e-mails + bijlagen en koppelingen. En e-mailen doen we zeer intensief. Dus vandaar premium!

[kroegtijger]

Zie https://www.microsoft.com...oft-365-business-products

Vermoedelijk doel je op Azure Information Protection Plan 1, waar je nu dus €8,10 per maand per gebruiker voor kwijt bent. Je kan dat ook gewoon als een losse module afnemen, en kost je dan (dacht ik) iets van 1,70 per gebruiker per maand.

Je gebruikt de voornaamste onderdelen die in je licentie zitten nu dus niet, en lijkt mij een vrij kostbare hobby worden op deze manier. Dat kan aanzienlijk goedkoper, of (als de kosten het punt toch niet zijn) gebruiksvriendelijker dan hoe je het nu oplost.

[Whis!]

https://i.imgur.com/ipN2gx8.png

Ik zie vooral waarom je wel 8 euro meer moet betalen per gebruiker per maand als je cruciale zaken via e-mail regelt als commercieel bedrijf.

[kroegtijger]

ATP (advanced thread protection) valt onder AIP (azure information protection). Bij een premium zit plan 1 daarvan inbegrepen, maar diezelfde dienst kan je dus ook los afnemen bij je Standard abonnement. Dat kost je dan dus niet 8 euro per maand meer, maar slechts 1,70 per maand meer. Ik weet niet welke rekenmachine jij gebruikt, maar die van mij geeft toch echt aan dat daar grofweg 6,30 per gebruiker per maand (oftewel bij de 10 gebruikers als voorbeeld 63,- per maand ofwel 756 euro per jaar) nu meer aan uitgeeft dan nodig is als je toch maar de helft van de geboden dienstverlening gebruikt.

Het zal mij vrij weinig uitmaken natuurlijk als je dat graag wil, maar ik zou daar toch wel kritisch naar kijken (of dus zoals gezegd wel gebruik gaan maken van de diensten die je afneemt; lijkt me een nog veel slimmere actie)

[Jelmer]

Defender for Office 365 en AIP zijn totaal wat anders en echt los van elkaar.

Defender for Office 365 = mail scanning, link substitution https://docs.microsoft.co...rview?view=o365-worldwide

AIP = document versleuteling, labeling, policies. - https://docs.microsoft.co...abels?view=o365-worldwide

De eerste gebruik je om malware, phisining buiten de deur te houden
De tweede gebruik je om (gevoelige) data BINNEN te houden.


Beide zitten wel in Business Premium., beide zitten niet in Business Standard. Ook Azure AD Premium P1 zit wel in Business Premium niet in Standard. Neem hier eens een kijkje: https://m365maps.com/Micr...%20Business%20Premium.htm

[Reactie gewijzigd door Jelmer op 24 juli 2024 11:14]

[segil]

Premium heeft meer features, zoals Defender for Office 365 (voorheen ATP), en Intune om je devices te managen. Kan prima samenwerken met een lokaal AD.

[kroegtijger]

Intune IS endpoint management. En ja, er is niets mis om dat met je OnPremise AD te koppelen natuurlijk, daar hebben we Azure AD Connect voor uitgevonden. Kan je met 1 credentialsetje op al je omgevingen inloggen, en werkt ook prima met MFA. Werk je met server2019, dan is seamless SSO ook beschikbaar, en kan je ook via hello authentiseren op je onpremise omgeving. Is geen enkel argument dus om dan met je lokale accountjes te gaan lopen klooien als er een perfecte oplossing voor handen is vanuit Microsoft.

[segil]

Wel als je on-prem diensten hebt draaien waar een AD voor nodig is.

[kroegtijger]

En wat is er dan mis met AzureAD Connect?

[segil]

ik volg je niet. Ik kreeg het idee dat je probeert te zeggen dat een lokaal AD helemaal niet nodig hoeft te zijn en je makkelijk alles in AAD kunt hebben. In dat geval heb je geen lokaal AD nodig natuurlijk.

[Vogel666]

AAD-Connect is de synchronisatie-tool van MS waarmee je Azure AD gelijk getrokken wordt met je OnPrem AD.
Maak een gebruiker aan in OnPrem AD dan bestaat ie een paar minuten later ook in Azure. Idem met rechten/groepslidmaatschappen.
Als je account sync op orde is, is PC in staat om middels Single Sign on en volledige intergratie tussen de 2 omgevingen te hebben...kortom de gebruiker merkt niet dat hij 2 accounts heeft, het lijkt 1 te zijn...

[segil]

ja, dat weet ik. Dat was ook niet de vraag hier

[Cergorach]

Is geen enkel argument dus om dan met je lokale accountjes te gaan lopen klooien als er een perfecte oplossing voor handen is vanuit Microsoft.

Tuurlijk is die er wel, je moet dan een hybride omgeving opzetten en volgens MS standaarden ook een lokale Exchange server opzetten die verbind met je Exchange Online. Een hybride omgeving is imho verre van zaligmakend. Laat staan voor een beheerder die er geen ervaring mee heeft is het een PIA!

Imho kan je zonder dat je meer inzicht hebt in de lokale AD omgeving/server er eigenlijk bitter weinig over zeggen.

[kroegtijger]

[...]

Tuurlijk is die er wel, je moet dan een hybride omgeving opzetten en volgens MS standaarden ook een lokale Exchange server opzetten die verbind met je Exchange Online.

Welnee, dat is compleet onzinnig. Je kan prima de Exchange Online dienst gebruiken. Er is geen enkele (maar dan ook echt geen enkele) reden om een OnPremise exchange te gebruiken hiervoor.

Een hybride omgeving is imho verre van zaligmakend. Laat staan voor een beheerder die er geen ervaring mee heeft is het een PIA!

Ah, dus het probleem zit niet in de techniek, maar in het gebrek aan kennis en kunde. Dat is een heel ander verhaal natuurlijk.

Imho kan je zonder dat je meer inzicht hebt in de lokale AD omgeving/server er eigenlijk bitter weinig over zeggen.

Je kan er in ieder geval over zeggen dat de rommel allemaal nog gebaseerd is op ouderwetse (nagenoeg legacy) technieken en werkwijzen. Dat hebben we allemaal al wel een paar jaar geleden over boord gegooid, want het is toch wel verdomde onhandig dat je stapels servers moet gaan beheren terwijl je vrijwel alles ondertussen ook wel als SaaS kan afnemen.

Daar waar je vanuit software-oogpunt toch nog vast hangt aan verouderde rommel kan je een OnPremise AD opzetten, sync je accounts met Azure AD Connect zodat je SSO kan gebruiken (of dat nu via PassThrough of via sync is maakt an sich niet zoveel uit. Als je setup redundant genoeg is uitgevoerd zou ik voor PassThrough kiezen). Voor dat beetje legacy rommel zet je vervolgens een RDS neer om het als remoteApp aan te bieden aan de users en klaar ben je.

Dus nee, ik zie nog steeds geen argumentatie voorbij komen behalve "ik weet niet hoe het moet"

[Cergorach]

Ja het kan zonder OnPremise Exchange, het nadeel is dat MS dat niet ondersteund (tenzij dat tussen nu en afgelopen jaar weer is veranderd), dus als je MS ondersteuning nodig hebt kan dat daar wel eens op stuk lopen, zeker bij grotere organisaties is dat ondenkbaar.

Natuurlijk is het kennis/kunde verhaal een issue, verwacht je dat de doorsnee MKB IT beheerder uitgebreide 'hybride' ervaring heeft als ze het nog niet gebruiken? De MS documentatie is... Complex te noemen en niet altijd even compleet. En als ze zelf gaan hobbyen krijg je vaak hele 'interessante' omgevingen... Waar men op afknapt (de uitspraken waarbij O365/AAD ruk is) of uiteindelijk een externe moeten inhuren om een prut omgeving eerst te ontprutten en dan goed in te richten.

Ik ben het helemaal met je eens dat zo een lokale AD omgeving asap uit een organisatie moet worden gewipt, minder (oude) bewegende onderdelen zorgen voor een efficiëntere omgeving die minder beheer kost, minder downtime heeft en daarmee goedkoper wordt. Echter afhankelijk van de omgeving kan je wel eens met zoveel legacy en dependencies zitten dat je bijna geen kant op kan. Omdat je bepaalde zaken niet zelf in beheer hebt (andere afdeling of derde partij), industrie standaarden, lang lopende bestaande contracten, investeringskosten, etc.

Bij het kleine MKB kon je meestal op korte termijn de hele lokale AD opdoeken, vaak niet eens meer lokaal servers. Als je nog legacy meuk had, in een VM op een cloudomgeving, de rest naar SAAS. Maar bij grotere en complexere organisaties, zeker in bepaalde branches, zit je met veel meer 'uitdagingen'. Als een interne beheerder, die dat al jaren op de traditionele manier doet, dit probeert dan kan die 9 van de 10 keer niet (efficiënt) de stap naar 'cloud' (O365/AAD) maken.

[segil]

Als je in een hybrid omgeving zit, waarbij je accounts managed worden vanuit lokaal AD, dan heb je een Exchange server on-prem nodig voor het beheer van de mail attributes. Dat is momenteel de enige ondersteunde oplossing vanuit Microsoft en een pain in the ass voor veel bedrijven, die migreren naar EXO en van hun Exchange servers af willen. Je kunt wel zelf gaat editen met aduc / adsiedit, maar dat wordt niet ondersteund.

[kroegtijger]

Als je in een hybrid omgeving zit, waarbij je accounts managed worden vanuit lokaal AD

Hier kan ik je al niet volgen waarom je zo'n situatie ook maar zou willen gaan creeeren. Je maakt jezelf het leven daar zo enorm veel moeilijker mee dan noodzakelijk is, maar ok...

dan heb je een Exchange server on-prem nodig voor het beheer van de mail attributes. Dat is momenteel de enige ondersteunde oplossing vanuit Microsoft en een pain in the ass voor veel bedrijven, die migreren naar EXO en van hun Exchange servers af willen. Je kunt wel zelf gaat editen met aduc / adsiedit, maar dat wordt niet ondersteund.

Het bewerken van attributes van objecten in je OnPremise AD wordt gewoon netjes supported hoor. Sterker nog, daar verwijst Microsoft ook in hun documentatie naar voor bijvoorbeeld het toepassen van aliassen op AD objecten via Azure AD Connect. Dan dien je het proxyAddress veld te vullen in je OnPremise AD. Is niets raars of ingewikkelds aan (en kan je uiteraard ook scripted via PowerShell laten bewerken; het is een normaal objectje waar je de values van kan zetten). AdsiEdit wordt een iets complexer verhaaltje, maar ook dat is niet per definitie unsupported. Ik heb overigens eigenlijk nooit AdsiEdit nodig om dergelijke bewerkingen door te voeren. Heel incidenteel dat het eens voorkomt dat een softmatch failed voor OnPremise / cloud objecten, maar meestal is dat een probleem met het source anchor dat niet gevonden kan worden en zelfs dan heb je AdsiEdit niet nodig om dat te fixen. Naar mijn mening zie je een aantal beren op de weg die er helemaal niet zijn en is er dan verder ook geen motivatie om aan de legacy werkwijzen vast te blijven houden. De moderne manier van werken zoals Microsoft dat hanteert werkt ideaal, en het zou prettig zijn als al die antieke software-boeren eindelijk hun rommel eens naar cloudbased oplossingen gaan brengen zoals we al een jaar of 10 implementeren, in plaats van nog steeds hunzelfde antieke rommeltje te blijven aanbieden. Die software steft vanzelf wel uit, en ik ben dan ook blij toe dat Microsoft met steeds hardere hand die risico-troep de nek om aan het draaien is. Als we het moeten laten afhangen van leveranciers als Unit4 zijn we over 30 jaar nog niet van de OnPremise rommel af.

[segil]

Het is gangbaar dat je je AD objecten lokaal beheert in een hybrid omgeving (computer, user, etc). Deze sync je dan naar Azure AD met adconnect. Daardoor moet je dus ook je mail attributes lokaal bewerken, omdat de source of athority lokaal is. Bij de middelgrote bedrijven waar ik gewerkt heb (en momenteel werk) is dit normaal.

Het managen van mail attributes via aduc oid wordt niet ondersteund door Microsoft. Alleen via Exchange. Zoals ik al zei, is dit een achileshiel van Exchange hybrid. Er wordft door bedrijven al jaren gevraagd naar een oplossing hiervoor. Je kunt wel met aduc zelf attributes gaan bewerken, maar dat problemen geven, omdat er geen check plaatsvindt. Jij kunt prima in aduc een duplicate proxyaddress invullen bij een object. Wat dus problemen gaat opleveren. Exchange ondervangt dat.

Zie ook https://docs.microsoft.co...sion-on-premises-exchange

Why you may not want to decommission Exchange servers from on-premises

Customers with a hybrid configuration often find after a period of time that all of their mailboxes have been moved to Exchange Online. At this point, they may decide to remove the Exchange servers from on-premises. However, they discover that they can no longer manage their cloud mailboxes.

When directory synchronization is enabled for a tenant and a user is synchronized from on-premises, most of the attributes cannot be managed from Exchange Online and must be managed from on-premises. This is not due to the hybrid configuration, but it occurs because of directory synchronization. In addition, even if you have directory synchronization in place without running the Hybrid Configuration Wizard, you still cannot manage most of the recipient tasks from the cloud. For more information, see this blog article.

Can third-party management tools be used?

The question of whether a third-party management tool or ADSIEDIT can be used is often asked. The answer is you can use them, but they are not supported. The Exchange Management Console, the Exchange admin center (EAC), and the Exchange Management Shell are the only supported tools that are available to manage Exchange recipients and objects. If you decide to use third-party management tools, it would be at your own risk. Third-party management tools often work fine, but Microsoft does not validate these tools.

[Reactie gewijzigd door segil op 24 juli 2024 11:14]

[kroegtijger]

Het is gangbaar dat je je AD objecten lokaal beheert in een hybrid omgeving (computer, user, etc). Deze sync je dan naar Azure AD met adconnect. Daardoor moet je dus ook je mail attributes lokaal bewerken, omdat de source of athority lokaal is. Bij de middelgrote bedrijven waar ik gewerkt heb (en momenteel werk) is dit normaal.

Misschien is het handig om dan even in de gaten te houden WAT je dan precies bewerkt en synct. Het lokale AD object is NIET (en ik kan niet genoeg benadrukken, NIET) hetzelfde als het cloud-object. Ze zitten alleen aan elkaar gekoppeld, maar meer dan dat ook niet. Je kan uiteraard NOOIT een sync vanuit cloud naar OnPremise doen; dat kan alleen vanuit OnPremise naar cloud. Dat je dus je bewerkingen OnPremise moet doen en moet syncen naar het cloud-object is een volstrekt logische werkwijze, maar veranderd daarmee verder dan ook 0,0 aan de situatie.

Het managen van mail attributes via aduc oid wordt niet ondersteund door Microsoft. Alleen via Exchange. Zoals ik al zei, is dit een achileshiel van Exchange hybrid. Er wordft door bedrijven al jaren gevraagd naar een oplossing hiervoor. Je kunt wel met aduc zelf attributes gaan bewerken, maar dat problemen geven, omdat er geen check plaatsvindt. Jij kunt prima in aduc een duplicate proxyaddress invullen bij een object. Wat dus problemen gaat opleveren. Exchange ondervangt dat.

Zie ook https://docs.microsoft.co...sion-on-premises-exchange


[...]

Blijft nog steeds de vraag overeind staan wat je met een hybrid exchange situatie zou moeten willen. Da's een situatie die je hooguit tijdelijk hebt voor migratie (maar meestal rammen we ze er gewoon in een weekendje allemaal doorheen naar de cloud; dan heb je er uberhaupt geen omkijken naar). Wat zou je motivatie zijn om een hybrid Exchange omgeving te gaan bouwen? Want ik ben eigenlijk nog nooit een situatie tegengekomen waarin een OnPremise exchange omgeving niet om kon naar een Exchange Online omgeving. Heel incidenteel kom je wel eens wat pruts-werk tegen van goed bedoelde hobby-projectjes die wat gescript hebben tegen hun lokale exchange aan over PowerShell, maar vrijwel niets wat dermate complex en hoogstaand is dat dit onmogelijk tegen de Exchange Online omgeving kan worden aan gezet, of dat er wel een andere oplossing voor handen is.

Ook als ik de documentatie van Microsoft hierover erbij pak (zie https://docs.microsoft.com/en-us/exchange/exchange-hybrid) worden er eigenlijk nagenoeg geen voordelen genoemd buiten het ondersteunen van oude rommel (lees: Exchange ActiveSync enabled devices). Als dat het probleem is waar je mee zit, dan lijkt het mij (aanzienlijk) zinvoller om die oude clients eruit te bonjouren in plaats van een hele server-omgeving in de lucht te houden voor oude rommel

[segil]

Ik lees wat tegenspraak hier. Je erkent dat je een sync'd omgeving nodig hebt (lokaal AD die leidend is en attributes synct naar AAD), waarbij dus ook on-prem Exchange attributes beheerd worden via Exchange. En vervolgens zeg je niet te snappen waarom je een Exchange hybrid wilt opzetten?

Allereerst heb je de eis om een on-prem Exchange te behouden voor het beheer van je Exchange attributes, zoals Microsoft betoogd.
Ten tweede bouw je een hybrid omgeving om je mailboxes te migreren (via mailbox moves). Ik denk dat jij vooral in het MKB segment werkt, als je het hebt over migratie in een weekendje. Dat doe je niet in een omgeving van 5000+ mailboxen. Dat gaat gefaseerd. Ik heb nu 2 migraties naar EXO gegaan bij dergelijke organisaties en met alle vooronderzoek, afstemmen, migreren van batches, support, etc., was ik in beide gevallen 1 jaar hiermee bezig. Vooral mailboxes van functionele accounts die lokaal via ews/imap mail uitlezen, kunnen pas gemigreerd worden als de applicatie oauth ondersteunt. (modern auth + mfa eis).
Als alles gemigreerd is, heb je nog smtp clients zoals MFA's, die moeten kunnen blijven mailen en het makkelijkste is dat via de smtp server van on-prem Exchange, die dit via de hybrid connector naar EXO verstuurt.

Het zou mooi zijn om lokaal geen Exchange meer te hebben, maar dat zal voorlopig nog niet zijn.

[kroegtijger]

Ik lees wat tegenspraak hier. Je erkent dat je een sync'd omgeving nodig hebt (lokaal AD die leidend is en attributes synct naar AAD), waarbij dus ook on-prem Exchange attributes beheerd worden via Exchange. En vervolgens zeg je niet te snappen waarom je een Exchange hybrid wilt opzetten?

Nee, dat stel ik niet. Ik stel dat als je attributes wil bewerken (ongeacht welke attributes) en je maakt gebruik van AzureAD Connect, dat je dat dan altijd OnPremise moet doen en niet aan de cloud-kant. Dat geldt bijvoorbeeld ook voor aliassen voor een ExchangeOnline omgeving die je via die weg dan moet doen. Dat heeft dus niets met een hybride exchange-implementatie te maken, maar alles met je AD objecten.

Allereerst heb je de eis om een on-prem Exchange te behouden voor het beheer van je Exchange attributes, zoals Microsoft betoogd.
Ten tweede bouw je een hybrid omgeving om je mailboxes te migreren (via mailbox moves). Ik denk dat jij vooral in het MKB segment werkt, als je het hebt over migratie in een weekendje. Dat doe je niet in een omgeving van 5000+ mailboxen. Dat gaat gefaseerd. Ik heb nu 2 migraties naar EXO gegaan bij dergelijke organisaties en met alle vooronderzoek, afstemmen, migreren van batches, support, etc., was ik in beide gevallen 1 jaar hiermee bezig. Vooral mailboxes van functionele accounts die lokaal via ews/imap mail uitlezen, kunnen pas gemigreerd worden als de applicatie oauth ondersteunt. (modern auth + mfa eis).

5000+ mailboxen zijn ook niet echt een issue natuurlijk. Je kan prima de sync meerdere keren laten lopen, en op het moment van overzetten mik je de MX-records om, je doet nog 1x een laatste sync en daarna neem je afscheid van je OnPremise omgeving en werk je cloudbased. Wel even de clients opnieuw configureren natuurlijk, maar dat spreekt voor zich lijkt me. Als we ons met dat soort grappen een jaar lang bezig gaan houden hebben we wel heel erg de poppen aan het dansen natuurlijk. 5000 mailboxen klinkt veel, maar in de praktijk is dat helemaal niet zo heel extreem. Daarbij is de hoeveelheid data ook vele malen interessanter dan het aantal mailboxen. 5000 mailboxen van 100MB 't stuk is maar 50GB data dat je over moet harken, maar praat je over 10 mailboxen van 50GB 't stuk is het al een heel stuk meer tijd dat je ervoor nodig hebt. Ook dan geldt dat je zo vaak je sync kan doen als je wil, zodat je alleen nog op het allerlaatst nog even de resterende items dient te syncen en er een klap op kan geven.

Of het er dus 10, 100 of 5000 zijn maakt nagenoeg niets uit als het systeem dat je hanteert klopt. Als je alles handmatig moet gaan aanpassen en wijzigen, dan is 5000 heel veel uiteraard.

Vergis je wat dat betreft niet; dergelijke getallen zijn voor de Microsoft wereld niet spannend. Daar praten we meer dan eens over omgevingen met 50.000 tot 100.000 end-users wereldwijd. Dan wordt het allemaal wat andere koek, maar 5000 is niet iets heel spannends te noemen.

Als alles gemigreerd is, heb je nog smtp clients zoals MFA's, die moeten kunnen blijven mailen en het makkelijkste is dat via de smtp server van on-prem Exchange, die dit via de hybrid connector naar EXO verstuurt.

?? Nee, da's wel echt een regelrecht foute methode te noemen (even er vanuit gaande dat je hier niet MultiFactor Authenticatie bedoeld maar MultiFunctional devices, oftewel printers met scan-functie). Daar heeft Microsoft een heel prima oplossing voor gemaakt door netjes authenticatie voor mailrelay te implementeren. Zie https://docs.microsoft.co...crosoft-365-or-office-365 onder optie 1. Implementeer je ook direct MFA, dan kan je een app password voor dat account genereren die je voor authenticatie kan gebruiken zodat je geen problemen met de MFA challenge zal ondervinden.

Het zou mooi zijn om lokaal geen Exchange meer te hebben, maar dat zal voorlopig nog niet zijn.

De laatste lokale exchange die echt noodzaak kende heb ik al in geen jaren meer gezien. Ben erg benieuwd waar die noodzaak uit bestaat.

[Cergorach]

5000+ mailboxen zijn ook niet echt een issue natuurlijk.

En hoe vaak heb je dit zelf daadwerkelijk gedaan in een complexe omgeving in een weekend (of zelfs een paar weken)?

[kroegtijger]

Meer dan eens al wel hoor. Zo spannend is het allemaal niet

[Cergorach]

Vooral mailboxes van functionele accounts die lokaal via ews/imap mail uitlezen, kunnen pas gemigreerd worden als de applicatie oauth ondersteunt. (modern auth + mfa eis).

This! So much THIS! ;-)

Nadat je het gros heb geupgrade/vervangen, zit je altijd nog met 1 of 2 applicaties die eigenlijk niet vervangen/geupgrade kunnen worden en kan je nog niet verder met je migratie. Ik heb uiteindelijk zelf wat moeten bouwen in Power Automate omdat de laatste leverancier niet opschoot en deadlines zelf niet haalde door instabiele software te leveren met oauth ondersteuning.

In het klein MKB kom je inderdaad veel minder dat soort situaties tegen en als je het tegenkomt, moet je niet tig systemen upgraden of vervangen zodat het netjes wordt ondersteund.

Je kan prima een werkende sync bouwen met een AD omgeving zonder lokale Exchange server, officieel ondersteund MS dat niet. Die specificatie heeft niet altijd in de documentatie gestaan, die staat daar nu al weer wat jaartjes in. Voor een kleine MKB is dat niet super problematisch en prijstechnisch zeer aantrekkelijk en 9 van de 10 keer viel het MS support niet eens op. Maar de laatste keer dat ik een dergelijke omgeving actief ondersteunde is alweer jaren geleden, MS kan daar nu veel moeilijker over doen. En voor een Enterprise omgeving is het al vlot een gehele no-NO!

Het is absoluut heerlijk om geen lokale Exchange meer te hebben! ;-)

[kroegtijger]

[...]

This! So much THIS! ;-)

Nadat je het gros heb geupgrade/vervangen, zit je altijd nog met 1 of 2 applicaties die eigenlijk niet vervangen/geupgrade kunnen worden en kan je nog niet verder met je migratie. Ik heb uiteindelijk zelf wat moeten bouwen in Power Automate omdat de laatste leverancier niet opschoot en deadlines zelf niet haalde door instabiele software te leveren met oauth ondersteuning.

Maar precies in dat laatste zit dan ook het probleem, namelijk die software-boeren die niet in staat zijn de rommel op orde te krijgen. Gelukkig sterven die vanzelf wel uit of gaan om, want veel meer keuze is er op den duur niet meer. Overigens hebben we nog steeds wel klanten met 1 of 2 pc'tjes in een hoek weg gepropt om die ene machine nog aan te sturen, of dat antieke boekhoudpakket nog te kunnen nazoeken, maar da's nog op 1 hand te tellen. Draait vaak allemaal nog op Windows XP of ouder ook, dus was hoe dan ook al lang end of life.

[ExilaaHH]

Dat is zeker niet waar. Als je bijvoorbeeld van RDS/Citrix gebruik maakt ben je E3 of Business premium nodig voor shared desktop activation.

[PageFault]

Het marktaandeel van Citrix gaat in een heel erg rap tempo omlaag (en terecht overigens, maar dat is een andere discussie...). Dus je opmerking is zeker waar, maar voor een klein, en krimpend, deel van de klanten.

[OxWax]

In het voordeel van een andere TC toepassing?

[PageFault]

Ik kom die thin clients bijna niet meer tegen bij klanten. Blijkbaar zijn die kastjes niet meer goedkoper dan een stapel instap desktopjes.
Of er is gewoon veel te veel gedoe met Citrix, daar hoor ik alle klanten die het hebben de hele dag over klagen.

[RobbieB]

Voor 10 medewerkers is het sowieso verstandig om over te stappen op AAD. Scheelt je een hoop onderhoud op je lokale AD. En qua security maatregelen is AAD sowieso vele malen beter.

[Inspired]

Vind je? Iets simpels als een password policy instellen kan al niet zonder lokale AD.

[kroegtijger]

https://howtomanagedevice...rd-policies-using-intune/

Geen hogere wiskunde om dat op Endpoint Manager in te stellen hoor.

[Inspired]

Zeker niet. Maar dan zit je dus al vast aan Intune. Plus, voor cloud only accounts werkt dat niet. En als mensen de portal gebruiken om het password te changen ook niet. Dus dit is een halve oplossing. Een 100% vervanger van een lokale AD is AAD nog niet. Dat is ook wat MS zelf zegt. Zou het graag anders zien overigens.

[kroegtijger]

Uiteraard is dit gebaseerd op AAD accounts; OnPremise password policy moet je natuurlijk ook OnPremise instellen, en lokale password policy moet je dan ook lokaal managen. In dat laatste geval zal je dat dan ook scripted moeten doorvoeren. De policy geldt natuurlijk alleen voor users en devices die daarop aanmelden, zoals dat ook bij OnPremise functioneert.

Het gebruik van passwords is echter ondertussen ook al wel redelijk achterhaald aan het raken; daarvoor gebruiken we natuurlijk gewoon Windows Hello, en in combinatie met MFA zal je daar nog een app passwordje bij nodig hebben om je outlook te configureren. Ik gok dat 90% van onze end-users geen flauw idee (meer) heeft wat hun wachtwoord uberhaupt is, want dat gebruiken ze niet meer. Modern OS met moderne hardware lost dat netjes op. Je klapt je laptop open, Windows Hello activeert je camera en logt je automatisch in.

[Vogel666]

En hoe gaan je applicaties die LDAP auhenticatie en provisioning gebruiken om met Windows Hello?
Ik geef toe ze worden schaarser, maar ik heb er toch nog tientallen in beheer.
Niet iedere omgeving is een kantooromgeving, waar word en Excel de kern applicaties zijn.
Biometrisch inloggen is sowieso geen optie voor veel bedrijven...immers niet iedereen werkt bij een koekjesfabriek... en zelfs die willen hun recepturen geheim houden.
Kernactiviteiten van een bedrijf (productie) moet vaak autonoom doordraaien ookal is er geen internet of zelfs net-stroom.

[kroegtijger]

En hoe gaan je applicaties die LDAP auhenticatie en provisioning gebruiken om met Windows Hello?

Prima gaan die ermee om, zolang je maar Server2019 (of nieuwer) gebruikt. Zit je nog op 2012r2 of 2016, dan werkt dat helaas niet en ben je nog wel aan wachtwoorden gebonden, maar de nieuwere versies ondersteunen dat wel netjes en geven je een Seamless Single SignOn experience.

Ik geef toe ze worden schaarser, maar ik heb er toch nog tientallen in beheer.
Niet iedere omgeving is een kantooromgeving, waar word en Excel de kern applicaties zijn.
Biometrisch inloggen is sowieso geen optie voor veel bedrijven...immers niet iedereen werkt bij een koekjesfabriek... en zelfs die willen hun recepturen geheim houden.

Juist in niet-koekjes-fabrieken is dat interessant, want je geeft niet zo snel je gezicht of je vingerafdruk aan je collega af, maar een wachtwoordje delen werd voorheen heel veel gedaan (met alle ellende van dien natuurlijk. Gebruiker A wil een wachtwoord-reset voor het account productiemedewerker, gebruiker B weet niet van het nieuwe wachtwoord en kan er niet in, vraagt dus weer een reset, gebruiker A weet daar niets van etc etc. Bakken met werk brengt die onzin met zich mee).

Kernactiviteiten van een bedrijf (productie) moet vaak autonoom doordraaien ookal is er geen internet of zelfs net-stroom.

Ook dat is geen enkel bezwaar, maar daarvoor geldt dus dat je dan vooraf goed moet nadenken of je wel passthrough-auth wil gaan toepassen of dat je synced passwords wil toepassen. Passthrough is wat veiliger en degelijker omdat je wachtwoorden maar op 1 plek staan en er geen sync plaatsvind, maar rust wel op het concept dat je OnPremise omgeving (en dan gaat het dus om de agents die de autenticatie afhandelen de DC kan bereiken) bereikbaar is vanuit de omgeving van Microsoft vandaan. Plaats je de OnPremise omgeving dus netjes in een datacenter, eventueel aangevuld met een of meerdere servers op locatie als daar noodzaak voor is, gekoppeld over VPN (des noods met een ReadOnly DC erbij), dan weet je redelijk zeker dat je daar geen probleem mee zal ondervinden. Als het hele datacenter offline ligt, is je probleem toch al wel wat groter dan alleen de user die niet kan authenticeren. Wil je daar meer zekerheid van uptime in brengen, dan kan je kiezen voor synced passwords, waarmee dus het wachtwoord OOK op de omgeving van Microsoft staat. Mocht om wat voor reden dan ook OnPremise onbereikbaar zijn, dan kan je nog altijd op de cloudomgeving inloggen omdat authenticatie dan tegen de wachtwoorden gebeurt die cloud-based zijn opgeslagen.

Het idee dat je omgeving veiliger zou zijn als je zelf het beheer doet is wel redelijk een achterhaald concept. Je kan zelf realistisch gezien nooit op tegen de robuustheid van de omgeving die Microsoft daarin heeft neergegooid. Recepturen sla je dus 10x veiliger in je SharePoint Online omgeving (of beter, in het team dat aan die omgeving hangt) dan dat je dat op je OnPremise server doet waar je ook nog zelf je eigen backup moet regelen, hardware moet monitoren etc etc etc. Dat zijn allemaal zaken die Microsoft uit handen neemt voor je door het cloud-based weg te zetten.

[Vogel666]

maar de nieuwere versies ondersteunen dat wel netjes en geven je een Seamless Single SignOn experience

ja zolang de applicatie SAML of afgeleide protocollen ondersteund. Maar ik heb nog nooit een LDAP authenticatie tegen Azure aan kunnen houden...

Je hebt duidelijk een heel ander bedrijf voor ogen dan ik. Productiebedrijven waar machines computergestuurd zijn, vragen om een heel andere aanpak. Als je glas-oven stilvalt dan kun je hem gewoon afbreken en zie dan maar eens een massief blok glas van 100m3 te verwijderen uit je fabriekshal...dat kost maanden. Er is geen weldenkend mens dat de de aansturing daarvan (of de authenticatie) afhankelijk maakt van een internetverbinding. Die maak je redundant over meerdere locaties .... onsite en offsite.

Overigens....zelf een offsite backup op orde houden....dat is echt een heel kleine moeite.

Azure is best leuk voor kantoorgeneuzel als email en Sharepoint. Maar ik zou er zeker even ndadenken voordat ik mijn noodprocedures daar ga plaatsen...

[Reactie gewijzigd door Vogel666 op 24 juli 2024 11:14]

[segil]

nee, defender for endpoint draait prima op je lokale AD clients. En je kunt ook agents installeren op je dc's om die te monitoren. Daarentegen, als je alleen maar gebruik maakt van cloud diensten, kan zou je mogelijk ook voldoende hebben aan AAD en hoef je geen lokale AD meer te draaien.

[Reactie gewijzigd door segil op 24 juli 2024 11:14]

[Vaelken]

Zelf ben ik op mijn werk aan het testen met de Defender for Business antivirus. Omdat we de de trial licenties gebruiken, hebben de mensen in de testgroep ook geen Business Premium, en zijn zij ook niet managed via Intune of AAD. In het overzicht van de defender zie je dan ook 'Managed by MEM' of 'Managed by MDE'. Je hoeft dus niet in te loggen via AAD.

[Whis!]

Ah check, ik moest het ook eerst nog aanzetten in het security dashboard. Ik ga nu door een wizard heen met de configuratie dus volgens mij komt het goed!

[AlainG]

In de hele discussie over verdor x tegen vendor y vraag ik me af of er al goed werkende tools zijn in open source om dit over te nemen ? Je hebt natuurlijk ClamAV, maar verdere Endpunkt Protection ? En verder ? Ik zou graag goede tools zien zonder al de commerciële belangen van de vendors.

[Razwer]

In de security wereld gebruiken bijna alle vendors een bepaalde mate van open source tools voor hun producten, maar een open source EPP (die ook effectief is) bestaat niet, simpelweg vanwege het feit dat threat actors door met het lezen van de broncode weten hoe ze het kunnen omzeilen.
Security through obscurity is in de EPP wereld nog steeds een belangrijk wapen.

[mutley69]

Dat is dus payware - gemaakt door de maker van uw OS - uw Cloud - eigenlijk heeft de maker er baat bij zijn andere produkten net niet goed genoeg te maken - zodat die antimalwaretools nodig/nuttig zijn.
Eigenlijk verdient Microsoft hiervoor gestraft te worden!