Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Samba dicht lek dat gebruikers wachtwoorden laat wijzigen op AD-domeincontroller

Samba heeft patches uitgebracht voor een lek dat aangemelde gebruikers zonder rechten de wachtwoorden van andere gebruikers laat wijzigen, inclusief beheerders. De kwetsbaarheid doet zich voor als Samba wordt gebruikt als Active Directory-domeincontroller.

Het lek, met kenmerk CVE-2018-1057, heeft er volgens de waarschuwing mee te maken dat de ldap-server op de verkeerde manier rechten valideert. De kwetsbaarheid is aanwezig vanaf versie 4.0.0alpha13 en staat beschreven in een speciaal wiki-artikel. Patches zijn beschikbaar in de vorm van versies 4.7.6, 4.6.14 en 4.5.16. Volgens de Samba-ontwikkelaars is op de patch-pagina ook te achterhalen of er oplossingen voor oudere versies van de software beschikbaar zijn.

In het wiki-artikel staan bovendien verschillende work-arounds beschreven, zoals het intrekken van wachtwoordwijzigingsrechten van alle gebruikersobjecten inclusief computers voor 'the world'. Om dat te doen is er een zogenaamde helper-tool in het leven geroepen. Het risico van het lek is dat een aanvaller mogelijk toegang kan verkrijgen tot een account met hogere rechten door het wachtwoord ervan te wijzigen.

De kwetsbaarheid is ontdekt door het Duitse SerNet, waarvan mensen ook aan de ontwikkeling van Samba werken. Het Samba-team waarschuwt daarnaast voor een tweede kwetsbaarheid met kenmerk CVE-2018-1050, dat het toelaat een dos-aanval op een externe printserver uit te voeren vanaf versie 4.0.0 van de software.

Samba is een opensource-implementatie van het smb/cifs-netwerkprotocol. Dit protocol is aanwezig in Windows en maakt het mogelijk om bestanden en printers via het netwerk te delen. Om interoperabiliteit met andere besturingssystemen als Linux, Unix en BSD te faciliteren is Samba in het leven geroepen. Daardoor kunnen bijvoorbeeld Linux-servers deelnemen in een Active Directory en ook fungeren als domain controller. Dat kan sinds versie 4.0.0.

Door Sander van Voorst

Nieuwsredacteur

13-03-2018 • 13:26

49 Linkedin Google+

Reacties (49)

Wijzig sortering
Vrij serieuze lek toch weer. Bij de vorige Samba security leak werd bij ons al snel geopteerd om het niet meer te gebruiken. Het idee erachter is goed, maar als de implementatie en/of het protocol onderhevig zijn aan zulke exploits, is het risico simpelweg te groot.
Vrij serieus lek inderdaad. Maar Microsoft heeft in hun eigen implementatie ook regelmatig grote lekken laten vallen.

Ik laat het niet vallen dus, maar ga wel snel mijn Samba PDC updaten.
Heel Active Directory is een speelplaats voor kwaadwillenden. Ik vraag me af wanneer er degelijke oplossingen komen vanuit Microsoft om ernstige kwestbaarheden zoals Pass the Hash te mitigeren in plaats van adviezen om enkel domain admins af te schermen. Ja dat kan het probleem grotendeels verhelpen, maar dat is voor grote domeinen een tijdrovende en kostbare taak.

[Reactie gewijzigd door deacs op 14 maart 2018 00:08]

Voor Windows werkstations is er een dergelijke oplossing al: LAPS.
Voor Windows servers zijn er oplossingen als Just in time administration en just enough administration waarmee je domain admin accounts in principe al kunt elimineren.
Wil je het helemaal secure doen, moet je wel een bastion domein gaan inrichten, waar je het beheer vanuit gaat doen.

En ja, dit is inderdaad bekeken vanuit de theorie. LAPS is vrij eenvoudig te implementeren, maar JIA en JEA vanuit een bastion domein zijn wel dingen die echt veel impact hebben op je beheer organisatie en je werk, waardoor het voor veel bedrijven geen werkbare oplossing is.

[Reactie gewijzigd door walteij op 13 maart 2018 14:28]

