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

Jeg ble lurt


Denne ukens mest interessante og lærerike opplevelse, var å være mottager av et angrep. Det var godt å se at etablerte tiltak stoppet det, men også en øyneåpner.

Jeg ble lurt


Denne ukens mest interessante og lærerike opplevelse, var å være mottager av et angrep. Det var godt å se at etablerte tiltak stoppet det, men også en øyneåpner.

Hendelsen startet med at jeg mottok en mail fra daglig leder i reisebyrået vi bruker. En del av forklaringen på at den gikk under radaren, er at jeg faktisk ventet et dokument fra han. Mailen var formulert på akseptabel norsk, med hans mailsignatur etc. Selv om jeg stusset på en av formuleringene, var det ikke nok til å øke bevissthetsnivået. I mailen lå filen tilsynelatende delt som et OneDrive dokument, og følgelig måtte jeg gjennom en autentiseringsprosess for å få tilgang. Ikke noe uvanlig i det, men det gav ingen fil som resultat. Jeg stoppet derfor etter to forsøk, og sendte en mail til han om at jeg ikke hadde fått filen.

Rundt klokken 1600 var jeg borte fra PC’en, men Microsoft Authenticator appen varslet om at jeg var i gang med en pålogging. Avslo selvfølgelig, og funderte litt på hvorfor den varslet. Rett etter ringte telefonen med en samtale fra USA. Tok ikke imot den, ettersom telefoner derfra som regel er uønskede salgshenvendelser. Jeg googlet nummeret: «Microsoft Authenticator Phone service». Da begynte det endelig å gå opp for meg hva dette trolig handlet om, og tankene returnerte til mailen fra reisebyrået. Det gikk opp for meg at jeg hadde blitt lurt til å gi fra meg brukernavn og passord.

Jeg skiftet passord på kontoen umiddelbart, og startet en dialog med noen av våre sikkerhetskyndige konsulenter. Vi bruker Office 365 og Azure AD P2 som innebærer ekstra sikkerhetsbarrierer, to-faktor autentisering og brukbare rapporter om hva som skjer. Fant frem den angjeldende mailen, og så at den i ettertid var gjenkjent og prosessert av Microsoft. Nå lå det med en tekstfil med tittel «Zero Hour Auto Purge – Malware Alert Text». «Zero Hour» er en indikasjon på hvorfor den slapp gjennom. Det er et begrep som brukes om angrepsmetoder eller signaturer som ikke er kjent av forsvarsmekanismene fra før.

Rapporteringen viste at vi på min konto hadde hatt innloggingsforsøk fra Amsterdam og Ghana. Det eneste som forhindret full tilgang, er at vi har to-faktor autentisering på våre systemer. Det er også poenget med å formidle denne historien.

For den som er ukjent med begrepet to-faktor, betyr det at man innfører et element til påloggingsprosessen ut over brukernavn og passord. To-faktor er relativt enkelt å etablere, selv for systemer som ikke har direkte støtte for det. Vi ser alt for mange systemer som mangler denne vesentlige barrieren, og de er åpenbare og hyppige mål for denne type angrep. Som daglig leder i Sicra er jeg godt kjent med risiko og angrepsmetode, men jeg gjenkjente ikke dette som et angrep før jeg hadde gitt fra meg brukernavn og passord. Det er nok mange uten to-faktor autentisering som aldri ville ha oppdaget at de hadde gitt fra seg nøklene til kongeriket. Vi har selvsagt varslet reiseselskapet, og bedt det informere relevante parter om kompromitteringen.

Om du trenger assistanse til å sjekke eller etablere to-faktor, ta kontakt. For mer informasjon om to-faktor se NSM side https://nsm.stat.no/aktuelt/passordanbefalinger-fra-nasjonal-sikkerhetsmyndighet/

SAML – NetScaler Identitet og autentisering


Vi leverer for tiden i en hybrid verden. Applikasjoner leveres som SaaS tjenester, produseres på egne datasenter eller i Public Cloud IaaS. I en slik virkelighet blir autentisering, identitetsbrokering og en sømløs og sikker opplevelse for brukeren vesentlig. Vi har erfaring med disse utfordringene, og bruker ofte NetScaler som verktøyet hvor vi syr dette sammen. I denne artikkelen forklarer Kai Thorsrud litt om hvordan vi kan bidra til enklere, sikrere og bedre opplevelser i en slik hybrid tilværelse.

Netscaler Cloud Gateway
Netscaler kan med fordel benyttes som en SAML Service Provider og eller Identity Provider. Den er en fleksibel autentiserings-proxy som fungerer svært godt mot public cloud. Vi bruker den for å tilby brukervennlig pålogging (SSO) til arbeidsflater som kombinerer tradisjonelle og cloud applikasjoner. Man kan eksponere interne web applikasjoner på en sikker måte og skjule interne URLs, samtidig som man samler public cloud og personlige web applikasjoner under en flate. Det er problemfritt å publisere tradisjonelle windows applikasjoner ved å benytte Citrix XenApp / XenDesktop i samme portal.

