ADFS v3 (2012R2) naar ADFS v4 (2016) Migratie – Deel 2/2
Welkom terug bij het 2e deel van onze ADFS v3 (2012R2) naar ADFS v4 (2016) Migratie. In deel 1 hebben we de feitelijke ADFS migratie voorbereid en voltooid. Nu zijn echter de WAP servers aan de beurt en moeten we het ADFS Forest Behaviour Level updaten. In deze post nemen we ook een kijkje naar verschillende best-practices en de Azure MFA integratie met ADFS. We trappen echter af met de DMZ WAP Servers. Let’s go!
Installeer WAP rollen op DMZ servers
Nu is het zaak dat de WAP servers voorzien worden van de juiste rollen. Alvorens we de WAP rollen installeren installeren we eerst het SSL certificaat. Vervolgens installeren we de rollen “Remote Access – Web Application Proxy” + “Network Load Balancer” + “RAS Connection Manager Administration Kit” + “Remote Server Administration Tools – Role Administration Tools”.
Als deze rollen geïnstalleerd zijn starten we de configuratie van de proxy server. Let op dat de poort 49997 open staat tussen ADFS en Proxy server.
Vul tijdens de configuratie de globale ADFS service naam en het service account in:
Selecteer het juiste SSL certificaat:
Start de configuratie:
Plaats de hostnamen van de ADFS servers in de host files van de proxy servers:
Tenslotte controleer je de werking van de ADFS Proxy servers in de “Remote Access” management console:
Verander in de firewall eventueel de IP adressen zodat het verkeer over de nieuwe proxy servers gerouteerd wordt en test de verbinding vanuit extern en intern.
Verwijder de oude ADFS (federatie) servers
Om de oude ADFS servers uit de farm te verwijderen moeten we deze eerst verwijderen van de load balancers.
Open een Powershell console op de oude proxy WAP servers en bekijk de huidige configuratie:
Get-WebApplicationProxyConfiguration |
Om de node uit het cluster te verwijderen gebruik je het commando:
Set-WebApplicationProxyConfiguration -ConnectedServersName ((gwpc).ConnectedServersName -ne ‘%servername%’) |
Voer bovenstaande uit voor alle oude WAP servers. Zet daarna de WAP servers uit en test of je configuratie nog werkt.
We zijn nu klaar met de WAP servers en kunnen de oude ADFS servers uit de ADFS farm te halen. Normaliter, bij een local database vereist dit geen losse actie en gebeurt op het moment dat de farm geupgrade wordt naar het nieuwe FBL (Farm Behavior Level). Op het moment dat je wel gebruik maakt van een SQL server moet je de “Active Directory Federation Services” role handmatig op alle 2012 servers verwijderen.
Let op dat je eventueel nu ook het DNS record aanpast naar de nieuwe ADFS servers (intern) zodat ook intern de SSO applicaties blijven functioneren na het verwijderen van de ADFS-role op de oude servers.
Upgrade ADFS FBL – Forest Behaviour Level + WAP Configuration Version
Momenteel is ons FBL, level 1 (2012) en we zijn nu klaar om deze te upgraden naar level 3 (2016). Om dit te doen log je in op de primary ADFS controller (met een SQL installatie maakt het niet uit op welke server omdat iedere server een primary server is). Hier start je (bij een local database) een admin Powershell en voer je het volgende commando uit:
Invoke-AdfsFarmBehaviorLevelRaise |
Bij een SQL database zijn er een paar extra stappen nodig omdat je eerst moet verbinden met de SQL server als administrator zodat je changes uit kunt voeren. Gebruik hiervoor het volgende commando en vul de gegevens in van een admin gebruiker op de SQL server:
$cred = Get-Credential |
Vervolgens voeg je het volgende commando uit om het FBL te upgraden:
Invoke-AdfsFarmBehaviorLevelRaise -Credential $cred |
Zoals je ziet vindt het commando beide ADFS servers waar het FBL level op verhoogd kan worden. De oude servers zijn nu uit de farm verwijderd en kunnen uitgeschakeld worden. Om je level te controleren kun je het volgende commando gebruiken:
Get-AdfsFarmInformation |
Als alles werkt is het tijd om het WAP configuratielevel te upgraden naar 2016. Zoals je met onderstaande commando zult zien is dit momenteel nog de 2012R2 versie.
Get-WebApplicationProxyConfiguration |
Om het level te upgraden voeren we het volgende commando uit:
Set-WebApplicationProxyConfiguration -UpgradeConfigurationVersion |
Controleer het level en of alles nog functioneert.
Overzetten Azure AD Connect Sync Tool
Mocht je de Azure AD Connect Sync tool draaien op een oude ADFS server en deze willen uitmigreren dan moet ook de Azure AD Connect tool worden omgezet. De migratie van de AAD Connect tool werkt als volgt.
1. Bekijk de configuratie van de huidige AAD Connect tool.
2. Installeer een nieuwe Azure AD Connect tool op de nieuwe server in “Staging mode”.
3. Vergelijk de configuraties van de AAD Connect tool van de oude en de nieuwe server.
4. Switch-over de synchronisatie naar de nieuwe server.
5. Migreer de oude server uit.
Om de configuratie van de huidige Azure AD Connect tool te bekijken gebruiken we de AADConnectConfigDocumenter tool. Deze kunnen we hier downloaden:
https://github.com/Microsoft/AADConnectConfigDocumenter/releases
Vervolgens loggen we in op de server waar de AAD Connect tool op geinstalleerd is en exporteren we de huidige configuratie als volgt:
Import-Module ADSync Get-ADSyncServerConfiguration -Path "%pad-waar-config-opgeslagen-wordt" |
Nu gaan we de geëxporteerde content opslaan in een subfolder van de “Data” folder van de “AADConnectConfigDocumenter” tool.
Nu pas je het batch script aan in de AADConnectConfigDocumenter tool zodat 2x de map opgegeven wordt waarin je de configuratiebestanden geplaatst hebt:
Wanneer de tool gedraaid heeft vindt je een HTML rapport in de “Report” directory:
Nu gaan we AAD Connect installeren op de nieuwe server. Dit mag een nieuwere versie zijn dan op de oude server staat. Aangeraden wordt echter om dezelfde versie te installeren. Wij proberen het meteen met de nieuwste build. Ik heb hier alle vertrouwen in.
Nadat de installatie is voltooid begint de configuratiewizard. Kies hier voor “Customize” zodat we een aantal settings kunnen kiezen. Deze settings moeten we identiek houden aan de settings van de oude server. Denk hierbij aan het service account, eventueel gebruikte SQL server, sync user, sync opties etc. Kijk deze settings af in je hiervoor gedraaide rapportage of via de interface van de oude AD Connect Sync tool.
Let erop dat je als synchronisatie gebruiker een normale gebruiker met de juiste rechten gebruikt. Het is niet (meer) toegestaan om een domain admin te gebruiken. Wil je je gebruiker voorzien van de juiste rechten kun je het volgende script uitvoeren op de synchronisatie gebruiker:
$accountName = "%domain%\%sync-user%" $ForestDN = "DC=%DOMAINNAME%,DC=%TOP-LEVEL-DOMAIN%" $cmd = "dsacls '$ForestDN' /I:S /G '`"$accountName`":WP;ms-ds-consistencyGuid;user'" Invoke-Expression $cmd |
Bij de laatste stap kies je ervoor om de “Staging Mode” te activeren:
Nu de configuratie en installatie voltooid is gaan we de configuraties vergelijken. Op de nieuwe server exporteren we ook de configuratie:
Import-Module ADSync Get-ADSyncServerConfiguration -Path "%pad-waar-config-opgeslagen-wordt" |
En ook deze plaatsen we in de data folder van de report tool (server-nieuw). Vervolgens passen we het batch bestand als volgt aan zodat we in de rapportage kunnen zien wat de verschillen zijn:
Nu bekijken we de verschillen. Pas eventueel de configuratie aan met zaken die je vergeten bent om door te voeren. Je kunt dit ook laten scripten via het “Sync Rule Changes Script”:
Als alle changes succesvol zijn doorgevoerd schakelen we staging-mode in op de oude server en schakelen we staging-mode uit op de nieuwe server.
Test of synchronisatie succesvol werkt. Maak eventueel ook nieuwe scheduled tasks en snelkoppelingen aan.
Activeren Azure MFA op ADFS 2016
Vanaf ADFS 2016 is het mogelijk om zonder separate MFA server gebruik te maken van Azure MFA. Om gebruik te maken van Azure MFA moet het account in Azure ingesteld zijn om MFA te gebruiken. Als dat zo is doorlopen we de volgende procedure om Azure MFA (met de Microsoft Authenticator) te installeren op ADFS.
Op elke ADFS server moet een certificaat aangemaakt worden. Om dit certificaat aan te maken moet je het TenantID opzoeken van je Azure Tenant. Vervolgens voer je onderstaande commando op iedere ADFS server uit:
$certbase64 = New-AdfsAzureMfaTenantCertificate -TenantID “%Tenant-ID%” |
Nu de ADFS servers over het juiste certificaat beschikken moeten we de Azure Multi-Factor Auth Client om deze als “credentials” te gebruiken voor de verbinding met ADFS.
Op een PC waar de Azure MSOL tools op geinstalleerd zijn voer je onderstaande commando uit om te verbinden met AzureAD (gebruik een global admin account):
Connect-MsolService |
Vervolgens definiëren we de GUID voor de Azure MFA client (981f26a1-7f43-403b-a875-f8b09b8cd720)
New-MsolServicePrincipalCredential -AppPrincipalId 981f26a1-7f43-403b-a875-f8b09b8cd720 -Type asymmetric -Usage verify -Value $certbase64 |
Nu gaan we de ADFS farm configureren om gebruik te maken van Azure MFA. Hiervoor gebruik je onderstaande commando op de primaire ADFS server (WID) of op een willekeurige ADFS server (SQL):
Set-AdfsAzureMfaTenant -TenantId “%Tenant-ID%” -ClientId 981f26a1-7f43-403b-a875-f8b09b8cd720 |
Vervolgens rebooten we de ADFS server:
Restart-Service adfssrv |
Zoals je kunt zien is het nu mogelijk om als primary of als secondary (tabblad Multi-Factor) Azure MFA te selecteren:
Na activatie krijgt de gebruiker om de Azure MFA inlogmethode te gebruiken:
ADFS Best Practices
Als laatste onderdeel is het tijd om een aantal ADFS Best-Practices door te voeren om de configuratie van ADFS nog beter en veiliger te maken.
1. Inschakelen “Change Password”
Standaard is het niet mogelijk om via ADFS je wachtwoord aan te passen. De optie is echter wel aanwezig en kan via GUI (ADFS – Service – Endpoints 0 Other – /adfs/portal/updatepassword/) en via Powershell aangepast worden. Dit gaat als volgt:
Enable-AdfsEndpoint "/adfs/portal/updatepassword/" Set-AdfsEndpoint "/adfs/portal/updatepassword/" -Proxy:$true |
Vervolgens resetten we ADFS op elke ADFS server in de farm:
Restart-Service AdfsSrv -Force |
Om te testen of het werkt kun je onderstaande URL gebruiken:
https://www.adfs.%domennaam%.nl/adfs/portal/updatepassword |
2. Enable WS-Trust 1.3 voor Desktop Client SSO
Om te profiteren van de nieuwe Microsoft ADAL (Active Directory Authentication Library) authenticatie mogelijkheid voor Office 2013/2016 / ProPlus moet WS-Trust 1.3 ingeschakeld worden. Na het inschakelen hebben we ook de beschikking over SSO functionaliteiten voor ADAL. Voer de volgende PowerShell-opdracht uit om het eindpunt voor WS-Trust 1.3 in te schakelen:
Enable-AdfsEndpoint -TargetAddressPath "/adfs/services/trust/13/windowstransport" |
Vervolgens resetten we ADFS op elke ADFS server in de farm:
Restart-Service AdfsSrv -Force |
Zorg er vervolgens voor dat zowel “Forms” als “Windows Authentication (WIA)” ingeschakeld is bij de authenticatie methodes:
WS-Trust endpoints zijn alleen bedoeld voor intern gebruik en niet voor extern gebruik. Daarom moeten we WS-Trust Windows v.a. het Extranet uitschakelen. Dit doen we met de volgende commando’s:
Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/2005/windowstransport -Proxy $false Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/windowstransport -Proxy $false |
3. Wachtwoord verloop meldingen in Office365
Middels een claim-rule kunnen we in Office365 de gebruiker op de hoogte stellen dat hun wachtwoord gaat verlopen zodat ze deze tijdig kunnen resetten.
De volgende regel moet toegevoegd worden.
c1:[Type == "http://schemas.microsoft.com/ws/2012/01/passwordexpirationtime"] => issue(store = "_PasswordExpiryStore", types = ("http://schemas.microsoft.com/ws/2012/01/passwordexpirationtime", "http://schemas.microsoft.com/ws/2012/01/passwordexpirationdays", "http://schemas.microsoft.com/ws/2012/01/passwordchangeurl"), query = "{0};", param = c1.Value); |
Dit gaan we doen via Powershell:
$msolId = "urn:federation:MicrosoftOnline" $rptName = "Microsoft Office 365 Identity Platform" $rptRules = (Get-AdfsRelyingPartyTrust -Identifier $msolId).IssuanceTransformRules $newRule = '@RuleTemplate = "LdapClaims" @RuleName = "UPN Claim Rule" c1: [Type == "http://schemas.microsoft.com/ws/2012/01/passwordexpirationtime"] => issue(store = "_PasswordExpiryStore", types = ("http://schemas.microsoft.com/ws/2012/01/passwordexpirationtime","http://schemas.microsoft.com/ws/2012/01/passwordexpirationdays", "http://schemas.microsoft.com/ws/2012/01/passwordchangeurl"), query = "{0};", param = c1.Value);' $rptRules = $rptRules + $newRule Set-AdfsRelyingPartyTrust -TargetName $rptName -IssuanceTransformRules $rptRules |
4. Inschakelen Extranet Lockout
ExtraNet lockout is een volledig op zichzelf staand mechanisme voor het voorkomen van DOS aanvallen op de ADFS server. Deze setting waarmee accounts gelocked kunnen worden wanneer meer dan een X aantal keer het foute wachtwoord is gebruikt gaan we inschakelen. We stellen hier de volgende properties in:
ExtranetLockoutEnabled = True (schakel de lockout policy in)
ExtranetLockoutThreshold = Default is 2147483647. Dit is het aantal foute wachtwoorden dat geprobeerd mag worden voordat een lockout plaats vindt. Omdat ADFS inlogpogingen ook AD inlogpogingen zijn is het logisch om deze waarde gelijk of lager te zetten dan je AD Lockout Policy. Wij gaan deze op 10 zetten.
ExtranetObservationWindows = Default 00:30:00 wat gelijk staat aan een half uur. Dit is de periode dat een gebruiker uitgesloten wordt als de policy geactiveerd wordt. Wij veranderen deze instelling naar een kwartier.
ExtranetLockoutRequirePDC = Default is True. Dit betekend dat de lockout alleen gecontroleerd kan worden door de PDC. We willen dat elke DC deze lockout kan controleren en stellen daarom deze seting in op “false”.
Dit doen we als volgt:
Set-AdfsProperties -EnableExtranetLockout:$true -ExtranetLockoutThreshold 10 -ExtranetObservationWindow (New-TimeSpan -Minutes 15) -ExtranetLockoutRequirePDC $false |
5. Log inlogpogingen
ADFS logt standaard geen gefaalde of succesvolle authenticaties. Om beter te kunnen loggen moeten we ADFS de juiste loglevels laten loggen, namelijk:
Set-ADFSProperties –LogLevel Information,Errors,Verbose,Warnings,FailureAudits,SuccessAudits |
En schakel de logging in via GPO om succes en failure audit logging in te schakelen:
auditpol.exe /set /subcategory:"Application Generated" /failure:enable /success:enable |
6. Aanpassen design
Momenteel ziet de huidige login pagina er een beetje ouderwets uit. Deze willen we een meer modern en gestoomlijnd uiterlijk geven zoals gebruikers gewend zijn van b.v. Office365.
Om dit te doen gaan we als volgt te werk:
1. Download de volgende stylesheet:
https://github.com/Microsoft/adfsWebCustomization/tree/master/centeredUi
2. Sla het thema op, op de primaire ADFS server in “c:\adfs\moderntheme”
3. Schakel ID Initiated SignOn Page aan (staat default aan… maar 2-B-Sure):
Set-AdfsProperties –EnableIdpInitiatedSignonPage $True |
4. Minify het “ThemeCenterBrand” CSS bestand en sla deze op als “ThemeCenterBrand-minified”
5. Maak een nieuwe ADFS theme aan:
New-AdfsWebTheme –Name custom –StyleSheet @{path="c:\adfs\moderntheme\ThemeCenterBrand-minified.css"} |
5. Activeer het nieuwe thema:
Set-AdfsWebConfig -ActiveThemeName custom |
Nu gaan we het nieuwe thema genaamd “custom” voorzien van 2 afbeeldingen. De achtergrond en het logo.
De achtergrond is bij voorkeur een JPG en het logo een PNG met transparante achtergrond. Verder hebben ze bij voorkeur de volgende formaten:
Wallpaper:
Lengte in pixels: 1920
Breedte in pixels: 1080
Bestandsgrootte in Kb: 200
Naam: Willekeurig. Wij gebruiken “background.jpg”
Logo:
Lengte in pixels: Maximaal 245 pixels
Breedte in pixels: Maximaal 36 pixels
Bestandsgrootte in Kb: 10
Naam: Willekeurig. Wij gebruiken “logo.png”
Beide bestanden plaatsen we in de thema folder “C:\adfs\moderntheme\images” en vervolgens updaten we het thema:
Plaats wallpaper:
Set-AdfsWebTheme -TargetName custom -Illustration @{path="C:\adfs\moderntheme\images\background.jpg"} |
Plaats logo:
Set-AdfsWebTheme -TargetName custom -Logo @{path="C:\adfs\moderntheme\images\logo.png"} |
Als het thema klaar is kopiëren we deze (niet voor functionaliteit maar als backup) naar hetzelfde pad (c:\adfs\moderntheme\) op iedere ADFS server in de farm.
Om links toe te voegen of te verwijderen op deze pagina kunnen we “AdfsGlobalWebContent” commando’s gebruiken. Op deze pagina’s worden de commando’s besproken: https://docs.microsoft.com/en-us/powershell/module/adfs/set-adfsglobalwebcontent?view=win10-ps
7. Overige takaways
Overweeg ook onderstaande tips om door te voeren zodat je ADFS server zo veilig mogelijk blijft:
- Admin rechten op ADFS mogen alleen aan AD en ADFS admins gegeven worden
- Minimaliseer het aantal lokale AD accounts
- Implementeer MFA
- Sta zo min mogelijk remote management op de ADFS servers toe
- Beperk toegang via een juist ingestelde firewall
- Plaats ADFS servers in top-level-OU’s zonder andere servers
- Als er GPO’s worden toegepast op ADFS servers zorg er dan voor dat deze specifiek voor de ADFS server zijn en niet toegepast worden op andere OU’s
- Zorg ervoor dat certificaten niet opgeslagen zijn op de ADFS server en dat ze als niet-exporteerbaar zijn geïmporteerd
- Zorg ervoor dat auto-renewal aanstaat van de certificaten en dat waar dit niet mogelijk is je de renewal dates in je agenda zet
- Zet logging aan op het hoogste niveau en zend de logs door naar een SIEM
- Pas overige hardening technieken toe zoals het up-to-date houden van de servers, het toepassen van lange en complexe wachtwoorden en het verwijderen van onnodige services.
Zo, dat was het migratietraject van een ADFS server 2012 naar ADFS 2016 incl. WAP servers, MFA en tweaks. Ik hoop dat deze post of delen van deze post waardevol waren en je op weg geholpen hebben. Ik heb getracht om zo compleet en duidelijk mogelijk het traject uit te schrijven. Dus ben je er blij mee, laat het dan even weten met een leuk berichtje of wederpost, want daar haal ik de energie uit om te blijven schrijven. Succes met migreren vrienden!!