Advies van MSFT zelf:
- LAPS voor clients
- Iedereen heeft een user account (Tier 2), zonder beheerdersrechten
- IT personeel dat op bijv. een server moet kunnen inloggen krijgt een beheerdersaccount (Tier 1)
- Domain admins krijgen een domain admin account (Tier 0)

Tier 2 mag elke 3 maanden zijn wachtwoord veranderen
Tier 1 mag dit iedere 6 weken doen
Tier 0 mag dit wekelijks doen.
Sinds de introductie van Windows 10 is er een oplossing voor pass-the-hash: Windows Defender Credential Guard. Die zorgt dat het lsass.exe process - verantwoordelijk voor genereren van tokens - afgeschermd is voor het besturingssysteem zelf. Hier wordt virtualisatie voor gebruikt en helpt tegen allerlei derived credential theft problemen. Deze feature zet je aan zonder enige vorm van beheer, alleen even kijken of eventuele 3rd party SSO software compatible is. Windows Server kent deze feature ook.
En met JIA en JEA zorg je er dus zelfs voor dat mensen met een Tier 1 account niet standard overal bij kunnen. Via enkele powershell commando's worden er rechten aangevraagd (en goedgekeurd), waarna de Tier 1 medewerker zijn werkzaamheden kan doen.
Via delegation of control kun je al heel veel werkzaamheden netjes laten uitvoeren zonder dat je domain admin bent.
Tier 0 accounts moeten wat mij betreft alleen gebruikt worden als het echt niet anders kan. Dus daar hoort dan ook gewoon een (minimaal) 24 karakter lang sterk wachtwoord bij. Dat hoeft dan dus ook niet wekelijks veranderd te worden.
Mocht je de domain admin accounts dan wel actief gebruiken, is het wekelijks aanpassen van die wachtwoorden weer een risico op zichzelf, omdat mensen dan toch makkelijker te onthouden wachtwoorden gaan gebruiken (met volgnummers, of week/jaar in het wachtwoord).
LAPS is standaard niet zo heel veilig, als je een foutje maakt in de ACLs kan iedereen bij de paswoorden komen. Bovendien is er geen audit log wie de paswoorden opvraagt.

Wij gebruiken een aangepaste versie van LAPS waarbij de paswoorden met een public key worden ge-encrypt, en kunnen alleen met via een webservice met auditing worden opgevraagd (die webservice decrypt ze dan).

Wekelijks je paswoord veranderen is trouwens vrij bizar, gelukkig doen we dit niet (ben zelf ook domain admin). Beter zou het natuurlijk zijn als ze het protocol aanpassen zodat pass the hash niet meer werkt. Anders laat je je users opdraaien voor je eigen ontwerpfouten. Zo vaak je paswoord veranderen leidt er gewoon toe dat mensen sequentiele paswoorden gaan gebruiken of ze op een makkelijke plaats opschrijven. Beter zou dan zijn om bijv. smart cards aan te raden, dan voeg je tenminste nog iets toe aan de beveiliging.

[Reactie gewijzigd door GekkePrutser op 13 maart 2018 15:12]

Binnen LAPS moet je inderdaad heel goed uitkijken met de ACL's.
Het auditen van LAPS is overigens niet zo heel moeilijk en zeer zeker wel aan te raden.
Ah ok, volgens ons AD team was het voor ons niet mogelijk, en wat betreft vertrouw ik op hun kennis. Zal wel iets zijn met scaling want we hebben 140.000 devices.

Ik ben zelf geen expert in AD. Maar ik doe Macs en ik heb de Mac LAPS client aangepast met de encryptie die ze toegepast hebben zodat het voor Windows en Mac hetzelfde werkt.
En ja, dit is inderdaad bekeken vanuit de theorie. LAPS is vrij eenvoudig te implementeren, maar JIA en JEA vanuit een bastion domein zijn wel dingen die echt veel impact hebben op je beheer organisatie en je werk, waardoor het voor veel bedrijven geen werkbare oplossing is.
Dat is het probleem inderdaad. In plaats van dat er gestandaardiseerde oplossingen vanuit MS komen, moeten bedrijven zelf oplossingen implementeren die vaak niet werkbaar zijn of die andere beveiligingsproblemen met zich meebrengen, dat geldt dus ook voor LAPS. Al lees ik wel vooruitgang met de Windows Defender Credential Guard voor nieuwe versies van Windows.

