Azure MFA med OnPremise systemer


I denne posten skal vi se på hvordan Azure MFA (Multi Factor Authentication) kan benyttes til flere formål enn bare som MFA for pålogging til Office365 og andre Microsoft-tjenester.

Azure MFA med OnPremise systemer


I denne posten skal vi se på hvordan Azure MFA (Multi Factor Authentication) kan benyttes til flere formål enn bare som MFA for pålogging til Office365 og andre Microsoft-tjenester.

Azure Multifaktor Autentisering (MFA)

I denne posten skal vi se på hvordan Azure MFA (Multi Factor Authentication) kan benyttes til flere formål enn bare som MFA for pålogging til Office365 og andre Microsoft-tjenester. Mange sitter i dag på dedikerte MFA-løsninger med relativt stive priser for å sikre pålogging til tjenester i eget datasenter, mens Azure MFA benyttes ved pålogging mot Microsoft-tjenestene.

Innledningsvis kan det være greit å plassere Azure MFA i MS-porteføljen. Azure MFA som system lever litt på siden av Azure AD. MFA benytter Azure AD som brukerkatalog og kan brukes av Azure AD ved pålogging. Men MFA kan likevel sees på som et separat system.

Bruk av Azure MFA kommer naturlig når en benytter skytjenester. Men når vi skal benytte det til OnPremise løsninger kan vi gå frem på flere måter.

Azure MFA via Radius/Microsoft NPS

Den enkleste modellen for å erstatte eksisterende Radius-basert MFA-løsning med Azure MFA er via Network Policy Server (NPS).  NPS er Radius server rollen som følger Windows Server.

Microsoft distribuerer en egen plugin for NPS som setter NPS i stand til å autentisere brukere mot Azure MFA. Når en bruker skal autentiseres sender Radius-klienten (i vår verden vanligvis en ADC/NetScaler) en Radius-forespørsel til NPS som tar seg av kommunikasjonen med Azure MFA og validerer brukeren.

  • Både SMS baserte koder og autentisering med Microsoft Authenticator appen
  • Bruker har samme MFA-token (app eller sms) som ved pålogging til Office365
  • Tokenet administreres av brukeren selv for eksempel via Office-portalen.

Implementering av denne løsningen består kun i å etablere NPS rollen på et par Windows Servere og installere plugin fra Microsoft. Deretter defineres endepunkt (gatewayer) og policies for disse i NPS GUI.

Det anbefales naturligvis å ha redundans på en slik tjeneste og ved oppsett av flere servere opptrer disse separat. NPS har powershell cmdlets for eksport og import av konfigurasjon som kan benyttes etter endringer som skal appliseres på flere servere.

Azure MFA med ADFS

Noe over samme lest som plugin for NPS finnes det ferdig integrasjon i ADFS mot Azure MFA. Denne er en integrert del av ADFS fra Windows Server 2016 og oppover. Vi går ikke i detalj på denne integrasjonen i denne posten fordi ADFS gir federert autentisering fra OnPremise AD, noe som virker litt unødvendig når vi likevel har alle brukere i Azure AD og kan bruke den som Identity Provider.

Azure AD autentisering

I modellene over er vi avhengig av lokal autentisering med AD eller tilsvarende og benytter Azure MFA kun som en flerfaktor-komponent.

Dersom en i stedet flytter autentisering av brukere i sin helhet over til Azure AD kan man benytte både Azure MFA og Conditional Access for å sikre tilgang til applikasjoner.

Godt implementert gir det moderne autentisering, gjerne med fingeravtrykk eller ansiktsgjenkjenning og via SAML eller Open ID Connect protokollene overføres brukers identitet til OnPremises løsningen. Selve autentiseringen er da et forhold mellom bruker og Azure AD mens applikasjonen (evt. gateway) mottar identiteten som signerte token brukeren har med seg fra Identity Provider.

Når identitet/autentisering skilles fra applikasjonen kan våre OnPremise systemer anses som SaaS tjenester vi leverer til egen organisasjon. Autentiseringen blir identisk som den vi bruker når vi integrerer eksterne SaaS tjenester mot egen Identity Provider.

Det legger samtidig grunnlaget for å kunne flytte forvalting av PCer, mobiler og nettbrett ut av lokalnett-sfæren og over i skyløsninger som for eksempel Microsoft Intune.

Hvis du lurer på noe mer om dette temaet, kontakt Sicra, da vi har praktisk erfaring med flere slike implementeringer