Freigeben über

Hvordan integrere ditt lokale Windows Server Active Directory med Windows Azure Active Directory, del 3: Single Sign-On

  • Artikel

Her er en oversikt over alle delene av denne artiklen:

Single sign-on

Forberedelser og krav

Windows Azure AD kan etablere trust mellom ulike typer Security Token Service (STS), men vi kommer til å benytte ADFS 2.1 på Windows Server 2012 i denne gjennomgangen. Du må ha følgende på plass for å kunne etablere trustet med WAAD:

  • Active Directory DS
    Et lokalt Active Directory som kjører på Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2 eller Windows Server 2012.
  • ADFS (eller annen STS)
    En eller flere ADFS servere som kjøre enten ADFS 2.0 på Windows Server 2008, Windows Server 2008 R2 eller Windows Server 2012, eller ADFS 2.1 på Windows Server 2012. Planlegging og implementasjon av ADFS er et omfattende tema med mange alternativer, men som et utgangspunkt anbefaler jeg å etablere en ADFS farm med minst én server og databasen lagret på en egen SQL Server. Du har da full fleksibilitet for premtidige utvidelser. I tillegg kan man om ønskelig etablere egene ADFS Proxy servere på nettverkets DMZ senere. ADFS serveren er med i ditt lokale Active Directory, mens ADFS proxyen står i arbeidsgruppe. Er det snakk om store miljøer bør du vurdere en egen SQL database for ADFS. Skal du ha flere ADFS Server i farmen eller flere proxyer på DMZ må du i tillegg ha en lastbalanserer, feks Network Load Balancing (NLB) eller F5 BigIP. Detaljert informasjon om design og implementasjon av ADFS finnes her: ADFS Design Guide. For test kan du klare deg med kun én ADFS server med lokal database (WID). Du kan også velge å ikke gjøre din ADFS tilgjengelig på Internet, singel sign-on vil da kun fungere for brukerer som er tilkoblet det lokale nettverket.
  • Microsoft Online Services (MSOL) komponenter
    Trustet mellom din STS (ADFS) og WAAD settes opp i PowerShell. Derfor må maskinen hvor du skal gjøre dette ha følgende installert. I vårt eksempel har vi tenkt å kjøre oppsettet av føderasjonen på ADFS serveren så vi har installert alle MSOL komponentene der.
    • .NET Framework 3.5 SP1
    • Microsoft Online Service Sign-in Assistant (MSOL SIA)
    • Microsoft Online Services PowerShell Module
  • Klargjøring av lokalt Active Directory
    Trust med WAAD er basert på domenenavn. Hver bruker som skal kunne benytte single sing-on for å få tak i tjenester hos Microsoft må derfor ha et User Principal Name (UPN) suffix under det domenet du har valgt å føderere. Dette domenet må i tillegg være et offentlig domene som er tilgjengelig for navneoppslag på Internet.

For å sjekke at alt er i orden før du prøver å etablere føderasjonen med Windows Azure AD kan du kjøre Microsoft Deployment Readiness Tool (MDRT) som gjør en grundig sjekk av alt som må være på plass før du kan sette opp single sign-on og directory sync. MDRD gir deg en oversiktlig HTML rapport med status for alle sjekker den har utført og beskrivelser av hvordan du løser eventuelle problemer den oppdager.

Oppsett

ADFS

Først må vi sette opp Active Directory Federation Services (ADFS). I denne gjennomgangen benytter vi følgende oppsett:

clip_image001

En fullstendig gjennomgang av planlegging og installasjon av ADFS er utenfor hva denne artikkelen forsøker å kommunisere, men her er en rask gjennomgang av ADFS oppsettet. Følgende servere er med:

  • aeaadfssql1
    Kjører SQL databasen for ADFS tjenesten.
  • aeaadfs1
    ADFS server som er med i on-premise Active Directory domenet. Denne serveren kan utføre autentisring mot on-premise Active Directory. Hvis du velger å ikke benytte en ADFS proxy så må FQDN for din ADFS-tjeneste peke på en IP-adresse som fører til denne serveren og TCP port 443 (SSL) må være åpen inn til denne serveren fra Office 365. I den interne DNS tjenesten peker ADFS-tjenestenavnet (fs.ateaedge.no) på denne serverens IP adresse.
  • aeaadfsproxy1
    ADFS server som ikke er med i domenet og står på nettverkets DMZ sone. Denne er, som navnet angir, kun en proxy som videresender forespørsler fra Internet til den interne ADFS tjenesten. I den eksterne DNS tjenesten peker ADFS-tjenestenavnet (fs.ateaedge.no) på denne serverens IP adresse.