[Reactie gewijzigd door deacs op 14 maart 2018 00:53]

Vervelende is wel dat je later terug zo een lekke versie zou kunnen installeren als DC en dan lekker alle paswoorden zitten veranderen. Uiteraard moet je al aardig wat rechten hebben om dit te kunnen doen in AD, maar als ik zou willen exploiten zonder het al te hard te laten opvallen:

- kwetsbare Samba DC installeren
- paswoorden veranderen
- logs opkuisen
- tweede kwetsbare Samba DC installeren met een ander gereset admin account
Het lek is naar, dat zeker. Ik denk ook dat de meesten schrikken van het woord Samba en meteen denken aan een fileserver..... Logisch natuurlijk, daar begon het. :)

Als je dit lek wilt misbruiken heb je een Samba LDAP server nodig. Dat is niet zo heel moeilijk maar je moet domain admin rechten hebben om de server aan de AD te joinen. Daarna gaat je LDAP server wel opvallen want komt netjes in de Domain Controllers OU terecht O-) . Daarnaast komt je server overal in de topologie terug.

Je beste kans is dus een bestaande Samba LDAP server misbruiken :9 . Sinds enkele jaren zit dat bijvoorbeeld standaard in NAS servers als FreeNAS.
En vergeet niet dat het allergrootste Microsoft lek ooit (als je i.p.v. user-credentials gewoon een setje met 0-bytes aanleverde werdt het als "Administrator" beschouwd ) ontdekt is juist DOOR de Samba ontwikkelaars die hun implementatie vergeleken met die van Microsoft.

Maar Micosoft doet continu wel heel erg zijn best om de interne werking van cifs/smb zo obscuur mogelijk te maken zodat de ontwikkelaars van Samba permanent catch-up moeten spelen.
Subtiele verschillen tussen verschillende Windows versies, ongedocumteerde functies, ongedocumenteerd (of totaal anders) gedrag bij functionalitiet die wel gedocumenteerd is. De lijst is erg lang.

En dat werkt fouten, zowel bij Microsoft als bij de ontwikkelaars van compatible software in de hand.
Maar om nou Samba helemaal in de ban te doen.
Voor interoperaibiliteit met WIndows systemen kun je eigenlijk niet om Samba heen.
Wat ga je dan gebruiken? Er is geen alternatief (voor zover mij bekend) dat dezelfde funktionaliteit biedt.
Maar zoveel alternatieven zijn er niet voor een AD infrastructuur. Het eenvoudigste alternatief is natuurlijk omschakelen naar Microsoft. En hoewel zoiets relatief eenvoudig kan vanuit gebruikersperspectief zal daar toch weer een hoop voorbereiding en bijgevolg ook kosten aan te pas komen om het technisch mogelijk te maken.
Denk dat het probleem op dat vlak toch vooral licentiekosten is... als je als beheerder linux snapt en met een Samba DC voor elkaar krijgt wat je nodig hebt, hetzij met wat kunst en vliegwerk, is een business case voor al die licentiemeuk van Microsoft best lastig.
Laatste keer dat ik daar naar zat kijken zaten ze bijvoorbeeld nogsteeds te rommelen met die CAL zooi. Dat moet gewoon weg. Al is dat inmiddels ook al wel even geleden.

[Reactie gewijzigd door Koffiebarbaar op 13 maart 2018 14:26]

Voor een AD en een fileserver zijn geen CAL's nodig.
CAL's zijn voor applicatieservers, SQL servers (mits geen enterprise, want die rekent per core) en Exchange servers.

De licenties van Microsoft zijn inderdaad een vak apart, veel te ingewikkeld en soms zelfs conflicterend. Wel CAL licenties, geen CAL licenties, core licenties, core + CAL licenties, en allerlei andere dingen er tussenin.

