Een nuttig security-idee zit soms verstopt in een saaie instelling. In een thread uit 2021 wees Nathan McNulty erop dat je voor een persoonlijk Microsoft-account een aparte alias kunt gebruiken om in te loggen, terwijl je het publieke adres dat iedereen al kent uitschakelt voor sign-in. Meer dan vijf jaar later is dat nog altijd relevant. MFA-fatigue, moderne phishing en sessiediefstal hebben gebruikersnamen niet minder belangrijk gemaakt.

De meeste gesprekken over accountbeveiliging springen meteen naar wachtwoorden en MFA. Terecht. Maar een aanvaller heeft ook een geldige gebruikersnaam nodig. Als je publieke e-mailadres tegelijk de loginnaam is van een gevoelige Microsoft-identiteit, heb je hun eerste stap al makkelijker gemaakt. En als je een aparte sign-in alias maakt, is het beter dat die willekeurig en niet makkelijk te raden is, zonder duidelijke link met je naam, bedrijf of publieke merk.

De les aan de kant van persoonlijke accounts

De praktische klikroute werd helder samengevat in Nathan McNulty over Microsoft-accountaliassen, voortbouwend op de oorspronkelijke opmerking van Mat Velloso. Microsoft zelf beschrijft de basis in Microsoft account aliases: voeg een alias toe, maak die indien nodig primair en beperk sign-in tot die aparte alias.

Deze eerste helft gaat over persoonlijke Microsoft-accounts en andere identiteiten die erg publiek zijn. Dit is geen patroon voor Entra-werkidentiteiten.

Zo stel je het in

Als je dit op een persoonlijk Microsoft-account wilt doen, is de flow kort. De exacte labels zullen wat verschuiven in de tijd, maar het pad blijft doorgaans hetzelfde.

Het doel is niet om je publieke adres van het account te halen. Het doel is om te stoppen met dat publieke adres als geldige login te accepteren.

1. Start op Your info

Open je Microsoft-account, ga naar Your info en gebruik in het blok Account info de link Sign-in preferences.

Microsoft account Your info-pagina met de link Sign-in preferences in de sectie Account info.
Het startpunt zit in het blok Account info op de pagina Your info.

2. Controleer welke alias nu primair is

De pagina Manage how you sign in to your account toont de huidige primaire alias en geeft je de optie Add email. Hier controleer je ook welke alias vandaag primair staat.

Microsoft Manage how you sign in to your account-pagina met de huidige primaire alias en de link Add email.
Controleer eerst welke alias vandaag als primaire gebruikersnaam geldt.

3. Voeg een aparte sign-in alias toe

Gebruik Add email om een nieuw adres aan te maken. Houd dat adres stil, maak het bij voorkeur redelijk willekeurig, en gebruik het niet op websites, in handtekeningen of in contactlijsten.

Pagina Add a username om een nieuw adres aan te maken en als Microsoft-username toe te voegen.
De nieuwe alias is bedoeld voor sign-in, niet voor publieke communicatie.

4. Laat alleen die alias nog aanmelden

Ga terug naar Sign-in preferences, laat de aparte alias aangevinkt voor sign-in en schakel sign-in met het publieke adres uit. Controleer op die pagina ook alle andere nog toegelaten sign-in-identifiers, inclusief oude aliassen of een telefoonnummer. Als een van die identifiers publiek of makkelijk te raden is, hoort die niet langer als login te werken. Je publieke adres mag aan het account gekoppeld blijven als je het nog nodig hebt voor mail. Het zou alleen geen geldige login meer mogen zijn.

Pagina Sign-in preferences met de primaire alias aangevinkt en een andere alias uitgevinkt voor sign-in.
De gewenste eindsituatie is eenvoudig: het adres dat publiek blijft, werkt niet langer als login.

Dat vervangt MFA of een password manager niet. Het haalt vooral onnodige blootstelling weg. Publieke adressen staan op websites, in handtekeningen, presentaties, leverancierslijsten en gelekte datasets. Als exact dezelfde string ook de gebruikersnaam is, hoeft een aanvaller niets meer te raden.

Geprivilegieerde accounts in de onderneming beschermen

Hier stopt de parallel. Het vorige deel ging over het verkleinen van de blootstelling van een loginnaam op een persoonlijk of publiek Microsoft-account. Het beschermen van geprivilegieerde enterprise-accounts is een ander probleem: niet het verbergen van een gebruikersnaam, maar het beheersen van de toegangspaden die naar administratieve macht leiden.

Net daarom is het Microsoft enterprise access model nuttig. Microsoft beschrijft daar minstens een control plane, een management plane en een data/workload plane. Wie een hoger vlak controleert, kan in de praktijk de lagere vlakken mee sturen. Daarom verdienen geprivilegieerde toegangspaden een ander beschermingsniveau dan gewone user access.

Ook de privileged access strategy vertrekt daarvan: er is geen enkele maatregel die privileged access oplost. Je moet het volledige pad beschermen tussen account, device, rol, eventuele tussenlaag en het gevoelige systeem zelf.