Investering i Netscaler vil også kunne videreføres i en fully managed cloud solution i Azure. Microsoft har erstattet sin RDP funksjonalitet og tilsvarende gateway funksjoner for å samle dette i form av en fully managed Netscaler, hvor de tilbyr en geo aware tjeneste med 12 Access Points globalt med en rask tilgang til dine applikasjoner.

Fordeler ved å benytte Netscaler for SAML

Netscaler tilbyr en regelbasert autentisering. Andre løsninger er ofte bundet til ett autentiserings-oppsett på frontend og backend, i ett fast prekonfigurert mønster. Ønsker man å tilpasse autentisering ved å gjøre annen back end autentisering eller annen front end autentisering for en applikasjon må man ha en instans per konfigurasjon.

I Netscaler gjøres alt dette dynamisk og under ett grensesnitt og en konfigurasjon. I tillegg kan man også dra nytte av flere avanserte funksjoner som følgende faktorer.

GeoLocation
Netscaler har GeoLocation funksjonalitet og leveres med en Location Database som identifiserer hvilke land du kommer fra eller hvilken region du kommer fra. Databasen er MaxMind sin lite database. Det er mulig å kjøpe Max Mind sin fulle database og importere dette for mer detaljert Geo Location. Den inkluderte databasen gir deg god mulighet til å identifisere hvilket land påloggingen utføres fra.

Eksempler på hvordan Geo Location kan være endel av pålogging
• Kreve ToFaktor fra enkelte Land (Netscaler kommer snart med gratis sms tokens inkludert. Netscaler støtter i dag integrasjon mot de fleste tofaktor løsninger)
• Nekte pålogging fra enkelte Land

IP Reputation
Netscaler har mulighet for å benytte IP Reputation databaser og man kan benytte IP Reputation som en faktor ved pålogging hvor man kan kreve ekstra identifisering eller nekte identifisering hvis pålogging forsøkes fra IP Addresser med dårlig rating. Man kan også aktivere ekstra logging for pålogging fra IP Addresser med dårlig reputation.

End Point Analysis
Netscaler har en End Point Analysis engine som benyttes sammen med tykk VPN Klient. For å kunne gjøre full End Point Analysis kreves det at man benytter VPN Klient for oppkobling. VPN Klient kan automatisk installeres fra tjeneste URL. Det er mulig å benytte End Point Analysis som en faktor ved pålogging, hvor pålogging kun tillates via VPN om man oppfyller kriterier for Anti Virus eller andre End Point kontroller.

Bruk av Netscaler Advanced Expressions under pålogging
Man kan benytte Netscaler Advanced Expressions som endel av påloggings kriterier. Dette gir utallige muligheter ved pålogging som å begrense pålogging på enkelte dager, enkelte tidspunkt. Sende deg til forskjellige IDP basert på domenenavn i epost addresse.

Generelle fordeler ved å benytte Netscaler til pålogging / SSO
Netscaler har en svært fleksibel autentiserings-engine som gjør at man kan lage ett back end autentiserings design for SSO inn mot on premise miljøer og deretter plugge på forskjellige front end autentiserings engines i forkant av applikasjonen. Dette gjør at man f.eks kan velge å la 3rd parties / samarbeidspartnere utnytte konseptet «bring your own identity» og ved attributter gjøre sømløs SSO inn mot on premise miljø.

Eksempler er å tillate login mot on premise miljø med OKTA Identity Provider i forkant hvor kan legger ved «internt» brukernavn som en SAML attributt. Brukeren kan da logge på med Okta SAML identity som ”kai@sicra.no”, hvor brukernavn ”kaithors” sendes som en SAML Attributt og deretter benyttes ved SSO inn i ett tradisjonellt on premise miljø. Videre kan man benytte samme back end autentisering mot en annen leverandørs «client certificate» baserte autentisering i front end hvor da internt brukernavn leveres som en attributt på sertifikatet.

Netscaler er ikke «Nok en ny interrim løsning»
Netscaler som applikasjons leveranse konsept er noe vi ser benyttes mer og mer av forskjellige leverandører for fremtiden

  • Microsoft benyttes Netscaler i Azure som en Identity Proxy og har sluttet utvikling av eget produkt til fordel for samarbeid med Citrix.
  • Google Elastic Cloud har utviklet hva de kaller «BeyondCorp VPN» som er en klientløs VPN strategi. Ser du hvordan BeyondCorp VPN fungerer er dette som kopiert fra en Netscaler. Google Kaller dette IAP, Identity Autentication Proxy og selges som det nye ”hotte” av aksess teknologier

Netscaler er videre også ranket som nummer 3 av Web Application Firewalls av gartner group i tillegg til å være ranket som nummer to av application delivery controllers av Gartner.

Netscaler har også en meget god arkitekturfordel i forhold til konkurrerende løsninger, ved at Netscaler hele tiden har vært basert på software og ikke ASIC plattform. Dette gjør at Netscaler har ett binary image identisk på tvers av alle plattformer.