[Reactie gewijzigd door walteij op 13 maart 2018 15:01]

Niet waar.. Voor elke user in een AD domein die een echt poppetje is heb je een Windows CAL nodig. Als je dan ook nog RDS/Citrix gebruikt heb je ook nog een RDS CAL nodig en voor Exchange idd een Exchange Call.

Een beetje user kost dus al snel minimaal 1500 euro alleen al aan CALs.
Feit dat hier überhaupt discussie over bestaat lijkt me voldoende zeggen over Microsoft's
tamelijk wazige licentiemodel...
Daar zal een certificeerde Microsoft partner misschien een andere mening over kunnen hebben maar licenties beheren zou je m.i. al met al geen scholing voor genoten moeten hoeven hebben. Daar moet gewoon een zeker mate van vanzelfsprekendheid werken en dat is rond in ieder geval die CAL meuk zeker niet zo.

[Reactie gewijzigd door Koffiebarbaar op 13 maart 2018 15:07]

Wat ik er nog van herinner heb je de keuze tussen CALs voor je users of CALs voor je devices en heeft elke PC met een windows licentie die aan het domein komt al een eigen device CAL. Heb je dan een beperkt aantal extra apparaten en een relatief eenvoudige omgeving dan kan het lonen om je dus op device CALs te richten en als je AD enkel voor user management gebruikt kan je er dus aan ontkomen met enkel de meegeleverde CALs.
Een apparaat met Windows komt niet inclusief een device CAL.
Het licentie drama is zelfs zo erg dat wanneer een gast bij jou op het netwerk komt en een IP address van je Windows DHCP server krijgt hier eigenlijk een device CAL voor aanwezig moet zijn.
De controle en handhaving hiervan is gelukkig totaal afwezig, maar zo erg is het daadwerkelijk wel gesteld. Ze maken het echter niet al te makkelijk inderdaad.
Uhmm jawel je moet een CAL hebben voor ieder apparaat, zelfs printers... (of iedereen een user CAL)

1 – Does my Multifunction Printer need a CAL?

Yes, if the multifunction printer is connected to a Windows Server network. A multifunction printer accesses server software to; receive an IP address, to receive a job, to communicate that the job is finished, etc. In short, it communicates with the server software. ...
https://blogs.technet.mic...lient-access-license-cal/

[Reactie gewijzigd door Rinzwind op 13 maart 2018 14:46]

Hmm, nog eens wat extra informatie doorgelezen en je hebt inderdaad (grotendeels) gelijk.
Als de printer een vast IP adres heeft en niet op de printserver is geinstalleerd, hoef je geen CAL te hebben, anders wel (DHCP en printserver zijn toch wel een makkelijk in een iets grotere organisatie).

Ook wordt de printer CAL in principe afgedekt door de user CALs. Ik heb mijn originele post ook even anagepast, want mijn eerste regel daar was dus overduidelijk fout.
Als je dan toch al niet veel bezig bent met GPO's en dergelijke maar wel over wilt naar een stabiele DC en misschien ook beheer uit huis wil plaatsen kan het interessant zijn om eens te kijken naar Azure Active Directory? Dan heb je vrij snel een maandelijkse prijs per gebruiker en ben je ook van je CAL zooi af. (maar uiteraard wel vele male duurder dan zelf een samba omgeving bouwen en hosten)
Als je Cal’s nodig hebt wil dit zeggen dat je ook gebruik maakt van Windows applicaties, dan zal de kostprijs van 2 extra windows server licenties om te gebruiken als GC/DC ok wel meevallen.

[Reactie gewijzigd door klakkie.57th op 13 maart 2018 14:41]

Ik zie bij ons steeds minder focus op AD, en een zoektocht naar mogelijkheden om er vanaf te komen :)

Want het systeemlandschap verandert ook. Steeds meer mobiele devices. Steeds meer apparaten die er tussenin zitten (Windows ARM, iPad Pros) en waar je steeds grotere delen van je werk op kan doen. Steeds meer Mac en Linux. Veel meer vraag naar BYOD (Bring Your Own Device). Mensen willen geen strakke IT afdeling meer die ze vertelt wat ze moeten gebruiken en dat ze niet op een moderne manier kunnen werken. En willen niet meer met twee laptops lopen.

