TechNet Norge

Hvordan vise lagrede passord

OlavT — Fri, 10 May 2013 10:23:26 GMT

Det er frustrerende å ha glemt et passord, men man vet at
det ligger lageret på en PC’en slik at man blir automatisk logget på så lenge
du bruker akkurat den PC’en. Mange ganger er det enkelt å be om et passord
bytte eller tilsending av passord på tjenesten det gjelder, mens andre ganger
er det vanskelig eller umulig. Noen ganger finnes det ikke mulighet for å få
tilsendt passord, eller det er så lenge siden at du ikke lengre har tilgang til
epost adressen som ble brukt når du startet å bruke tjenesten. Eller som i mitt
tilfelle denne gangen. Jeg har en NAS boks, der ligger det mye data etter hvert
og nå trenger jeg passordet for å komme inn. For å gjøre ting ekstra vanskelig
har jeg byttet IP adresse på boksen slik at jeg ikke engang kan bruke det
lagrede passordet på PC’en min for å logge på. Men jeg vet at det ligger der et
sted :-(

Mange vil kanskje kjenner seg igjen med lagrede epost
kontoer eller web tjenester som Facebook når man skal sette opp en ny PC. Den gode
tingen er at hvis du har maskinen med de lagrede passordene tilgjengelig kan vi
hente ut igjen passordene i klartekst så lenge du har brukerens passord og kan
logge på profilen. Det betyr at du bør sjekke dette opp før du reinstaller
Windows på en PC hvis du tror at det er noen passord du bør ta med deg videre.

Løsningen ligger i “Credential Manager”

Hva er Credential Manager? (Legitimasjonsbehandling)

Legitimasjonsbehandling lar deg lagre legitimasjon, for
eksempel brukernavn og passord som du bruker til å logge på webområder eller
andre datamaskiner på et nettverk. Ved å lagre legitimasjon kan Windows logge
deg på webområder og datamaskiner automatisk. Legitimasjon lagres i spesielle
mapper på datamaskinen kalt hvelv. Windows og programmer (for eksempel
weblesere) kan sikkert gi legitimasjonen i hvelvene til andre datamaskiner og
webområder

Så hvordan kan vi bruke dette til å løse problemet med glemt
passord?

Først starter vi “Credential Manager”, her kan vi se en god
liste over hvilke “credentials” some r lagret. Vi finner både «credentials» for
web og andre Windows funksjoner.

I mitt tilfelle var det passordet på enheten 10.0.0.3 som
var problemet. Så neste skritt er å utvide http://10.0.0.1/. Trykk på “Show” snarveien og
du blir bedt om passordet for brukerkontoen som er pålogget. Dette er
selvfølgelig for å være sikker på at ikke andre kan gå inn hvis brukeren
forlater maskinen ulåst e.l.

Skriv inn passordet og “Credentials” er nå i klar tekst.

Hver klar over at i en periode så kan andre «Credentials» nå
bli åpnet uten at du må skrive inn passordet og at de åpnede passord er synlig
i klar tekst frem til du lukker «Credential Manager»

Det er også mulig å rydde i listen ved å velge «Remove».
Dette er en lur måtte å rydde, jeg ser ofte at brukere sletter passord som er
feil, for eksempel lagret passord på en webside som er byttet på en annen
maskin, ved å slette fra nettleserens «Delete Browsing History» funksjon.
Ulempen med dette er at alle passord blir slettet, ikke bare det som er feil.
Det kan også hende at du trenger å slette andre passord den web baserte.

Så neste gang du trenger å slette passord, bruk
heller “Credential Mana

Nettverkvirtualisering, NIC teaming, QoS, Hyper-V og System Center

Kristian Nese — Fri, 03 May 2013 06:02:00 GMT

Windows Server 2012 tar virtualisering og nettskyen på alvor. En av de mest betydelige forbedringene på infrastruktur-siden i den nye versjonen er innebygd støtte for NIC teaming.

I dagens datasentre spiller hypervisorene (virtualiseringslaget) en sentral rolle og er selve fundamentet til en privat nettsky. Virtualisering gir oss muligheten til å konsolidere og klynge ressursene sammen for å utnytte maskinvaren og de investeringene som er gjort på en bedre måte enn ved å kjøre 1:1 – hvor man har en dedikert fysisk server til hver applikasjon/serverrolle.

Vi skal ikke bruke altfor lang tid på å dvele rundt ting som er allmenn kjent, men før vi dykker i det tekniske så må man forstå helheten.

Virtuelle maskiner er intet annet enn filer på disk. I større miljøer hvor Failover Cluster er inne i bildet, så må man ha en form for shared storage. Shared storage kan aksesseres via iSCSI protokollen, Fibre Channel eller rett og slett Server Message Block 3.0 (SMB3.0) (jeg har blogget om Hyper-V via SMB tidligere og anbefaler alle som ikke har sett på dette, om å evaluere denne nye løsningen). Så man har alternativer; enten å bruke tradisjonell block-basert lagring via iSCSI og/eller Fibre Channel, eller bruke fil-basert lagring over SMB3.0. Uavhengig av hva man velger, så krever det nok båndbredde sånn at man ikke får en flaskehals.

Dette leder oss til converged fabric og Software-Defined Datacenter - hvor software-stacken tar seg av all konfigurasjon av tilgjengelighet, redundans, lastbalansering og failover. Om man ønsker å ta i bruk NIC teaming uten System Center som administrasjonslag, så må man *** støv av Powershell-egenskapene.

Dette vil fungere utmerket i et lite miljø, men om man har behov for å implementere nettverksvirtualisering opp i alt dette, så blir det tungt og vanskelig å administrere. Da er det bedre å overlate management-jobben til et management-verktøy, som i dette tilfellet er Virtual Machine Manager.

Jeg har på oppdrag fra Microsoft skrevet to bloggposter (på Engelsk) som forklarer nettverksvirtualisering med Hyper-V/VMM, og hvordan man implementerer NIC teaming med QoS med VMM.

Network Virtualization Guide with VMM 2012 SP1

Configure NIC teaming and QoS with VMM 2012 SP1

Azure Camp til Bergen_ 31.mai

Linda Ørestrand — Tue, 30 Apr 2013 12:02:28 GMT

Azure Campene på Lysaker har være en suksess, og etter flere forespørsler tar vi nå konseptet til Bergen. Vi har foreløpig kun satt opp en Camp, så ikke la sjansen til å få en introduksjon til "Infrastructure as a Service" gå fra deg.

Kurset holdes av Morgan Simonsen og Olav Tollefsen.

Dato: 31.mai

Kl.: 12.30-16

Enkel lunsj

Sted: Rica Hotell, Christies gt. 5-7

Kurset er gratis!

Sitat fra en fornøyd kursdeltager:

«Hei, vil gjerne få skryte litt av Campen. Vanligvis er ting som dette veldig fluffy og ganske salgsrettet, men det vi gikk igjennom var veldig aktuelt, og definitivt tilpasset målgruppen. Veldig aktuelle temaer, og for meg som har vært igjennom et par Azure presentasjoner før var det veldig OK å få vite de tingene som betyr noe for oss, av folk som kjenner norske forhold (ikke bare standard cases om "Contoso" og bedrifter med 150.000 ansatte og 50 regionskontorer). Mange takk til begge kursholderne »

Meld deg på her: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032552978&Culture=nb-NO&community=0

Agenda

12: 30– 13:15 Introduksjon til Windows Azure v/Olav Tollefsen

Vi går gjennom Windows Azure plattformen med fokus på de nye Infrastructure
as a Service funksjonene (Virtual Machines, Virtual Network).

13:30 – 14:30 Integrasjon med Windows Azure v/Morgan Dahl Simonsen

Hvordan kan Windows Azure integreres med ditt eksisterende nettverk og
tjenester? Vi går igjennom hvordan du etablerer VPN-tilkobling til Windows Azure, hvordan
kjøre Active Directory domenekontrollere i Windows Azure og hvordan føderere og
synkronisere ditt on-premise Active Directory med Windows Azure Active Directory.

14:45 – 16:00 Administrasjon av Windows Azure med PowerShell v/Morgan Dahl Simonsen

Hvordan administrere Windows Azure med PowerShell? Vi går igjennom oppsett
avtilkobling mot Windows Azure for PowerShell og viser hvordan du kan¨automatisere
hele din cloud-plattform.

Gratis bøker fra Microsoft Press

OlavT — Mon, 22 Apr 2013 09:27:32 GMT

Alltid kjekt med gratis ting, og ennå kjekkere blir det når det faktisk kan brukes til noe :-)

