Onlangs schreef Jethro Seghers, een Belgische Office 365 MVP een artikeltje met de titel How to allow DirSync to synchronize a .local domain without a domain rename. De schrijver stipt een belangrijk aspect aan waar veel mensen mee te maken krijgen bij een Office 365 implementatie. Alleen ontbreekt in het artikel een stukje context en is de term ‘domain rename’ wat ongelukkig gekozen. Met deze blogpost wil ik uitleggen wat het issue werkelijk is en waarom een domain rename hier eigenlijk niets mee te maken heeft.
Wat is een UPN eigenlijk?
De User Principal Name (UPN) is een Active Directory attribuut in de vorm van een e-mailadres. De waarde voor userPrincipalName hoeft niet altijd gevuld te zijn, het is gewoon een eigenschap van het object zoals ook de cn, name, distinguishedName, en objectGUID attributen dat zijn.
Een UPN bestaat uit een prefix en een suffix, beide delen worden gescheiden door een apenstaartje (@). De UPN wordt ook wel eens internetstijl inlognaam genoemd omdat deze lijkt op een e-mailadres.
In Office 365 wordt de UPN gebruikt om mee aan te melden, dus niet een vorm zoals bijvoorbeeld domein\gebruiker.
Belangrijk om te weten is dat gebruikers een expliciete en een impliciete UPN hebben. Om met die laatste te beginnen, een gebruiker kan altijd aanloggen met zijn impliciete UPN: UserName@dnsdomainname. Dus ook als het userPrincipalName attribuut niet gevuld is.
Een expliciete UPN is een extra UPN die je zelf in kunt stellen door het userPrincipalName attribuut te vullen. Hierbij kun je zowel de prefix als de suffix zelf bepalen. Laten we eens naar een voorbeeld kijken:
De impliciete UPN van deze gebruiker is dus Henk@lab1.local en de gebruiker kan hiermee op een AD werkplek aanmelden. Vervolgens stellen we een expliciete UPN in, in het veld userPrincipalName overschrijven we Henk@lab1.local met fiets@banaan:
Met deze extra UPN kan de gebruiker nu dus ook aanloggen:
Ik heb in dit voorbeeld bewust gekozen voor een rare UPN Suffix. We zijn dus niet beperkt tot eventuele extra suffixes die we in het domein aan kunnen maken volgens: HOW TO: Add UPN Suffixes to a Forest. De suffixes die we hier toevoegen verschijnen vervolgens in de drop-down list in Active Directory Users and Computers (ADUC):
Wat heeft DirSync daar mee te maken?
DirSync is de gratis FIM 2010 implementatie die Office 365 klanten mogen gebruiken om hun AD-objecten naar Windows Azure AD te synchroniseren. Voordat je deze inschakelt moeten de te synchroniseren AD objecten aan een aantal eisen voldoen. Zo mogen er bijvoorbeeld geen ongeldige karakters in de AD velden staan en moet de UPN aan het volgende voldoen:
Your Active Directory environment must be properly configured in order for your users to sign-in to Microsoft online services. In particular, the userPrincipalName (UPN) attribute, also known as a user logon name, must be set up correctly for each user in a specific way. The UserPrincipalName attribute must use a publically routable domain. If you are not currently using a publically routable domain, you will need to update your users UserPrincipalNames. To do this, add an alternative UPN suffix in your on-premises Active Directory.
Zo kunnen we lezen in Prepare for directory synchronization. De reden hiervoor is dat je gebruikers met hun UPN moeten aanmelden bij de Office 365 diensten, aan de hand van de UPN suffix wil Microsoft dan kunnen bepalen of je een ook een wachtwoord in moet geven of dat je organisatie gefedereerd is en er een redirect naar een ADFS-server moet worden gegeven.
Wat nu als mijn UPN niet voldoet?
Zo komen we weer bij het probleem uit het artikel wat ik eerder aanhaalde. Wat nu als mijn DNS domein naam op .local eindigt? Dan voldoet de impliciete UPN dus niet aan de eisen omdat deze eindigt op @domain.local. Dan voegen we daar dus een expliciete UPN aan toe die wel een ‘publically routable name’ heeft. Dan kan dus door een suffix toe te voegen aan ADUC en deze per gebruiker te kiezen, door het userPrincipalName attribuut voor iedere gebruiker te bewerken met ADSIEdit of ADUC of natuurlijk scriptmatig.
Er zijn een aantal mogelijkheden om dit te doen, bijvoorbeeld met de native Server 2012 AD cmdlets:
Get-ADUser -Filter { UserPrincipalName -like "*@lab1.local"} |
ForEach-Object {
$UPN = $_.UserPrincipalName.Replace("lab1.local","office365lab.com")
Set-ADUser $_ -UserPrincipalName $UPN
}
Welke UPN deel ik uit?
Goed, we hebben aan gebruiker Henk nu uitgelegd dat hij mag inloggen met henk@office365lab.com want dat is zijn username met de nieuwe UPN suffix. Maar Henk had ook al een mailadres die daar op lijkt: h.steen@office365lab.com. Als we dan toch een nieuwe UPN moeten geven aan de gebruikers, zou het dan niet handig zijn om die gelijk te maken aan het primaire SMTP adres? Het is voor gebruikers namelijk makkelijker te onthouden dat ze bij Office 365 in kunnen loggen met hun mailadres.
Een script om dit uit te voeren zou er zo uit kunnen zien:
Get-ADUser -Filter { UserPrincipalName -like "*@lab1.local" } -Properties mail |
ForEach-Object {
Set-ADUser $_ -UserPrincipalName $_.mail
}
En wat als ik te laat was?
Als de UPN niet aan de eisen voldoet wordt het object wel gesynchroniseerd maar krijgt hij een UPN in je Office 365 standaard domein: tenant.onmicrosoft.com. Daar kunnen we niet mee inloggen dus dit moet veranderd worden in de juiste UPN.
Hiervoor gebruiken we de Windows Azure AD PowerShell cmdlets: Windows PowerShell-cmdlets gebruiken om uw Windows Azure AD-tenant te beheren Eenmaal verbonden kunnen we de UPN opnieuw instellen met het Set-MsolUserPrincipalName cmdlet. Bijvoorbeeld:
Get-MsolUser henk@lab1.local | Set-MsolUserPrincipalName –NewUserPrincipalName henk@office365lab.com
Tenslotte
Als we op deze manier naar de UPN kijken dan is duidelijk dat het hernoemen van je domein nooit een optie geweest is, dat is dus ook niet het probleem wat we op hoeven te lossen. Wel kan het zijn dat je pas later in het proces tegen dit onderwerp aanloopt en hierdoor verrast wordt. Dit kun je voorkomen door je implementatie te plannen en uit te voeren aan de hand van de documentatie op TechNet:
Inmiddels heb ik de auteur van het artikeltje via Twitter gesproken, hij heeft de naam van het artikel al aangepast en de term ‘without a domain rename’ laten vervallen. Bovenstaand artikel is hiermee gelijk wat minder relevant geworden maar ik hoop dat het alsnog wat bijdraagt.
In 2006, ISA was inmiddels volwassen en werd opgevolgd door de net iets verbeterde ISA 2006, kocht Microsoft Whale Communications. Niet lang daarna kwam Intelligent Application Gateway (IAG) 2007 op de markt. In 2010 werd de tweede versie sinds de overname door MS uitgebracht, nu hernoemd naar Unified Access Gateway (UAG) 2010 en onderdeel van de nieuwe security-reeks Forefront. UAG was niet slecht, veel mogelijkheden om met trunks en portals allerlei applicaties te publiceren met legio mogelijkheden voor authenticatie en SSO. Het systeem met include-files maakte het kinderspel om functionaliteit aan te passen of zelfs toe te voegen.