Dus wij zetten steeds meer in op MDM beheer in plaats van traditionele AD. Er is een goede ontwikkeling gaande met beheerde containers, zowel op mobiel gebied (Android Enterprise bijv.) en Windows 10 Work container. Waarbij je de werk-zaken kan compartmentaliseren en de rest van het apparaat redelijk vrij kan houden, op wat antivirus e.d. na. Op dit moment is het nog de uitzondering (alleen voor de mensen die per se BYOD willen of een Mac nodig hebben voor hun werk), maar er is ontzettend veel vraag naar, steeds meer roep om dit voor iedereen mogelijk te maken. Ook vereist het een andere denkwijze op netwerkgebied (beschouw je interne netwerk niet langer als 100% veilig, dus alles op TLS, alles achter SSO enz). Maar dat is sowieso een goede ontwikkeling voor de veiligheid.

Niet dat we microsoft-af gaan hoor, want voor Windows 10 is inTune (en Azure AD) toch wel de manier waar je dan op uitkomt. Voor andere platformen zijn andere opties momenteel wel beter. Maar het zou me niet verbazen als de ouderwetse AD over 5 jaar helemaal op zijn retour is.

[Reactie gewijzigd door GekkePrutser op 13 maart 2018 17:19]

en welk nadeel lost je op met je mdm oplossing ?

"Mensen willen geen strakke IT afdeling meer die ze vertelt wat ze moeten gebruiken. En willen niet meer met twee laptops lopen."

En hoe ga je de eindgebruikers dan helpen ? of laat je ze dan helemaal aan hun lot over ? Moeten ze maar naar de computerwinkel om de hoek en in de tussentijd zijn ze niet meer productief. Wat doe je met policies die in de tussentijd veranderen ? bv geen ios 9 devices meer maar alleen 10 and up ? Dan moet de eindgebruiker ook maar een nieuw device kopen ? Spectre , Meltdown allemaal het probleem van de eindgebruiker ?

ik geloof absoluut niet in BYOD , dit is gewoon eindgebruikers pesten omwille van "mogelijke" kostenbesparing.

[Reactie gewijzigd door klakkie.57th op 13 maart 2018 17:07]

Op zich behandel je met een optionele BYOD je werknemers als volwassen intelligente mensen: de mensen die voor BYOD kiezen, wegen de productiviteitswinst van zelf problemen (sneller) oplossen dan de IT support op tegen de winst van het outsourcen ervan naar de IT afdeling, en de (onvermijdelijke) langere responstijd.

Mensen met weinig IT skills, die kiezen voor bedrijfs laptops/telefoons, beheerd en supported door je eigen IT afdeling.

Een verplichte BYOD policy waar je als IT afdeling de puinhoop die IT-leken ervan maken moet gaan supporten, dat is het slechtste van 2 werelden.

[Reactie gewijzigd door Dreamvoid op 13 maart 2018 17:20]

Nu werk ik al 20j als SystemsAdmin en er zijn 2 dingen die ik echt nog nooit heb meegemaakt.

1. Eindgebruikers die volwassen omgaan met hun device
2. Eindgebruikers die eens je ze wat meer "macht" geeft over hun device dit niet gaan misbruiken.

Ik heb letterlijk al duizenden gebruikers zien komen en gaan en allemaal zijn ze in staat om binnen de 5 minuten spotify, itunes of wat dan ook op hun toestel te installeren, hoewe lde bedrijifspolicy uitdrukkelijk iedere vorm van installatie of manipulatie verbiedt.
Da's best knap als je de app store uitschakelt :)
Alsof je op macos, ios, windows 7,8,10 android en linux enkel apps kan installeren via de store en wat is dsn nog de meerwaarde voor de eindgebruiker als hij dan toch niet de laatste versie van AngryBirds kan installeren

[Reactie gewijzigd door klakkie.57th op 13 maart 2018 18:52]