Microsoft Press gir ut masse gode bøker, og flere av de er gratis tilgjengelig for nedlastning.

Det er stort sett "Introducing"bøker, så de går ikke i dypden på alle område, men det er en god start hvis du vil lære deg mer om produktene

For oss IT Pro så ligger det nå ute bøker for blant annet Windows 8, Server 2012, SQL og utrulling av Window 7. "Introducing Windows Server 2012" boken har jeg lest selv, den er et veldig greit start sted hvis du ønsker en god oversikt over Server 2012, selv om den ikke går i dypden vil den hjelpe deg å finne mer stoff for å grave videre. "Deploying Windows 7" består av deployment relaterte kapittler fra "Windows 7 Reource Kit" og artikkler fra Microsoft sin Springboard side om deployment, en veldig bra bok. Selv om den tar for seg Windows 7 spesifikt vil den i meget stor grad gjelde for Windows 8 og XP også

http://blogs.msdn.com/b/microsoft_press/archive/2012/05/04/free-ebooks-great-content-from-microsoft-press-that-won-t-cost-you-a-penny.aspx

Ny PowerShell modul for Windows Azure Active Directory

Morgan Simonsen — Wed, 17 Apr 2013 19:30:42 GMT

En ny versjon av PowerShell-modulen for Windows Azure Active Directory er tilgjengelig. Denne gikk tidligere under navnet Microsoft Online PowerShell-modulen. Alle cmdlets i modulen har order MSOL i seg, og modulene kalles MSOnline og MSOnlineExtended. Versjonsnummeret er fortsatt 1.0.0 som det var for den forrige modulen. Nytt i denne utgaven er støtte for Windows Server 2012; du kan nå installere modulen på Windows Server 2012 og også konfigurere den versjonen av ADFS som følger med Windows Server 2012. Dette betyr at du ikke lenger trenger å kjøre noen registerhack for å sette opp ADFS på WS2010 mot Windows Azure Active Directory. Dokumentasjonen har også blitt oppdatert.

