Innledning
Jeg husker da Windows 2000 Server ble utgitt. En av de tingene som jeg var ute mest frem til var IPsec. Med IPsec støtte bakt rett inn i operativsystemet, vil jeg være i stand til å sikre forbindelsene mellom alle datamaskinene på nettverket. Ikke lenger vil jeg trenger å bekymre deg noen med et nettverk sniffer stjele passord, brukernes navn og søknadsinformasjon som den beveget seg over ledningen. Mens IPsec kunne ha gjort dette mulig, det viste seg å være for komplisert, for begrenset, og ærlig, for mye av en smerte i nakken for å få det til å fungere.
Med Windows Server 2003, fikk ting til være litt enklere. Mens Windows 2000 Server krevd at du kjøre IPsec veiviseren på hver av maskinene som du ønsket å aktivere IPsec politikk, Windows Server 2003 kan du bruke Group Policy, i form av anIPsec Group Policy snap-in, for å konfigurere IPsec policy for Windows Server 2003 og Windows XP på nettverket. Med Active Directory aktivert Group Policy, kan du skalere IPsec politikk. Men den samme kompleksiteten i IPsec konfigurasjonsveiviseren som vi hadde med Windows Server 2000 IPsec-konfigurasjon fortsetter med Windows Server 2003 og Windows XP.
IPsec er en del av Windows TCP /IP-stakken, med IPsec driveren være et meget lavt nivå driver. IPsec-policy, som navnet tilsier, er pålagt på nettverkslaget, før noen av applikasjonslaget data er mottatt av et system. Når du konfigurerer en IPsec-policy, du faktisk konfigurere IPsec regler som bestemmer:
- hva trafikk burde ha IPsec-beskyttelse aktivert på det,
- om trafikken skal tillates eller blokkeres,
- hvis trafikken er tillatt, om det skal kreve autentisering eller kryptering, og
- hvis autentisering og /eller kryptering er nødvendig, hva slags godkjenning eller kryptering skal brukes.
Det er andre innstillinger også, for eksempel en som definerer kilden og målet adresse eller nettverket som politikken bør påføres.
Mens jeg trodde IPsec var kult og en av grunnene til å bli begeistret for Windows 2000 Server, at spenningen ikke generalisere til den generelle samfunnet, mest sannsynlig for grunnene til at jeg nevnt ovenfor. Men det syntes å være et brak i IPsec veien som rystet ting opp litt rundt 2005, da Microsoft begynte å publisere informasjon om Server og Domain Isolation (SDI). Visjonen rundt SDI var at du kunne logisk segment nettverket for å beskytte dine domene eiendeler fra vertene av lavere tillit. Løftet om SDI var at du kunne logisk segment høy verdi eiendeler fra lavere verdi midler (eller høy tillit eiendeler fra lavere tillit eiendeler) i stedet for fysisk isolere disse sikkerhetssoner fra hverandre. Evnen til logisk segment med IPsec som sikkerhetsgrense virket veldig attraktivt og potensielt en stor kostnad saver.
SDI hørtes svært attraktiv på papir. Men som de sier, er djevelen i detaljene, og det viste seg at djevelen var levende og godt. For å skape en effektiv SDI løsning, måtte du opprette et stort antall regler, noe som resulterte i en svært kompleks distribusjon scenario. Det var komplisert, ikke bare i sin utforming, men også i den løpende forvaltningen. Du måtte lage et stort antall regler, og så måtte du lage enda flere regler som skapte unntak fra reglene du allerede hadde opprettet. Potensialet for en "floke av regler" ligner på en dårlig forvaltet datasenter sin floke av ledninger var normen og administratorer mistet interessen for SDI over tid.
Alle vet at det noen ganger tar Microsoft et par prøver å få ting riktig . De ønsket ikke å gi opp drømmen om hva IPsec kan levere til IT-administratorer, så de tok en titt på problemene med hvordan IPsec ble iverksatt, og bestemte seg for å løse noen av disse problemene. Dette førte til utviklingen av AuthIP - en implementering av IPsec som har forbedringer i Internet Key Exchange (IKE) protokoll som fikset noen av de viktigste begrensningene i tidligere versjoner av IPsec. AuthIP ble først introdusert med Vista og Windows Server 2008, og er også inkludert i Windows 7 og Windows Server 2008 R2.
AuthIP Utvidelser av IPsec
AuthIP er faktisk et sett med utvidelser til IKE-protokollen som inkluderer nye flagg og forhandlingsmetodene for å øke nytten av IPsec. AuthIP kan brukes med datamaskiner som kjører Vista, Windows 7, Windows Server 2008 og Windows Server 2008 R2. Og hvis disse datamaskinene må bruke IPsec å kommunisere med down-level datamaskiner som ikke støtter AuthIP, kan de ikke klarer tilbake til å bruke IKE.
AuthIP gjør følgende funksjoner som ikke var tilgjengelig med tidligere versjoner av IKE:
- Godkjenner hjelp av en rekke protokoller eller metoder
bruksområder mer effektiv protokoll forhandling - Bruker flere sett av legitimasjon for å autentisere
autentisere brukere på nye måter
Hvis du husker hvordan autentisering jobbet med tidligere versjoner av IPsec, du vet at godkjenning var basert på data legitimasjon. Du hadde to valg for datamaskin autentisering: datamaskin sertifikatgodkjenning eller datamaskin konto autentisering ved hjelp av Kerberos. Oh, kan du også bruke en forhåndsdelt nøkkel, men det er ganske lavt i næringskjeden når det gjelder skalerbarhet og sikkerhet. Hvis du ønsket å kontrollere hvilke brukere som hadde tilgang til en server applikasjon, du måtte forholde seg til brukerautentisering på applikasjonsnivå - noe som medførte klarerte brukere fra pålitelige maskiner potensielt kan utnytte et angrep på nettverksnivå mot server hosting anvendelsen av interesse .
Med AuthIP, kan du kontrollere tilgangen av datamaskinkonto, brukerkonto eller begge deler. Dette styrker godkjenning til et lavere nivå i TCP /IP-stakken, slik at du nå ikke trenger å være avhengig av applikasjonen å autentisere brukeren. Med AuthIP, kan du autentisere brukeren på nettverkslaget og beskytte programmet fra nettverkslaget angrep som skjedde før programmet laget autentisering foregår
Du kan bruke følgende metoder for brukerautentisering med AuthIP.
- Computer helseattest, som brukes av Network Access Protection (NAP)
- Brukersertifikat (klientsertifikat i brukersertifikatet butikken)
- NTLMv2 for den påloggede brukeren konto
- Kerberos for logget på brukerkontoen
Autentisering ved hjelp av ulike metoder
AuthIP åpner opp distribusjon scenarier ikke tilgjengelig med tidligere versjoner av IPsec. For eksempel finnes det situasjoner der du trenger for å støtte forskjellige godkjenningsmetoder på hver side av forhandling. Å legge frem et eksempel, kanskje ett medlem av IPsec peer forhandling støtter autentisering mens den andre siden støtter datamaskinkontoen godkjenning. Dette scenariet ville mislykkes i tidligere versjoner, men er aktivert som AuthIP.
For eksempel vurdere en situasjon hvor du ønsker å bruke IPsec å sikre kommunikasjon mellom en server i DMZ og en server som ligger i datasenteret. Serveren i DMZ er i en skog som har en enveis tillit med datasenteret serverens skogen slik at DMZ skogen stoler datasenteret skogen, men datasenteret skogen ikke stoler DMZ skogen. Dette tillater brukere i datasenteret skogen for å koble til DMZ-server ved hjelp av bruker eller data legitimasjon, men ikke tillater brukere i DMZ skogen for å koble til datasenter ressurser ved hjelp av datamaskin eller brukerlegitimasjon.
Men har du utplassert sertifikater på begge serverne og hver server har klarert andre serverens sertifikat. Med AuthIP kan du nå støtte scenarier der autentiserer jevnaldrende bruker ulike metoder for godkjenning. I dette scenariet, når datasenteret serveren autentiserer sin IPsec tilkobling til DMZ serveren, vil den bruke bruker eller datamaskin konto Kerberos-godkjenning. Når DMZ serveren autentiserer til datasenter server, vil den bruke datamaskin eller brukersertifikat godkjenning. Selv om hver av IPsec jevnaldrende bruker en annen autentiseringsmetode, kan de likevel etablere en IPsec-tilkobling fordi målet er vellykket autentisering, ikke bare vellykket autentisering ved hjelp av samme autentiseringsprotokoll.
Forhandle mer effektivt
Som jeg nevnt ovenfor, med tidligere versjoner av IPsec (IKE) du kan autentisere basert på datamaskinkonto ved hjelp av enten databevis eller datamaskinkontoen bruker Kerberos. Men hvis den foretrukne metoden for autentisering mislyktes, deretter hele IPsec forhandling mislyktes.
Tenk deg at du har to datamaskiner som du ønsker å bruke IPsec å beskytte kommunikasjon mellom dem. Disse to datamaskiner tilhører forskjellige skoger og det er ingen tillit mellom skogene. Men har du utplassert databevis til begge disse vertene, og befolket Klarerte rotsertifiseringsinstanser 'sertifikat butikker, slik at hver maskin klarerer den andre maskinens sertifikat. Men med tidligere versjoner av IKE, vil IPsec forhandlinger i dette scenariet mislykkes fordi etter ikke Kerberos-godkjenning, vil de potensielle IPsec partnere ikke prøve å bruke datamaskinen autentisering.
AuthIP løser dette problemet ved at forhandling av godkjenning metoder. Hvis en metode mislykkes, kan du konfigurere IPsec å bruke andre metoder, og IPsec jevnaldrende vil fortsette å forhandle godkjenningsmetoder før de finner en felles. Dette åpner betydelig opp antall scenarier der du kan distribuere IPsec og gjør hele løsningen mer håndterlig og lettere å konfigurere.
bruker mer enn et enkelt sett med legitimasjon for å Verifisere
Som du kanskje har antatt fra å lese de ulike nye scenarier som støttes av AuthIP, kan du bruke flere legitimasjon for å godkjenne IPsec jevnaldrende. Du kan autentisere IPsec jevnaldrende som bruker data legitimasjon, brukerlegitimasjon, eller begge bruker og datamaskin legitimasjon. Hvis du vet om Direct, den nye fjerntilgang teknologi tilgjengelig med Windows 7 Enterprise /Ultimate Edition og Windows Server 2008 R2, kan du vite at infrastrukturen tunnel bruker datamaskinen sertifikat og datamaskinkontoen NTLMv2-godkjenning, mens intranett tunnel bruker datamaskinen sertifikat og bruker konto Kerberos-godkjenning. Ved å legge til brukerlegitimasjon til autentiserings mix, kan du beskytte servere fra ondsinnede brukere som kanskje bruker en pålitelig maskin.
Et annet scenario er aktivert av flere legitimasjon støtte er NAP. Med NAP, er en datamaskin helseattest brukes til å godkjenne en datamaskin for å bevise at det er et domenemedlem og er i samsvar med nettverk helsepolitikk. Disse legitimasjon kan stables oppå maskinen og brukerkonto godkjenning hvis du liker; AuthIP gjør dette mulig.
Domain Controller støtte nå Gjør Server og Domain Isolasjon Mulig for resten av oss
En av grunnene IPsec ble ikke brukt mye i det siste var problemet med domenekontrollere. Hvis du ønsker å bruke IPsec på nettverket med tidligere versjoner av IPsec, måtte du unnta domenekontrollere fra IPsec politikk. Grunnen til dette var at for å godkjenne en datamaskin, måtte du ha tilgang til DC, og hvis du ikke får tilgang til DC, kan du ikke autentisere - så du kjørte inn i den klassiske "høna og egget" paradoks .
Windows Server 2008 og nyere, og Vista og nyere løse dette problemet ved å aktivere følgende:
- Du trenger ikke lenger å lage unntak for domenekontrollere, som du kan konfigurere IPsec å bestemme når du skal bruke IPsecin kommunisere med domenekontrollere.
- Datamaskiner som kjører Vista og nyere, og Windows Server 2008 og oppover kan bli spurt om legitimasjon når du kobler til en domenekontroller - dette løser gamle "domene join" problem der du trengte å unnta en datamaskin fra IPsec beskyttelse hvis du ønsket å bli en datamaskin til domenet. Ved å aktivere spørre om legitimasjon, kan ikke-domene datamaskiner be om legitimasjon for å etablere IPsec økten.
- For klienter på lavere nivå, kan du enkelt lage politikk (uten å måtte lage unntaksregler) som forespørsel IPsec beskyttelse, men ikke krever det.
Disse forbedringene i intradomainIPsec forhandlingene gå en lang vei mot å gjøre IPsecdeployment faktisk mulig på nett i dag.
Sammendrag
IPsec ble først introdusert med Windows 2000 Server. Mens det holdt en rekke lover, var det en rekke av grunnene til at det tok ikke holde på bedriftsnettverk. Med introduksjonen av Vista og Windows Server 2008 (og deretter Windows 7 og Windows Server 2008 R2), har du nå tjenester av AuthIP, noe som forbedrer fleksibilitet og administrasjon av IPsec. Nå har du kraftige autentiseringsmekanismer som er lett å konfigurere ved hjelp av Group Policy basert administrasjonsverktøy som lar deg lage robuste og kraftige IPsec politikk uten kompleksiteten som frarådes bruk av tidligere versjoner av IPsec. Kombinasjonen av nye brukerautentisering alternativer, muligheten til å bruke flere bevis, mer fleksibel autentisering forhandling og muligheten for hver side til å bruke forskjellige godkjenningsmetoder gjør AuthIP den salve som IPsec nødvendig for å bryte gjennom og finne sitt fulle potensial.
godkjenner brukere på nye måter - Godkjenner hjelp av en rekke protokoller eller metoder