In dit artikel wordt uitgelegd hoe eADM de User Principal Name (UPN), het primaire SMTP-adres en e-mailaliassen toewijst, en hoe de inrichting van mailboxen verschilt tussen lokale Active Directory-, hybride (externe mailbox) en uitsluitend cloudgebaseerde accountmodellen.
Houd er rekening mee dat dit artikel zeer algemeen van aard is, aangezien de precieze regels voor het aanmaken van mailboxen per klant verschillen!
Hoe eADM de UPN en het primaire SMTP-adres toewijst
eADM stelt de userPrincipalName (UPN) en het primaire SMTP-adres bij het aanmaken van het account, op basis van de regels die in het synchronisatiesjabloon zijn geconfigureerd. Deze regels maken doorgaans gebruik van organisatorische gegevens zoals naam, afdeling en functiecode.
Doorgaans hanteert eADM het principe van één account en één wachtwoord. Eén medewerker heeft één account en één wachtwoord voor zowel de lokale Active Directory, Entra ID als Google Workspace. De UPN en het primaire SMTP-adres kunnen worden ingesteld op basis van de werkplek van de medewerker. Als een medewerker van functie verandert, bijvoorbeeld van een gezondheidsdienst naar een school, kan het e-maildomein automatisch worden bijgewerkt en blijft het vorige adres behouden als alias.
Gebruikers met meerdere werkgevers en meerdere functies
In een eADM-tenant met meerdere organisaties worden de functiegegevens van een medewerker die functies bekleedt bij verschillende organisaties of afdelingen, uit elk actief dienstverband geïmporteerd en aan elkaar gekoppeld. Het nationale identiteitsnummer koppelt de records uit de verschillende bronsystemen aan elkaar. Toegangsrechten zijn cumulatief: de gebruiker krijgt de som van de toegangsrechten van alle actieve functies.
De UPN en de primaire SMTP worden bepaald op basis van de hoofdfunctie van de medewerker, bijvoorbeeld de functie met het hoogste percentage of de langste anciënniteit. Dit kan per klant worden geconfigureerd. Als een van de dienstverbanden wordt beëindigd, wordt alleen de toegang die aan die specifieke functie is gekoppeld, ingetrokken. Voor de andere dienstverbanden kunnen e-mailaliassen worden aangemaakt.
Accountmodellen: lokaal, op afstand en uitsluitend in de cloud
eADM ondersteunt verschillende integratieniveaus met de directorydiensten van Microsoft, variërend van een volledig on-premises opstelling tot een volledig cloudgebaseerde tenant zonder lokale Active Directory:
|
Model |
Waar accounts en mailboxen zich bevinden |
Hoe eADM de mailbox inricht |
|---|---|---|
|
Lokaal |
Active Directory op locatie, met Exchange eveneens op locatie |
eADM schrijft gebruikersattributen rechtstreeks naar Active Directory. De lokale Exchange-server beheert de mailbox. |
|
Op afstand (hybride) |
Active Directory op eigen server als bron; mailbox gehost in Exchange Online |
eADM schrijft gegevens naar Active Directory en voert, indien geconfigureerd, een PowerShell-script uit op de lokale Exchange-server (of via Exchange Management Tools) om een postbusobject op afstand aan te maken dat de AD-gebruiker koppelt aan de cloudpostbus. |
|
Alleen in de cloud |
Alleen Microsoft Entra ID, geen lokale Active Directory |
eADM beheert de gebruiker rechtstreeks in Entra ID via Microsoft Graph. Er wordt automatisch een mailbox aangemaakt wanneer een geschikte Exchange Online-licentie wordt toegewezen. |
Lokaal: Active Directory en Exchange op eigen locatie
eADM schrijft wijzigingen rechtstreeks naar de lokale Active Directory. De bestaande Microsoft Entra Connect Sync neemt vervolgens de wijzigingen in gebruikers, groepen en attributen over en synchroniseert deze met Entra ID.
Op afstand: hybride Exchange met een externe mailbox
In een hybride omgeving beheert eADM Exchange niet rechtstreeks. In plaats daarvan schrijft het de juiste attributen naar het Active Directory-gebruikersobject en voert het, indien geconfigureerd, een PowerShell-script uit op de on-premises Exchange-server (meestal Enable-RemoteMailbox.ps1), of via de Exchange-beheertools als er geen lokale Exchange-server meer aanwezig is. Hierdoor wordt een mailboxobject op afstand aangemaakt dat de AD-gebruiker koppelt aan de mailbox in Microsoft 365 en zorgt voor een correcte e-mailroutering.
Opmerking: Identum houdt zich niet bezig met het beheer, de configuratie of het oplossen van problemen met de Exchange-server zelf. Wijzigingen aan de Exchange-infrastructuur, waaronder installatie, migratie en certificaatbeheer, vallen onder de verantwoordelijkheid van de IT-afdeling of de Exchange-beheerder van de klant.
Alleen in de cloud: Entra ID en Exchange Online
In een ‘cloud-only’-tenant beheert eADM userPrincipalName en mailNickname rechtstreeks in Entra ID. De UPN is altijd het primaire e-mailadres, en Exchange Online voegt de e-mailbijnaam bij het primaire domein automatisch toe als alias zodra een licentie is toegewezen. Er is geen lokale Active Directory- of Exchange-server nodig.
Primair SMTP-adres en e-mailaliassen
In Active Directory en Exchange worden de e-mailadressen van een gebruiker opgeslagen in de proxyAddresses attribuut. Het primaire adres wordt aangeduid met een hoofdletter SMTP: voorvoegsel; aliassen moeten in kleine letters worden geschreven smtp: voorvoegsel. Per account kan er slechts één primair adres tegelijk bestaan.
eADM ondersteunt twee algemene methoden om dit kenmerk correct te houden:
-
Minimale configuratie. eADM stelt alleen de
mailattribuut in Active Directory. Microsoft Entra Connect en Exchange Online leiden daar vervolgens uit afproxyAddressesen het primaire adres automatisch, op basis van de standaardadresbeleidsregels van Microsoft. Dit is eenvoudig in te stellen, maar biedt beperkte controle over naamswijzigingen en extra aliassen. -
Adresbeheer op basis van scripts. Een PowerShell-script, dat door eADM wordt geactiveerd, berekent het primaire adres en eventuele aliassen en schrijft deze expliciet weg. Dit biedt ondersteuning voor naamswijzigingen waarbij het oude adres automatisch als alias wordt behouden, voor regels voor meerdere domeinen en voor andere klantspecifieke vereisten, maar dit gaat gepaard met extra scriptwerk en onderhoud.
De juiste aanpak hangt af van de complexiteit van de naamgevingsregels en de domeinstructuur van de klant. Identum kan tijdens de onboarding advies geven over het meest geschikte model.
Wat verandert er als je een Exchange-server vervangt?
Wanneer een organisatie haar lokale Exchange-server vervangt of upgradet, moet de hostnaam of FQDN van de nieuwe server worden bijgewerkt in het PowerShell-script dat door eADM wordt gebruikt. In de meeste standaardconfiguraties is dit de $exchange variabele bovenaan Enable-RemoteMailbox.ps1.
Afhankelijk van hoe het script oorspronkelijk is ingesteld, zijn er mogelijk nog andere verbindingsparameters die u moet controleren:
-
$exchange, de hostnaam of FQDN van de Exchange-server -
Inloggegevens van het serviceaccount die worden gebruikt om verbinding te maken met Exchange, indien de huidige Windows-sessie niet wordt gebruikt
-
Elke expliciete URI of verbindingsstring in
New-PSSessionofConnect-ExchangeServer
Waarschuwing: Werk het script niet bij in de productieomgeving zonder eerst de verbinding in de testomgeving te controleren. Een verkeerd geconfigureerd Exchange-eindpunt zorgt ervoor dat het aanmaken van mailboxen voor nieuwe gebruikers stilzwijgend mislukt, totdat het probleem is verholpen.
Hoe de verwijzing naar de Exchange-server bij te werken
-
Zoek de
Enable-RemoteMailbox.ps1script in de eADM-synchronisatieconfiguratie. -
Werk de
$exchangevervang deze variabele door de hostnaam of FQDN van de nieuwe Exchange-server. -
Controleer eventuele aanvullende verbindingsparameters (zie bovenstaande lijst).
-
Test het bijgewerkte script handmatig op de nieuwe server voordat je het opslaat in de productieconfiguratie.
-
Voer een testprovisioning uit in eADM om te controleren of de externe mailbox correct is aangemaakt.
-
Neem contact op met de ondersteuning van Identum als het script aanpassingen vereist die verder gaan dan de
$exchangevariabele, of als de huidige scriptconfiguratie onduidelijk is.
Omvang van de ondersteuning door Identum
Identum kan u bij het volgende ondersteunen wanneer de Exchange-omgeving van een klant verandert of wanneer er wordt overgestapt tussen accountmodellen:
-
Het herzien en bijwerken van de
$exchangevariabele en bijbehorende parameters in het eADM-provisioningscript -
Advies over de meest geschikte aanpak voor UPN, primair SMTP en het beheer van aliassen voor de domeinstructuur van de klant
-
De bijgewerkte configuratie testen in een sandbox-omgeving
-
Controleren of nieuwe gebruikersaccounts na een wijziging correct zijn aangemaakt
Identum houdt zich niet bezig met het beheer, de configuratie of het oplossen van problemen met de Exchange-server of de Entra ID-tenant zelf. Wijzigingen aan de infrastructuur, waaronder installatie, migratie naar een volledig cloudgebaseerde omgeving en certificaatbeheer, vallen onder de verantwoordelijkheid van de IT-afdeling van de klant of diens Exchange- of Entra ID-beheerder.
Gerelateerde artikelen
In dit artikel wordt uitgelegd hoe eADM de UPN, het primaire SMTP-adres en e-mailaliassen toewijst, en hoe de inrichting van mailboxen verschilt tussen lokale Active Directory-, hybride (externe mailbox) en uitsluitend cloudgebaseerde Entra ID-accountmodellen. Het behandelt het attribuut `proxyAddresses`, het script `Enable-RemoteMailbox.ps1` en de variabele `$exchange` die in hybride opstellingen worden gebruikt, UPN-regels voor meerdere werkgevers en de reikwijdte van de ondersteuning door Identum wanneer Exchange-servers veranderen of klanten overstappen naar een puur cloud-model. Het artikel is bedoeld voor IT- en Exchange-beheerders bij de gemeentelijke klanten van Identum.