32-bit http://g.microsoftonline.com/0BX10en/230
64-bit http://g.microsoftonline.com/0BX10en/423
Dokumentasjon http://technet.microsoft.com/en-us/library/hh967628.aspx

Bli med på AzureConf!

Linda Ørestrand — Wed, 10 Apr 2013 10:29:07 GMT

Den 23. april kl.: 18:00 gjenntar vi fjorårets suksess og gir dere en helt gratis virtuell Windows Azure konferanse!

Vi starter det hele med en keynote av Scott Guthrie, oppfulgt av flere sesjoner om
hvordan Windows Azure kan hjelpe deg med å lage robuste og skalerbare
applikasjoner. Community-medlemmer verden over er med på å dele sine erfaringer
og oppdagelser med Windows Azure. Denne konferansen passer både til deg som
nettopp har startet med Windows Azure og for deg som mer erfaren.

Hele arrangementet vil ha en live stream via channel9, og on-demand videoer vil bli publisert i ettertid.

For mer informasjon og oppdateringer fremover mot eventet: http://www.windowsazureconf.net/

Legg dette evente inn i kalenderen din ved å klikke her: http://sdrv.ms/14WyQOF

Ønsker du å komme i gang med Windows Azure?
Vi har en rekke muligheter for at både du som er IT-Pro og utvikler enklest mulig kan komme i gang med å ta i bruk Windows Azure i dine løsninger.