Her er konfigurasjonstrinnene. Så langt der et mulig er kommandolinje benyttet:

  1. Installer Windows Server 2012 på to maskiner. I vårt eksempel er dette aeaadfssql1 og aeaadfs1.

  2. Installer SQL Server 2012 på maskinen som skal kjøre ADFS databasen (aeaadfssql1). Benytt standardverdier på alle valg. Påse at Windows Authentication er valgt.

  3. Opprett en bruker som skal kjøre ADFS tjenesten. Denne trenger kun å være Domain User. Denne vil benyttes av ADFS tjenesten og applikasjonspoolen på alle de interne ADFS serverne. Altså de som er med i domenet (aeaadfs1). Denne kontoen må ha tilgang til SQL databasen.

  4. Legg til ADFS rollen på ADFS primærserveren (aeaadfs1) og ADFS Proxyen (aeaadfsproxy1):
    Add-WindowsFeature -Name ADFS-Federation –IncludeManagementTools

  5. Installer et ADFS service-sertifikat på den primære ADFS serveren (aeaadfs1). Dette sertifikatet benyttes som et vanlig SSL sertifikat for å kryptere kommunikasjonen med ADFS tjenesten. Hvis du ikke benytter en ADFS proxy må dette sertifikatet stoles på av både Office 365,eventuelle andre føderasjonspartnere og klienter. Trust med klientene og andre føderasjonspartnere enn Office 365 kan ordnes ved å utveksle interne CA sertifikater, men ikke med Office 365. Det enkleste er derfor ofte å kjøpe et SSL sertifikat for dette formålet.

  6. Identifiser service-sertifikatets thumbprint. Du trenger dette for å konfigurere ADFS:
    image

  7. Konfigurer ADFS på primærserveren (aeaadfs1):
    Install-AdfsFarm -CertificateThumbprint 85D184038F330CA5059E04373806852D2A6F2BC0 -FederationServiceName fs.ateaedge.no -ServiceAccountCredential (Get-Credential) -OverwriteConfiguration -SQLConnectionString "Data Source=AEAADFSSQL1;Integrated Security=True"
    CertificateTumbprint identifiserer service sertifikatet, FederationServiceName angir navnet på ADFS tjenesten, ServiceCredential gir brukernavn og passord for servicekontoen (se trinn 3), til sist kommer informasjonene for å koble til SQL databasen.

Hvis du ønsker å benytte en ADFS Proxy server må også følgende utføres:

  1. Installer Windows Server 2012 på ADFS Proxy serveren (aeaadfsproxy1).
  2. Rediger HOSTS filen på ADFS proxy serveren slik at navnet på ADFS tjenester (fs.ateaedge.no) peker på IP adressen til den interne ADFS serveren.
  3. Legg til ADFS rollen på ADFS Proxyen (aeaadfsproxy1):
    Add-WindowsFeature -Name 'ADFS-Proxy' -IncludeManagementTools
  4. Eksporter ADFS service sertifikatet, inkludert den private nøkkelen, fra ADFS primærserveren og importer det på ADFS Proxyen.
  5. Konfigurer ADFS på proxy serveren:
    Add-AdfsProxy -FederationServiceName fs.ateaedge.no –FederationServiceTrustCredential (Get-Credential)
    Når du blir spurt om brukernavn/passord oppgir du en konto og passord som har lokale administratorrettigheter på ADFS primærserveren.

Vi har nå gjort ferdige de lokale forberedelsene og kan sette opp trustet med Microsoft nettskyen.

Føderasjon med Windows Azure Active Directory

Vi har valgt å føderere domenet ateaedge.no og har etablert dette i en offentlig DNS. Navnet vi har gitt vår egen STS tjeneste, som ADFS leverer, er fs.ateaedge.no. Dette navnet resolves til den interne ADFS serverens IP adresse av klienter som befinner seg på det lokale nettverket. Mobile klienter som er utenfor lokalnettverket resolver det samme navnet til ADFS proxyens IP.

Som nevnt skal vi sette opp føderasjonen på den intern ADFS servere. Selve operasjonen må gjennomføres med PowerShell. Her vises oppsettet:

  1. Brukernavn/passord
    Kommando: $FSCred = Get-Credential
    Lager et PowerShell objekt som lagrer brukernavn og passord for en service-administrator i ditt Windows Azure AD. Dette objektet benyttes kun under oppsett av føderasjonen.
    clip_image002
  2. Koble til Windows Azure AD
    Kommando: Connect-MsolService -Credential $fscred
    Kobler til Windows Azure Active Directory vha brukernavn/passord som ble angitt i forrige trinn. Hvis alt er OK gir ikke denne kommandoen noen status.
  3. Vi har valgt å sette opp føderasjonen direkte fra ADFS primærserveren. Hvis du ønsker å gjøre dette fra en annen maskin må du også kjøre denne kommandoen:
    Set-MSOLADFSContext –Computer <FQDN til ADFS Server>
  4. Etablere domenetrust
    Her finnes det to muligheter:
    1. Opprette et nytt føderert domene
      Kommando: New-MsolFederatedDomain -DomainName ateaedge.no -SupportMultipleDomain
      Etablerer et trust for ateaedge.no domenet samtidig som vi vha SupportMultipleDomain parameteren setter opp støtte for flere topp-nivå domener på et senere tidspunkt.
    2. Konvertere et domene som allerede er etablert i WAAD til et føderert domene
      Kommando: Convert-MSOLDomainToFederated -DomainName ateaedge.no -SupportMultipleDomain
      Et allerede etablert domene kalles for et standard domene. Hvis alt går bra får du følgende tilbakemelding:
      Successfully updated 'ateaedge.no' domain.
  5. Verifisere innstillinger
    Kommando: Get-MsolFederationProperty -DomainName ateaedge.no
    Viser et sammendrag av føderasjonen for det angitte domenet, både fra lokal ADFS og Windows Azure AD. Se etter source attributtet, det skal være ett for ADFS og ett for WAAD. Informasjonene fra disse skal være lik.