hoewe lde bedrijifspolicy uitdrukkelijk iedere vorm van installatie of manipulatie verbiedt.
Dat is dan ook het probleem.. Mensen accepteren niet meer dat je alles verbiedt.

Kijk, als je bij de AIVD werkt dan kan ik me er nog wat bij voorstellen. Payroll medewerkers wellicht.. Maar waarom zou iemand niet naar een paar liedjes mogen luisteren tijdens het werk?

Als je je medewerkers als kleuters gaat behandelen en alles verbieden, dan geef je aan dat je ze ook geen enkele verantwoordelijkheid binnen het security proces toevertrouwt. Dan zie je ze puur als vijand en niet als medespeler. Ook wel logisch dan dat ze de grenzen gaan verkennen.

Dus, als ze door al die beperkingen hun werk niet kunnen doen, dan gaan ze van alles en nog wat verzinnen om er omheen te komen. Iedereen kent wel die handige harry van financien die weet hoe je toch je foto's van het bedrijfsuitje op de USB stick kan krijgen. Vervolgens weet iedereen het trucje en slingeren overal sticks rond. Uiteindelijk ben je op security gebied alleen maar slechter uit want dan heb je er helemaal geen controle meer over.

Ik snap wel dat het van hogerhand moet, maar ik zie bij ons in elk geval juist vanaf de hogere lagen steeds meer druk op een 'common sense' security beleid.

[Reactie gewijzigd door GekkePrutser op 13 maart 2018 22:49]

Nergens zeg ik toch ,dat ze de tools niet krijgen om hun werk te doen ? In tegendeel we voorzien in alles, laptop , iphone, internet abonnement .... etc etc, maar dan wel enkel om hun werk te doen.

Als je een contract ondertekent moet je, je eraan houden. Een beetje het probleem van deze tijd, iedereen denkt dat ze expert zijn in alles en het beter weten.

Als ik dan voor de zoveelste keer lees dat één of ander bedrijf weer gegevens verloren heeft .... tja

Ik zou zeggen laten we het eens zijn om het oneens te zijn.

[Reactie gewijzigd door klakkie.57th op 13 maart 2018 23:40]

Ik denk dat zijn punt is dat het werk van nu niet het werk van morgen is. Er is opeens een conferentie waar beeldmateriaal aan moet worden geleverd, of er is een nieuwe klant die toch heel koppig een factuur in een oude versie van word wil ontvangen of noem maar wat geks op.

De baas zit maar in je nek te hijgen want die dingen komen nooit ruim van te voren maar enkel als een verrassing voor de mensen die het uit mogen voeren, IT zet je in de wachtrij als je snel hulp nodig hebt (want iedereen heeft snel hulp nodig) en ga zo maar door. Als het helemaal mee zit heb je een IT afdeling met strenge regeltjes waar voor elke IT-gerelateerde uitzondering eerst moet worden overlegd met je baas oid.

Je wilt alleen maar je werk doen, en Harry van Financien helpt je om jezelf te helpen. En achteraf komt IT maar klagen over die verschrikkelijke gebruikers.

Ik snap helemaal waar het oogpunt van de ITer vandaan komt, maar ik snap de gebruikers ook. IT heeft vaak niet de manschappen die het nodig heeft om geweldig te functioneren, en medewerkers mogen van de baas vaak in andere rollen bijspringen en functioneren die ze oorspronkelijk misschien niet geacht worden te doen.
Bij ons heeft het niks te maken met kostenbesparing. Gebruikers vragen zich steeds luider af waarom ze alleen hun documentjes mogen typen op 'gezegende' apparaten. We komen vanuit een heel traditionele IT omgeving en sinds we naar O365 zijn gegaan zijn mensen enorm blij met de webmail, office online enz. De roep om meer wordt steeds sterker. Wat we nu proberen te doen is de meest flexibele werkomgeving aanbieden die nog de vereiste security omgeving kan bieden. Dit in combinatie met een verplaatsing van de nadruk van je security op het apparaat en meer richting het netwerk. Interne sites met alleen http of zonder authenticatie (SSO natuurlijk) moeten verdwijnen.