1) Her finner du SDK og det du trenger for å bruke Windows Azure

2) Kom i gang med Windows Azure Training Kit, presentasjoner, hands-on labs, kode og demoer!

3) Vi deler ut gavekort hos komplett til dere som fullfører denne lille oppgaven.

4) Lage spill med Azure backend? Ta en titt på Windows Game Starter kit with Leaderboard in Windows Azure.

5) Trening her i Norge? Bli med på Windows Azure Camp (IaaS)

Hvordan finne drivere til ukjente enheter i Windows?

OlavT — Mon, 08 Apr 2013 20:30:11 GMT

Fant en topp artikkel på ITPro om hvordan man finner ut av de ukjente enhetene i "Device Manager"

Gå inn på Itpro og les mer

Hvordan integrere ditt lokale Windows Server Active Directory med Windows Azure Active Directory, del 5: Test og feilsøking

Morgan Simonsen — Mon, 08 Apr 2013 14:20:00 GMT

Her er en oversikt over alle delene av denne artiklen:

Test og feilsøking

I denne artikkelserien har vi sett på hvordan vi setter opp intergrasjon mellom vårt lokale Windows Server Active Directory Directory Service (AD DS) og Windows Azure Active Directory (WAAD) for å få single sign on og automatisk synkronisering. Nå som hele konfigurasjonen er gjennomført kan vi foreta en pålogging med en bruker fra vårt lokale AD og få single sign on mot tjenester i Microsofts nettsky. For å kunne benytte noen tjenester forutsettes det selvfølgelig at de nødvendige lisensene er tildelt i nettskyen.

Test

Brukerne våre er allerede synkronisert inn i Windows Azure Active Directory, men for at single sign on skal fungere må vi logge på med en bruker fra vårt lokale AD på en maskin som er med i vårt lokale AD. Single sign on er ellers ikke mulig. I denne testen skal en bruker logge på Office 365. Brukeren er en vanlig domenebruker som logger på en Windows 8 maskin som er medlem i vårt ateaedge.no Windows Server Active Directory.

Åpne IE (eller en annen nettleser som kan konfigureres til Single Sign on)
Naviger til office.microsoft.com
Trykk Logg på linken i øvre høyre hjørne
Velg å logge på med en organisasjonskonto
En organsasjonskonto er en konto lagret i Windows Azure Active Directory. Denne kontoen kan enten være manuelt opprettet eller synkronisert.
Du blir sendt til Office 365 påloggingssiden, skriv inn UPN.
I det øyeblikket du trykker Tab eller bruker musen for å flytte markøren til passord-feltet, eller du trykker Logg på, vil du bli automatisk redirigert til din egen STS (ADFS) som autentiserer deg og sender deg videre til Office 365

Dette bekrefter at DirSync og Single Sign on fungerer som det skal. Hvis du trykker Logg av vil du igjen bli redirigert til din egen STS (ADFS) for å bli logget av der, for deretter å bli sendt tilbake til påloggingssiden til Office 365.

Feilsøking

De vanligste feilene i en slik løsning er listet nedenfor:

ADFS servicesertifikat utgått
Manuelt forny sertifikatet, eller implementer en prosess som gjør dette automatisk.
ADFS metadata er ikke oppdatert
Manuelt oppdater føderasjonsmetadata eller implementer Office 365 Federation Metadata Update Tool for å sørge for at dette skjer automatisk.
STS siten ligger ikke i Local Intranet sites på klienter
Internet Explorer vil kun sende fra seg brukernavn og passord hvis siten det navigrers til ligger i Local Intranet sites sikkerhetssonen. Hvis siten ikke ligger der vil man måtte logge på manuelt på STSen. I vårt eksempel er URLen til STS fs.ateaedge.no.
Brukernavn og passord for Widnows Azure AD kontoen til DirSync er endret
Hvis kontoen som angis under DirSync oppsett for å koble til Widnows Azure AD endres vil DirSync slutte å fungere. Kjøre DirSync konfigurasjonsveiviseren igjen og oppdater kontoinformasjonen.

Microsoft tilbyr ulike former for supportplaner avhengig av hvilke skytjenester man benytter. Se i portalen til de tjenestene du benytter etter alternativ. TechNet forumene er fulle av god informasjon og hjelpsomme mennesker, se lenker under. Eller så kan du jo ta kontakt med din infrastruktur-partner…

Lykke til med Windows Azure Active Directory!

Morgan
www.activedirectory.no
www.cloudpower.no

Hvordan integrere ditt lokale Windows Server Active Directory med Windows Azure Active Directory, del 4: Directory Sync

Morgan Simonsen — Mon, 08 Apr 2013 14:19:00 GMT

Her er en oversikt over alle delene av denne artiklen:

Directory sync

Etter at single sign-on fungerer kan vi gå videre med directory sync.

Forberedelser og krav

Du må ha følgende på plass for å kunne etablere synkronisering med WAAD:

En server som kan kjøre Directory Sync tool. Dette er en spesialtilpasset versjon av Forefront Identity Manager (FIM). Siden denne serveren kjører programvare som har store tilganger i ditt Active Directory bør den beskyttes på lik linje med domenekontrollerne. Maskinen som skal kjøre Directory Sync tool har følgende krav:
- Må være medlem i ditt lokale Active Directory
- Ikke være en domenekontroller
- Må ha .NET Framework 3.x installert
- Kunne kjøre PowerShell
- Maskinvare tilpasset volumet av brukere du skal synkronisere. Se her for mer informasjon.
- Directory Sync tool benytter en lokal installasjon av SQL Server 2008 Express. Har du mer enn 50 000 objekter som skal synkroniseres må du ha en full SQL Server 2008 eller 2008 R2 installasjon. Ser her for mer informasjon.
For å sette opp Directory Sync tool må du ha en konto som har følgende tilganger (disse kan, og må, være ulike kontoer):
- Administratorrettigheter på Directory Sync tool serveren
  Dette er nødvendig for å kunne installere directory sync tool og SQL på serveren.
- Rettigheter i ditt lokale Active Directory
  Kontoen må ha Enterprise Admin tilgang i din Active Directory forest. Brukernavnet og passordet til denne kontoen blir kun brukt under oppsett og lagres ikke på disk eller i minne.
- Rettigheter i din Windows Azure Active Directory tenant
  Kontoen må ha admin rettigheter i WAAD. I portalen er dette kjent som Global Administrator. Directory Sync tool lagrer denne kontoens brukernavn og passord. Du må oppdatere konfigurasjonen hvis disse endres.

Directory Sync tool oppretter en bruker kalt MSOL_AD_SYNC i Users mappen i ditt lokale Active Directory. Denne kontoen benyttes til å lese informasjon fra Active Directory og kopiere den over i directory sync tool databasen før den synkroniseres til Windows Azure AD. Denne kontoen må ikke flyttes ut av Users mappen, eller endres på annen måte.

Microsoft Deployment Readiness Tool som vi benyttet for å sjekke at alt var klart for å sette opp singel sign-on sjekker også om alt er klart for directory sync. Hvis du ikke allerede har kjørt dette verktøyet bør du gjøre det nå og se igjennom rapporten. Denne viser deg bla hvor mange objekter som vil bli synkronisert.

Oppsett

I dette tilfellet har vi satt opp en egen Windows Server 2012 maskin for å kjøre Directory Sync tool. Etter at denne serveren er installert ser topologien vår slik ut:

Her er trinnene som må utføres for å etablere Directory sync:

Aktiver Directory Sync i Windows Azure AD portalen

Logg på portalen, velg Integration, Directory sync og trykk Activate.

Du får følgende advarsel om at ditt lokale Active Directory nå blir autoritativ kilde for nesten all brukerdata i Windows Azure AD, og at informasjon fra ditt lokale AD evt vil overskrive data i Windows Azure AD. Trykk Activate.

Prosessen med å aktiver directory sync for ditt Windows Azure AD starter og portalen vil endre status når det er fullført. Det kan ta inntil 24 timer før aktiveringen er fullført. Du vil ikke kunne gå videre i denne guiden før directory sync er aktivert i Windows Azure AD.

Installer Directory Sync tool

Logg på directory sync serveren og last ned Directory Sync tool
Link til denne finner du under Deploy headingen i portalen, eller bruk denne linken.
Kjør dirsync.exe
(Hvis du ennå ikke har installert .NET Framework, kjøre denne PowerShell kommandoen: Add-WindowsFeature NET-Framework-Core.)
Følg Directory Sync tool installasjonsveiviseren, og velg å starte Directory Sync Configuration Wizard når installasjonen er ferdig.
Følg Directory Sync konfigurasjonsveiviseren
1. Du må angi to sett med brukernavn og passord. Et for å koble til Windows Azure AD og et for å koble til ditt lokale AD:
  Microsoft Online
  
  MERK: Dette brukernavnet og passordet benyttes kontinuerlig av DirSync så hvis du bytter passord på kontoen du angir her så må du kjøre Directory sync konfigurasjonsveiviseren igjen.
  Lokalt Active Directory
  
  MERK: Dette brukernavnet og passordet benyttes kun til å sette rettigheter i ditt lokale Active Directory for DirSync verktøyet og blir ikke lagret. Du trenger med andre ord ikke kjøre Directory sync konfigurasjonsveiviseren igjen hvis du endrer denne kontoen. Rettighetene vil allerede være satt.
2. Velg om du skal kjøre Exchange hybrid deployment
  
  MERK: Oppsett av Exchange hybrid er ikke tatt med i denne veiledningen. Hvis du ønsker å sette opp sameksistens også mellom din lokale Exchange-løsning og Exchange Online/Office 365 må du gjør det i tillegg til det som har blitt vist her. I så fall vil også Directory Sync tool skrive informasjon fra Windows Azure Active Directory tilbake til ditt lokale Active Directory (såkalt write back). Dette er nødvendig for at du skal kunne flytte postbokser fra Exchange Online tilbake til din egen Exchange-løsning (offboarding). Se her for mer informasjon:
  Email Coexistence
  Office 365 Deployment
3. DirSync konfigureres
4. Velg å kjøre synkronisering nå
  
  Dette vil tvinge en synkronisering umiddeblart. Sjekk Applikcation loggen på DirSync serveren for å se status.
Logg på Windows Azure Active Directory portalen og se status på DirSync:

Test og verifisering

Nå som dirsync er satt opp kan vi observere følgende:

Manuelt opprettede kontoer i Windows Azure Active Directory, med UPN fra domenet du har valgt å føderere, som er i konflikt med lokale kontoer, vil bli overskrevet av DirSync. Har du en bruker i ditt lokale AD med UPN user1@ateaedge.no og en manuelt opprettet bruker i Windows Azure Active Directory med samme UPN vil denne bli overskrevet.
Brukerkontoer fra domenet du har føderert, dvs de har UPN suffix likt ditt fødererte domene, vil ikke kunne endres i noen av portalene som benytter Windows Azure AD som identitesplatform. Alle endringer på disse brukerne må gjøres i ditt lokale AD og deretter synkroniseres til Windows Azure AD.
Du vil nå ha to typer brukere i Windows Azure AD; synkroniserte og skybrukere. Dette vil vises litt forskjellig avhengig av hvilken portal du benytter:
Office 365