Executives en executive assistants kunnen nog altijd high-value identities zijn, zeker als ze approvals, delegaties of gevoelige informatie concentreren. Maar dat is niet automatisch hetzelfde als een Entra-adminaccount, een control-plane-rol of een account dat recoverypaden kan wijzigen. Die groepen overlappen soms. Je beschermt ze niet op exact dezelfde manier.

Wat dat concreet betekent voor privileged accounts

Het geloofwaardige minimum blijft klassiek, maar het moet consequent afgedwongen worden. Microsoft raadt in Active Directory accountsaan om adminaccounts van gewone gebruikersaccounts te scheiden. In de praktijk betekent dat geen dagelijkse mailbox, geen vrije browser en geen gewone productiviteitstaken op het adminaccount.

Minstens even belangrijk is dat een zware rol niet permanent actief blijft als ze maar af en toe nodig is. Microsoft Entra Privileged Identity Management (PIM) geeft daar het praktische mechanisme voor: maak de rol eligible, laat activatie verplicht zijn, en voeg de passende remmen toe zoals MFA, approval, een motivatie en een korte activatieduur. Dat is JIT in bruikbare vorm. Niet alleen minder admins, maar minder permanent privilege.

Die accounts moeten ook op schone admin-devices landen. Microsoft documenteert expliciet het afdwingen van conforme of hybrid joined devices in Require compliant device or Microsoft Entra hybrid joined device for administrators. Met Filters for devices in Conditional Accesskun je nog verder gaan en alleen een gesloten groep admin-devices toelaten.

Voor Entra-adminrollen stuurt Microsoft ook aan op phishing-resistant MFA in Require phishing-resistant multifactor authentication for Microsoft Entra administrator roles. Dat detail telt, omdat een adminaccount op een proper device nog altijd interessant blijft als het vatbaar is voor phishing of sessiediefstal.

In directietaal komt het neer op vier eisen: apart adminaccount, apart admindevice, sterke phishing-resistente authenticatie en expliciet beheer van emergency of break-glass accounts. Minder elegant dan een alias-truc, maar precies het verschil tussen een gevoelig account en een verdedigbaar privileged path.

En als je nog on-prem AD hebt

In hybride omgevingen zijn Authentication Policies and Authentication Policy Silos nog altijd nuttig om een eenvoudige vraag af te dwingen: waar mag dit account in de praktijk nog authenticeren? Als privileged paths nog on-prem lopen, moet je ze ook daar sluiten.

Een belangrijke nuance: dit is geen onschuldig AD-label. Het is een controle die leunt op Kerberos-gedrag en vaak samenloopt met protected accounts. Als adminflows nog steunen op NTLM, op standaard credential delegation of op legacy-aannames in services en werkstations, dan gaat een deel daarvan breken. Dat is net waarom je audit eerst nodig hebt voor je enforcement aanzet.

In de praktijk betekent dat een aparte silo voor je hoogste privilege-accounts, met alleen de relevante admins, de geharde adminwerkstations en eventueel de serviceaccounts die echt in dat pad thuishoren. Daarna definieer je vanaf welke devices en naar welke systemen die accounts nog Kerberos-authenticatie mogen krijgen. Voor identity- of control-plane-accounts hoort die lijst meestal beperkt te blijven tot adminwerkstations, jump hosts en een kleine set domeincontrollers of beheerservers.

Microsoft voorziet ook een auditmodus voor enforcement. Die volgorde is belangrijk. Kijk eerst welke bestaande flows zouden breken, herstel die, en schakel daarna enforcement in. Anders blijft de silo een nette AD-configuratie zonder echte grens op het gebruik van privileged credentials.

Wat je hierna kunt doen

  • Als je een persoonlijk Microsoft-account of een erg publiek account beheert, haal dan je publieke e-mailadres weg uit de toegelaten login-identifiers en vervang het door een discrete, liefst vrij willekeurige alias.
  • Als je privileged accounts aanstuurt, controleer dan of de basis er echt staat: een apart adminaccount, een apart admindevice, phishing-resistant MFA en just-in-time activatie via PIM.
  • Als je omgeving nog hybride is, laat dan expliciet uitzoeken waar die credentials vandaag nog mogen authenticeren. Daar blijven oude paden vaak langer open dan iemand denkt.
  • En als niemand je daar een helder antwoord op kan geven, is dat op zich al een nuttige uitkomst. Meestal betekent het dat eigenaarschap, prioriteit of echte afdwinging nog ontbreekt.

Het doel is niet om alles onder het label "belangrijke identiteiten" te schuiven. Het doel is net om twee onderwerpen helder te scheiden. Voor een persoonlijk of erg publiek account wil je de blootstelling van de login verminderen. Voor een privileged enterprise-account wil je een toegangspad met grote impact beschermen.

Als je wilt toetsen of gevoelige identiteiten in jouw omgeving echt gescheiden, beperkt en verdedigbaar zijn, contact op te nemen.