MERK: Hvis du benytter ADFS 2.1 på Windows Server 2012, som i dette eksempelet, trenger du å legge inn litt ekstra informasjon i registeret på din ADFS server. Dette er fordi ADFS PowerShell var en PowerShell snap-in i versjon 2.0, men er nå en PowerShell modul. Lagre teksten under som en reg fil og importer den på ADFS serveren.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellSnapIns\Microsoft.Adfs.PowerShell]
"ApplicationBase"="C:\\Windows\\ADFS"
"Version"="6.2.0.0"
"AssemblyName"="Microsoft.IdentityServer.PowerShell, Version=6.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
"Description"="This powershell snap-in contains cmdlets used to manage Microsoft Identity Server resources."
"PowerShellVersion"="1.0"
"ModuleName"="C:\\Windows\\ADFS\\Microsoft.IdentityServer.PowerShell.dll"
"Vendor"="Microsoft"

Under dette oppsettet har din lokale ADFS og Windows Azure AD utvekslet informasjon om digitale sertifikater (token signing certificate). Disse har en utløpsdato og hvis denne passeres før sertifikatet fornyes vil single sign-on slutte å fungere. Det anbefales derfor at du følger informasjonen på denne siden for å sette opp en automatisk oppdatering av føderasjonsinformasjonen:

Test

Vi kan nå teste at føderasjonen fungerer og at brukere kan logge på tjenester i skyen med sitt lokale brukernavn og passord. Dette kan vi enten gjøre med en nettleser eller med Microsoft Remote Connectivity Analyzer.

Nettleser (på en maskin som er medlem av ditt lokale Active Directory)

  1. Sørg for at URLen til din egen STS er lagt inn maskinens Local Intranet sites.
    I vårt tilfelle er URLen https://fs.ateaedge.no/
  2. 2. Gå til Microsoft Online portalen.
  3. Når du her skriver inn et brukernavn fra et føderert domene vil du få melding om at du må logge på hos din lokale STS (ADFS server).
    clip_image003
  4. 4. Trykk på linken. Du vil se at nettleseren videresender deg til din lokale STS og deretter videre inn på Microsoft portalen. Med mindre du allerede har etablert directory sync, vil testen feile og du vil se følgende melding fra Microsoft portalen:
    clip_image004
    Dette betyr imidlertid bare at brukeren du tester med ikke finnes i Windows Azure AD ennå. Føderasjonen fungerer som den skal, ellers ville du fått en feilmelding fra ADFS i stedet. Din ADFS løsning har sendt i fra seg noen verdier til Windows Azure AD, men siden det ikke på dette tidspunktet finnes noen bruker som matcher disse verdiene får du denne feilen.

Microsoft Remote Connectivity Analyzer

MRCA kan benyttes til å teste både lokal Exchange og Office 365.

  1. Gå til Microsoft Remote Connectivity Analyzer.
  2. Velg Office 365 fanen og deretter Microsoft Single Sign-On, trykk Next.
  3. Skriv inn brukernavn og passord, trykk Perform Test.
  4. Hvis alt fungerer som det skal vil du få opp en webside med Connectivity Test Successful.

Single sing-on vil arte seg forskjellig avhengig av hvor og med hvilke enheter eller klienter brukerne logger på. En maskin som er medlem i Active Directory vil ha automatisk SSO mot Windows Azure AD hvis den er på lokalnettverket og kan snakke med den interne ADFS serveren, mens den må logge på via en webside (forms) når den er utenfor nettverket. Du bør teste alle scenarioene under:

  • Fra en maskin som er medlem i Active Directory
  • Fra en maskin som ikke er medlem i Active Directory tilkoblet det lokale nettverket
  • Fra en maskin som er medlem i Active Directory men på utsiden av det lokale nettverket
  • Fra ulike operativsystemer
  • Fra private PCer
  • Fra kiosk PCer eller Internet-caféer (kun med nettleser)
  • Fra smarttelefoner som benytter Microsoft Active Sync protokollen

MERK:

  • Det kan gå inntil 24 timer før Microsoft online portalen viser at domenet ditt er føderert. Dette gjelder spesielt hvis du har konvertert et allerede eksisterende standard domene til et føderert domene.
  • Du vil ikke lenger kunne lage brukere i Windows Azure AD fra en av portalene eller PowerShell under domenet du har føderert. Kun brukere under ikke-fødererte domener kan opprettes i portalene eller PowerShell.

Neste trinn er å etablere Directory Sync for å kopiere brukere fra det lokale Active Directory opp i Windows Azure Active Directory. Det er tema i neste del.