Als iemand een apparaat heeft dat niet op iOS 10 kan, is het al heel erg oud (het meest recente apparaat is de iPhone 4S uit 2012), en natuurlijk houden we hier rekening mee. Het is een andere denkwijze. Hele oude Android apparaten mogen bijvoorbeeld niet op de wifi (en geroote al helemaal niet).

Op dit moment hebben we BYOD alleen puur optioneel en dat zal ook nooit anders worden; wie een laptop nodig heeft, krijgt er een. Alleen wat we eventueel gaan doen is die reserveren, niet verplichten. Het zal ook nooit iets voor iedereen worden. Maar als een gebruiker beter kan werken op zijn manier, willen we dat niet tegen gaan houden.

Wat MDM toevoegt is het volgende:
  • Kunnen bepalen van policies op apparaten van verschillende typen (mobiel, desktop, zelfs chromebooks en presentatieschermen)
  • Geen afhankelijkheid van aanwezigheid op het lokale netwerk of VPN
  • Restricties instellen op app basis in plaats van apparaat basis (dus bij verlies/vertrek niet de hele telefoon wipen maar alleen de bedrijfsapplicaties en geassocieerde data)
Kijk naar een jaar of 10 geleden, toen hadden heel veel mensen een desktop. Als ze een laptop hadden dan was het een log bakbeest. 5 jaar geleden had iedereen een (chunky 14") laptop en blackberry. Nu loopt iedereen met een ultrabook en wat voor mobiel apparaat ze maar willen. BYOD zien we vooral in veel landen waar de standaard telefoon weinig soeps is (Samsung J3 bijvoorbeeld :P). Maar de reacties zijn erg positief, mensen kopen steeds vaker een dual-sim om niet met 2 smartphones op zak te hoeven lopen.

Ik weet zeker dat over 5 jaar het landschap op kantoor er weer heel anders uit gaat zien en gezien bovenstaande punten denk ik niet dat traditionele on-site AD daar nog een belangrijke rol in gaat spelen.

[Reactie gewijzigd door GekkePrutser op 13 maart 2018 17:46]

Maar je installeert toch een MDM wat is dan het verschil ?
Je zal dat device toch ook moeten encrypten ook al staat er een MDM oplossing op, toch ?
Wat is dan de "extra" flexibiliteit die een eindgebruiker krijgt?
Of laten jullie toe dat de O365 omgeving ook toegankelijk is bv vanaf een home-pc, internet-café ?

Ik ben altijd benieuwd hoe anderen het doen, al ben ikzelf vanhet principe "schroef alles toe tot de laatste punt en comma" :)


je moest ééns weten watvoor storm er hier opstak toen we ipad 1 en 2 niet meer ondersteunden en strong password hebben aangezet op devices zoinder fingerprint.

[Reactie gewijzigd door klakkie.57th op 13 maart 2018 18:01]

Het verschil heb ik daarboven aangegeven; een MDM is flexibeler, ondersteunt meer OSen en werkt ook buiten je bedrijfsomgeving. Aangezien steeds meer mensen thuis werken en niet de moeite nemen om de VPN te gebruiken omdat het meeste bij ons toch vanaf internet toegankelijk is, is de bereikbaarheid van AD echt een probleem.

Ja, op dit moment is de O365 ook van buiten toegankelijk, inclusief email. We hebben wel 2FA.

Wij hadden ook alfanumerieke paswoorden op alle mobiele apparaten en zijn daar juist van teruggekomen; bij encryptie is het aantal pogingen toch beperkt dus een numerieke code van 6 cijfers is voldoende. En encryptie is redelijk pijnloos tegenwoordig, de gebruiker merkt niet eens meer of het aan staat.

Beveiliging is altijd een compromis, en het is wat mij betreft belangrijk om te zorgen dat je de gebruiker niet te veel in de weg zit. Want dan gaan ze vanzelf manieren zoeken om er omheen te komen, en daar krijg je dat geklooi met rondslingerende USB sticks mee. Als je een goed beveiligde omgeving aanbiedt die makkelijk werkt en niet te veel beperkingen heeft, wordt er ook veel minder omheen gewerkt.