Windows Azure AD:

For å bekrefte at DirSync fungerer som den skal må vi teste både automatisk og tvungen synkronisering. Automatisk synkronisering foregår hver tredje (3) time som standard så her må vi bare vente til neste intervall. Tvungen synkronisering kan gjøres på to måter; vha DirSync konfigurasjonsveiviseren og via PowerShell. Forberedelsene til testen er like for både automatisk og tvungen synkronisering.

For å teste DirSync, enten tvungen eller automatisk synkronisering; gjør en endring på en bruker som synkroniseres i ditt lokale Active Directory. Du kan endre feks:

Fornavn
Etternavn
Visningsnavn
Jobtittel
Avdeling
Kontornummer
Kontortelefon
Faxnummer
Gateadresse
By
Postnummer
Land eller region

Gjennomfør tvungen synkronisering på en av måtene beskrevet under. (Hvis du ønsker å teste automatisk synkronisering må du vente minst tre timer fra tidspunket du endret den lokale brukeren på.)

PowerShell

På serveren som kjøre Directory Sync tool, åpne Windows Explorer og gå inn i mappen %programfiles%\Microsoft Online Directory Sync.
Dobbeltklikk DirSyncConfigShell.psc1 filen og vent til Windows PowerShell kommer opp. Dette nye PowerShell-konsollet har Directory Sync PowerShell cmdlets lastet.
Kjør Start-OnlineCoexistenceSync.
(Det kan være lurt å lage en snarvei til psc1-filen på skrivebordet.)

Konfigurasjonsveiviser

På maskinen som kjører Directory Sync tool, klikk Start, klikk All Programs, klikk Microsoft Online Services, klikk Directory Synchronization, klikk så Directory Sync Configuration.
Følg veiviseren og legg inn de nødvendige brukernavn og passord.
På Finish siden, la valget i Synchronize directories now boksen stå, og trykk så Finish.

Logg på en av portalene som benytter Windows Azure AD, eller kjør MSOL PowerShell og se på brukeren du endret.

Directory Sync tool logger aktivitet i Application-loggen på serveren hvor det kjører. Kilden til hendelsene er Directory Synchronization. En hendelse med ID 4 og beskrivelsen The export has completed indikerer at en directory sync er fullført. ID 5 viser antall endrede objekter.

I neste, og siste, del skal vi se på feilsøking og hvordan hele løsningen fungerer sammen.

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

Morgan Simonsen — Mon, 08 Apr 2013 11:26:00 GMT

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:

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:

Installer Windows Server 2012 på to maskiner. I vårt eksempel er dette aeaadfssql1 og aeaadfs1.
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.
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.
Legg til ADFS rollen på ADFS primærserveren (aeaadfs1) og ADFS Proxyen (aeaadfsproxy1):
Add-WindowsFeature -Name ADFS-Federation –IncludeManagementTools
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.
Identifiser service-sertifikatets thumbprint. Du trenger dette for å konfigurere ADFS:
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:

Installer Windows Server 2012 på ADFS Proxy serveren (aeaadfsproxy1).
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.
Legg til ADFS rollen på ADFS Proxyen (aeaadfsproxy1):
Add-WindowsFeature -Name 'ADFS-Proxy' -IncludeManagementTools
Eksporter ADFS service sertifikatet, inkludert den private nøkkelen, fra ADFS primærserveren og importer det på ADFS Proxyen.
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:

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.
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.
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>
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.
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:

Verify and manage single sign-on with AD FS 2.0

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)

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. Gå til Microsoft Online portalen.
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).
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:

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.

Gå til Microsoft Remote Connectivity Analyzer.
Velg Office 365 fanen og deretter Microsoft Single Sign-On, trykk Next.
Skriv inn brukernavn og passord, trykk Perform Test.
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.