Zie ook Spotify die het downloaden van muziek enorm heeft verminderd, niet door goedkoper te zijn maar wel makkelijker :)

[Reactie gewijzigd door GekkePrutser op 13 maart 2018 19:01]

Ook duidelijk.
Dit soort policy komt erbij ons “nog” niet in. Wij hebben zelfs verplicht vpn-connected policy.

Usb gebruiken is sowieso no-go, klanten eisen zelfs dat deze afgesloten worden.

[Reactie gewijzigd door klakkie.57th op 13 maart 2018 19:07]

Het is ook een mooie kostenbesparing voor de IT afdeling: BYOD = SYOP (Solve Your Own Problems)

[Reactie gewijzigd door Dreamvoid op 13 maart 2018 15:58]

Dan doe je het niet goed. Je kan daar niet alles mee afschuiven. Als je officieel BYOD gaat aanbieden, dan moet je ze ook ondersteunen. Dat maakt het voor de support juist alleen maar lastiger. Je kan mensen immers niet in een situatie laten zitten waarin ze hun werk niet kunnen doen. Je moet bijvoorbeeld ook werklaptops op de plank hebben liggen voor als iemand zijn prive laptop stuk laat vallen en opeens niet op BYOD kan blijven. Op dit moment bestellen we puur wat we nodig hebben en dat werkt dan niet.

Natuurlijk is het een kostenbesparing op de aanschaf en dat staat er weer tegenover. Wij kijken vooral naar BYOD omdat we veel externen hebben zoals consultants die een laptop van hun werk krijgen en er dan vanwege de beveiliging ook nog een van ons mee moeten sjouwen. Dat werkt gewoon niet. Al die dingen aan AD hangen kan niet omdat ze al AD hebben van hun eigen bedrijf.

Maar kijk naar BYOD op mobiel gebied, een paar jaar geleden was dat not done en nu zit iedereen lekker op zijn eigen iPad Pro of wat dan ook te werken. Die wens wordt steeds sterker en het werkt gewoon prima. Voor mensen met lichte office taken is het zelfs al gauw voldoende, al hebben we nog niemand die er volledig op werkt.

Ook is het belangrijk om de wens van gebruikers mee te nemen dat als ze een laptop krijgen, ze die ook voor privedoeleinden kunnen gebruiken. Eigenlijk een soort omgekeerde BYOD. Doen ze met hun telefoon immers ook. In dat opzicht verandert het landschap ook erg.

[Reactie gewijzigd door GekkePrutser op 13 maart 2018 17:18]

Dan gebruik je ook geen Intel processoren meer?
Met als verschil dat er voor Samba al alternatieven zijn (ook met hun eigen voor- en nadelen). En als er in de toekomst hardware beschikbaar komt die niet onderhevig is an meltdown en spectre zullen we zeker en vast op termijn de apparatuur vervangen.
Het lastige is dat de concurrerende processoren ook kwetsbaar waren, van ARM tot AMD, van POWER tot SPARC.
SPARC niet ;) Maar inderdaad dat maakt je punt niet minder valide.
SPARC wel degelijk, Oracle heeft inmiddels Solaris gepatched.

https://www.theregister.c...arterly_patches_jan_2018/

[Reactie gewijzigd door Dreamvoid op 14 maart 2018 01:26]

Oh ja inderdaad!

In het begin werd juist gezegd dat SPARC als een van de weinigen niet kwetsbaar was. Itanium trouwens ook niet.
Dit is toch wel redelijk erg :

"Het risico van het lek is dat een aanvaller mogelijk toegang kan verkrijgen tot een account met hogere rechten door het wachtwoord ervan te wijzigen."
Wellicht een noob-vraag:

Wat is een active directory, en hebben mensen die met Ubuntu of Debian simpelweg een directory "delen" met Samba hier ook mee te maken?
Holy crap ... ik zou je vraag even googelen als ik jou was ;-) N00ber dan dit kan inderdaad niet :p

[Reactie gewijzigd door Thanis op 14 maart 2018 07:43]

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS HTC U12+ dual sim LG W7 Google Pixel 3 XL OnePlus 6 Battlefield V Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True