Secure Ticket Authority

Bemærk: de samme principper og koncepter gælder også for NetScaler.

denne artikel besvarer nogle ofte stillede spørgsmål vedrørende Sta (Secure Ticket Authority). Spørgsmålene er opdelt i følgende fire kategorier:

oversigt

spørgsmål: Hvad er den sikre Billetmyndighed?
spørgsmål: Hvilke produkter interagerer med STA?
spørgsmål: Hvorfor er STA nødvendig?
spørgsmål: Hvordan implementeres STA-tjenesten?
r: Er der en version af STA, der ikke kræver IIS?
spørgsmål: Hvor bor STA-serveren?
spørgsmål: Hvad er forskellene mellem forskellige versioner af STA?

sikkerhed

spørgsmål: Hvordan genereres STA-billetten?
spørgsmål: Hvad udgør en sta-billet?
spørgsmål: er billetten valideret mod arbejdsstationen?
spørgsmål: slettes billetten efter brug?
spørgsmål: er billetter nogensinde skrevet til Disk på STA?
spørgsmål: er det muligt for nogen at kapre en billet?
spørgsmål: Hvordan beskytter jeg STA-trafikken med SSL?
r: Skal STA altid adresseres ved hjælp af et fuldt kvalificeret domænenavn?
spørgsmål: Hvordan ændrer jeg STA-porten fra 80 til noget andet?
spørgsmål: kan en angriber sende tilfældige billetter til Porten for at logge på?
spørgsmål: Hvilke andre oplysninger kræves for at logge på andet end en gyldig STA-billet?
spørgsmål: Hvordan kan vi indstille levetiden for STA-billetten, hvorefter billetten skal være ugyldig?

skalerbarhed

spørgsmål: Hvor mange STAs har jeg brug for?
r: Logger brugerne gennem porten om morgenen og kører en enkelt offentliggjort applikation hele dagen, eller lancerer de flere applikationer hele dagen?
spørgsmål: Hvordan kan jeg sikre Sta fejltolerance?
spørgsmål: Hvordan indlæser jeg Balance multiple STAs?
spørgsmål: Kan jeg bruge flere STAs med Microsoft netværk Load Balancing?
spørgsmål: Kan jeg dele en enkelt STA med flere gårde, portaler og Optællingsservere?

fejlfinding

spørgsmål: Hvordan skal IIS konfigureres til at være vært for STA?
spørgsmål: Hvordan aktiverer jeg logning på STA?
r: Hvorfor bryder Microsoft Iislock-værktøjet STA?
spørgsmål: Hvordan kan jeg teste STA for at være sikker på, at den fungerer korrekt?
spørgsmål: hvordan fortolker jeg STA-logfilerne?
spørgsmål: Hvad er nogle af de almindelige konfigurationsfejl, der ses af teknisk Support?

oversigt

spørgsmål: Hvad er den sikre Billetmyndighed?

A: Secure Ticket Authority (STA) er en internettjeneste, der udveksler oplysninger om serveren for tilfældigt genererede billetter. Det bruges til at kontrollere adgangen til en sikker server.

spørgsmål: Hvilke produkter interagerer med STA?

a: internetgrænseflade, butiksfacade, sikker adgangsstyring, NetScaler og sikker Port interagerer med STA. I hele denne artikel er følgende typer servere grupperet i en enkelt kategori kaldet application enumeration servers:

• 2.0 eller nyere
• Secure Access Manager 2.0 eller nyere
• StoreFront
• applikationstællingsservere er ansvarlige for at godkende brugere, opregne offentliggjorte applikationsikoner og producere en ICA-fil til en klient, der giver dem mulighed for at oprette forbindelse til en offentliggjort applikation via en sikker Portserver.

spørgsmål: Hvorfor er STA nødvendig?

A: i en sikker indgangsportal udfører indgangsportalserveren ikke godkendelse af indgående anmodninger. I stedet udsætter serveren autentificering til en applikationstællingsserver og bruger STA til at garantere, at hver bruger er godkendt. Applikationstællingsservere anmoder kun om billetter til brugere, der allerede er godkendt til internetserveren. Hvis brugerne har gyldige sta-billetter, antager portalen, at de har bestået autentificeringskontrollerne på internetserveren og bør have adgang.

dette design giver Dig mulighed for at arve alle godkendelsesmetoder på din internetserver. Hvis din Internetgrænsefladeserver f.eks. er beskyttet med RSA SecurID, er det kun SecurID-godkendte brugere, der kan køre gennem den sikre server.

spørgsmål: Hvordan implementeres STA-tjenesten?

A: STA er skrevet som en ISAPI-udvidelse til Microsoft Internet Information Services (IIS). Udvidelsen kaldes Ctkssta.dll og er hostet i mappen / Scripts som standard. Andre komponenter kommunikerer med STA ved hjælp af HTTP.

Applikationstællingsservere anmoder om billetter ved applikationsstart ved at sende data til STA som en del af en billetanmodning. De data, der sendes til STA, inkluderer adressen på den Ksenapp-Server, som brugeren vil oprette forbindelse til, og i tilfælde af Internetgrænseflade 2.0 og Secure Access Manager 2.0 udvidede oplysninger om navnet på den aktuelle bruger og den offentliggjorte applikation, som brugeren ønsker at køre. STA reagerer ved at generere en billet og sende den tilbage til applikationstællingsserveren. Denne billet og dens tilsvarende data forbliver i hukommelsen på STA i et konfigurerbart antal sekunder (100 som standard).
applikationstællingsserveren konstruerer en ICA-fil til brugeren og indsætter STA-billetten i adressefeltet i Ica-filen. Når klienten opretter forbindelse til den sikre Port, præsenteres billetten, og porten skal validere billetten, inden der oprettes en sikker session for klienten. Porten udfører en dataanmodning ved at sende billetten tilbage til STA og bede om dens tilsvarende data til gengæld. Hvis det lykkes, videresender STA de oprindelige data til porten, og porten opretter et relæ mellem slutbrugeren og serveren.

både billetanmodninger og dataanmodninger udføres som dokumenter til anmodning/svar.

spørgsmål: er der en version af STA, der ikke kræver IIS?

A: Nej, På dette tidspunkt er IIS forpligtet til at være vært for STA. Husk, at STA ikke behøver at blive udsat for et usikkert netværk som internettet; STA ‘ en er placeret på dit betroede netværk og er kun tilgængelig via portalserverne og applikationstællingsserverne.

spørgsmål: Hvor bor STA-serveren?

A: STA-serveren kan placeres hvor som helst, så længe den sikre Port og applikationstællingsservere kan nå den. Vi anbefaler at placere STA på det betroede netværk eller på et separat ben af din interne brandvæg, men der er ingen andre krav til STA-serveren end IIS. STA behøver ikke at tilhøre et domæne, en serverfarm, en Secure Access Manager-gård eller en anden intern server, men det er almindelig praksis at dele STA med en anden funktion. En STA inkluderes automatisk som en del af Secure Access Manager 2.0-opsætningen; mange administratorer finder det praktisk at finde STA på en server.

spørgsmål: Hvad er forskellene mellem forskellige versioner af STA?

A: der er ingen væsentlige funktionelle forskelle mellem Version 1.0 og 1.1, men når du bruger 2.0 STA med Internetgrænseflade 2.0 eller Secure Access Manager 2.0, udvidet information tilføjes til billetanmodningen: navnet på brugeren og det program, brugeren ønsker at køre. Disse udvidede data forbruges af portaltjenesten for at få vist oplysninger om hver portsession i administrationskonsollen Secure port 2.0.

hvis Secure portal 2.0 er konfigureret til at bruge en ældre STA fra Version 1.1 eller 1.0, kan brugerne oprette forbindelse til applikationer, men secure portal management console viser “N/A” for brugernavnet og applikationsnavnet, der er knyttet til hver ICA-session. For at se de udvidede oplysninger i den sikre Port 2.0 administrationskonsol, skal du bruge Version 2.0 eller nyere af STA og bruge enten Secure Access Manager 2.0 eller Internet Interface 2.0 som din applikationstællingsserver.

sikkerhed

spørgsmål: Hvordan genereres STA-billetten?

A: ISAPI-udvidelsen.dll bruger pseudo-tilfældig talgenerering til at producere en 16-byte seksadecimal streng. Af sikkerhedsmæssige årsager, er ikke afsløre de nøjagtige trin, der anvendes til at producere denne tilfældige sekvens af tegn.

spørgsmål: Hvad udgør en sta-billet?

A: kodningsformatet er en streng af formularen:

;STA_VERSION; STA_ID; billet

hvor:

• STA_VERSION er et numerisk felt, der identificerer versionen af STA. I øjeblikket er de eneste gyldige værdier for dette felt “10 “for sta Version 1.0 og 1.1 og” 20 ” for STA Version 2.0.
• STA_ID er en sekvens af 0 – 16 tegn, der repræsenterer et vilkårligt navn tildelt af administratoren til en bestemt STA. I Version 1.denne streng er standard til STA01, STA02 osv. Når STA installeres automatisk som en del af Secure Access Manager 2.0, er STA ID et hash af servernavnet. Når flere STA ‘ er deles af en enkelt server, skal hvert STA-ID være unikt. Dette gør det muligt for Porten at finde den STA, der oprettede billetten, og vende tilbage til den STA for billetvalidering. En billet oprettet på STA01 findes ikke på STA02.
• TICKET er en tilfældigt genereret sekvens af 32 store bogstaver alfabetiske eller numeriske tegn.

  for eksempel:
  ; 10; STA01; FE0A7B2CE2E77DDC17C7FD3EE7959E79

spørgsmål: er billetten valideret mod arbejdsstationen?

A: Nej, der er intet, der binder en billet til en bestemt arbejdsstation. Det er teoretisk muligt at anmode om en billet fra arbejdsstation A og derefter bruges fra arbejdsstation B. For at mindske denne risiko:

• Brug altid HTTPS mellem klienten og applikationstællingsserveren for at forhindre en Angriber i at opfange billetten, når den rejser fra server til klient.
• reducer ticket time-to-live så meget som muligt for at reducere den tid, en angriber skulle overføre billetten fra maskine A til maskine B.

Husk, at en billet udstedt af STA kun kan bruges en gang, så hvis den tilsigtede bruger på maskine a opretter forbindelse, er billetten ugyldig for alle fremtidige forbindelsesforsøg fra maskine A eller maskine B.

spørgsmål: slettes billetten efter brug?

A: Ja, billetter renses straks efter en vellykket dataanmodning, så de kun kan bruges en gang. De slettes også efter en konfigurerbar time-out (Standard 100 sekunder), hvis ikke brugt.

spørgsmål: er billetter nogensinde skrevet til Disk på STA?

A: Kun når verbose logging er aktiveret ved at indstille LogLevel=3 i Ctsta.konfigurationsfil. Ellers opretholder STA alle udestående billetter (billetter, der blev anmodet om af en applikationstællingsserver, men endnu ikke valideret af en sikker Port) ved hjælp af en database i hukommelsen. Data sendes altid til STA ved hjælp af HTTP POST-kommandoen, så ingen meningsfulde billetdata skrives nogensinde til STA-serverlogfilerne.

spørgsmål: er det muligt for nogen at kapre en billet?

A: under normal drift skal en billet rejse følgende fire segmenter af netværket:

• fra STA til applikationsnummerationsserveren
• fra applikationsnummerationsserveren til klienten
• fra klienten til den sikre Portserver
• fra porten til STA

de første og sidste segmenter findes kun mellem servere i din enhed og STA på din betroede server netværk, hvilket betyder, at en ubuden gæst skal have adgang til dit netværk for at opfange billetten i den retning. Alligevel kan disse veje krypteres med SSL, hvis du bruger sikker Port Version 2.0. I Den Sikre Port 1.1 og tidligere kan trafik til STA ikke krypteres ved hjælp af SSL.

for at sikre det andet segment skal du lægge et certifikat på din applikationsnummerationsserver og kun tillade klienter at oprette forbindelse, hvis de bruger HTTPS. Det tredje segment er altid sikret med SSL.

selv når alle de foregående links er sikret med SSL, er klienter stadig sårbare over for angreb fra trojanske programmer, der overvåger klientaktivitet. For at mindske denne risiko, rådgive dine brugere til at oprette forbindelse fra maskiner, hvor anti-virus og Trojan afsløring program er installeret.

spørgsmål: Hvordan beskytter jeg STA-trafikken med SSL?

A: Installer først et Internetservercertifikat på kopien af IIS, der er vært for STA. Du kan finde flere oplysninger i IIS-dokumentationen.

Konfigurer din applikationstællingsserver og den sikre Portserver til at bruge HTTPS, når du kommunikerer med porten. Ved tilslutning via HTTPS skal følgende regler altid være opfyldt:

• du skal adressere STA ved hjælp af et fuldt kvalificeret domænenavn, der matcher emnet for STA-servercertifikatet.
• maskinen, der kommunikerer med STA, skal kunne løse sta ‘ s fuldt kvalificerede domænenavn til en passende IP-adresse.
• maskinen, der kommunikerer med STA, skal have tillid til Certifikatmyndigheden (CA), der udstedte STA-servercertifikatet.
• for at opfylde kravene i det tredje punkttegn skal CA-rodcertifikatet installeres på den sikre Portserver og på applikationstællingsserveren. Vær forsigtig, når du installerer rodcertifikatet: du kan ikke blot dobbeltklikke på en rodcertifikatfil og køre guiden certifikatimport.

(dette indikerer, at din brugerkonto, ikke serveren eller nogen systemtjenester, stoler på CA.) Følg trinnene for at installere et rodcertifikat til brug med:

1. Kør Mmc.Tilføj snap-in ‘ en certifikater.
2. når du bliver spurgt, hvilke certifikater der skal administreres, skal du vælge computerkonto og derefter lokal Computer.
3. Udvid certifikaterne (lokal Computer) > Trusted Root Certification Authority node. Højreklik på certifikater, og vælg derefter alle opgaver > Import.
4. Gennemse for at vælge dit CA root-certifikat og fuldføre importguiden.

spørgsmål: skal STA altid adresseres ved hjælp af et fuldt kvalificeret domænenavn?

A: hvis du har til hensigt at sikre trafik til STA ved hjælp af SSL, skal enhver komponent, der får adgang til STA, inklusive din server og applikationstællingsserver, adressere STA ved hjælp af det fuldt kvalificerede domænenavn (FDN), der matcher emnet for det servercertifikat, der bruges af IIS på STA. For eksempel i Internetgrænseflade 2.0 ville STA-adressen blive indtastet som:https://sta-server.company.com/Scripts/CtxSta.dll

hvis du vælger ikke at sikre trafik til STA ‘en, kan du adressere STA’ en ved hjælp af en IP-adresse, værtsnavn eller FKDN.

spørgsmål: Hvordan ændrer jeg sta-porten fra 80 til noget andet?

A: fordi STA betjenes af IIS, ændrer du STA-porten, når du ændrer IIS-porten. Følgende eksempel illustrerer, hvordan du ændrer IIS-porten fra 80 til 81.

1. åben Internet Services Manager.
2. Højreklik på standard hjemmeside og se egenskaberne.
3. på fanen hjemmeside skal du ændre TCP-portnummeret fra 80 til 81.
4. Klik på OK.
   den foregående ændring påvirker også alle andre ressourcer, du har offentliggjort fra STA-serveren. Hvis du vil ændre sta-kommunikationsporten uden at påvirke andre hjemmesider, der hostes af den samme internetserver, kan du oprette en ny hjemmeside i IIS med det ene formål at være vært for STA. Følgende er et eksempel på, hvordan du vil oprette en ny hjemmeside på port 81 til STA.
5. Opret en ny fysisk mappe som C:\ MYSTA på din server harddisk til at fungere som dokumentet rod til sta site.
6. Opret en undermappe under MYSTA kaldet Scripts. Flyt følgende filer fra din eksisterende STA til mappen nye Scripts:
   • Ctsta.dll
   • Ctsta.config
   • ctsmlss.TST
7. åben Internet Services Manager.
8. Højreklik på servernavnet og vælg Ny > hjemmeside.
9. Opret en ny hjemmeside kaldet “My STA site” og C:\MYSTA som dokumentets rodmappe.
10. se egenskaberne for din nye hjemmeside og ændre TCP-porten til 81.
11. Højreklik på mappen Scripts under min STA-side i Internet Services Manager og se egenskaberne. I afsnittet programindstillinger skal du ændre Køretilladelserne til “Scripts og eksekverbare filer.”

Bemærk: Du kan vælge et andet mappenavn end “Scripts”, men vær opmærksom på, at sikker Port og alle applikationstællingsservere som f.eks.dll så du bliver også nødt til at opdatere STA URL i indstillingerne på disse servere.

spørgsmål: kan en angriber sende tilfældige billetter til Porten for at logge på?

A: en angriber skulle gætte en gyldig billet og også indløse den inden for de få millisekunder, efter at klienten har anmodet om det, men før porten hævder det.

spørgsmål: Hvilke andre oplysninger kræves for at logge på andet end en gyldig STA-billet?

A: brugere har også brug for domæneoplysninger eller en Ksenapp-Serverbillet, der anmodes om af applikationstællingsserveren. (En sta-billet er ikke det samme som en STA-billet.) Tilfredsstillelse af STA åbner kun en sti til det betroede netværk for en bestemt server. Når der, skal brugeren stadig godkende med gyldige domæneoplysninger.
spørgsmål: Hvordan kan vi indstille levetiden for STA-billetten, hvorefter billetten skal være ugyldig?
A: Vi kan indstille sta-billetets levetid ved at oprette en følgende registreringsdatabasenøgle på Leveringscontrolleren:
placering: HKLM\program \ Citrick \ DesktopServer
navn: Hmlstaticketlifetimeinsekunder
Type: dord værdi: Giv værdi i sekunder (Decimal)
tag en sikkerhedskopi i registreringsdatabasen, før du redigerer registreringsdatabaseværdier, Bemærk også, at en ændring i registreringsdatabasen kræver en genstart på controllerens ende.

skalerbarhed

spørgsmål: Hvor mange STAs har jeg brug for?

A: STA er kun tilgængelig, når en bruger starter et program, svaret på dette spørgsmål varierer fra en implementering til den næste.

spørgsmål: logger brugerne gennem porten om morgenen og kører en enkelt offentliggjort applikation hele dagen, eller lancerer de flere applikationer hele dagen?

A: De opgaver, der udføres af STA, er ikke dyre i CPU-termer; det er en let tjeneste, der kun er begrænset af udførelsen af IIS. I en test understøttede en server med lav rækkevidde med en 1 GB processor og 256 MB RAM over 250 billetanmodninger i sekundet, mens CPU-udnyttelsen forblev under 60%.

spørgsmål: Hvordan kan jeg sikre Sta-fejltolerance?

A: følgende applikationstællingsservere giver dig alle mulighed for at indtaste flere Sta-URL ‘ er, når du konfigurerer parametrene til sikker Port:

• 2.0
• sikker adgang Manager 2.0
• StoreFront

i alle tilfælde, hvis en STA ikke reagerer, forsøger applikationstællingsserveren en anden STA på listen. Hver portserver skal igen konfigureres med STA URL og unikt STA ID for hver billetmyndighed.

spørgsmål: Hvordan indlæser jeg Balance multiple STAs?

A: der skal udvises særlig omhu ved belastningsbalancering af sikre Billetmyndigheder. En række forskellige metoder kan bruges til at indlæse balance mellem forbindelsen mellem en applikationstællingsserver og STAs, men en sikker Portserver skal altid kontakte hver STA individuelt baseret på dens STA-ID. Når du konfigurerer adressen på hver STA i konfigurationsværktøjet, skal hver STA — adresse være den rigtige adresse på STA-serveren-indtast ikke adressen på nogen udstyrsbelastningsbalancer, klyngenavn eller Round-robin DNS-navn her.

butiksfacade, Internetgrænseflade 2.0 og Secure Access Manager 2.0 Alle Understøtter round-robin belastningsbalancering af STAs, når flere STAs er angivet. Når denne indstilling er aktiveret, er der ikke behov for yderligere belastningsbalanceringsprogrammer eller-udstyr.

applikationstællingsservere kan bruge enhver form for belastningsbalancering til udstedelse af en billetanmodning, fordi hver modtaget billet indeholder et felt, der angiver det unikke ID for den STA, der genererede den. Så længe hvert STA-ID er unikt, og alle sta-servere kan løse STA-ID ‘ et til en bestemt (ikke belastningsbalanceret) serveradresse, lykkes operationen, og STA-trafik er belastningsbalanceret.

e: Kan jeg bruge flere STA ‘ er med Microsoft-Netværksbelastningsbalancering?

A: netværksbelastningsbalancering kan ikke bruges mellem den sikre Portserver og flere STA ‘ er. Hvis konfigureret på denne måde, brugere modtager intermitterende afslag, fordi, under billetvalideringsprocessen, porten kan være belastningsbalanceret til en myndighed, der oprindeligt ikke genererede brugerens billet.

spørgsmål: Kan jeg dele en enkelt STA med flere gårde, portaler og Optællingsservere?

A: Ja, en enkelt STA kan deles mellem et vilkårligt antal sikre Portservere og applikationstællingsservere. STA er ikke begrænset til et bestemt domæne, gård, eller applikationstællingsserver. Det er en anonym tjeneste.

fejlfinding

spørgsmål: Hvordan skal IIS konfigureres til at være vært for STA?

STA URL /Scripts/Ctsta.dll skal serveres med anonym adgang aktiveret. Hvis du peger på STA-URL ‘ en, bliver du ikke bedt om en adgangskode.

• du skal give tilladelse til Ressourceskripter og eksekverbare filer i IIS-metabasen. Denne tilladelse er ikke nødvendig for hele / Scripts-mappen, men kan indstilles til Ctsta.DLL fil individuelt.
• for sikker Portversion 1.1 og tidligere skal du ikke aktivere indstillingerne Kræv SSL og kræv 128-bit SSL.
• som standard er følgende kontotilladelser nødvendige:

på vinduer 2000 servere

• iusr_machinename-kontoen har brug for læseadgang til Ctsta.DLL.
• kontoens navn skal ændre adgangen til logfilmappen, som er \Inetpub\Scripts som standard.

på vinduer 2003 servere

• iusr_machinename-kontoen har brug for læseadgang til Ctsta.DLL.
• den indbyggede Netværkstjenestekonto skal ændre adgangen til logfilmappen, som er \Inetpub\Scripts som standard.

spørgsmål: Hvordan aktiverer jeg logning på STA?

A: brug notesblok til at redigere filen \Inetpub\Scripts\Ctsta.config på STA-serveren og find den linje, der siger LogLevel=0. For maksimal logning skal du ændre dette til LogLevel=3. Du skal genstarte Internetudgivelsestjenesten for at få ændringer til at træde i kraft.
Bemærk: Når du har aktiveret logning, skal den brugerkonto, under hvis myndighed STA udfører (IUSR_MachineName på vinduer 2000 eller netværkstjeneste på vinduer 2003 som standard) have skriveadgang til logfilmappen, som er \Inetpub\Scripts som standard. Du kan også ændre logfilmappen, når du redigerer.konfigurationsfil.

spørgsmål: Hvorfor bryder Microsoft Iislockeringsværktøjet STA?

A: Hvis du accepterer alle standardindstillingerne for iislockeringsværktøjet, er mappen / Scripts deaktiveret. STA implementeres som et ISAPI-filter udgivet som /Scripts/Ctsta.dll; ved at deaktivere / Scripts-mappen nægter du adgang til STA. Aktiver mappen / Scripts og Tillad Scripts og eksekverbare adgang for STA til at fungere.

spørgsmål: Hvordan kan jeg teste STA for at være sikker på, at den fungerer korrekt?

A: hvis du peger på STA-URL ‘ en, vil du enten se en tom hvid side eller meddelelsen “405 ressource ikke tilladt.”En af disse resultater indikerer en fungerende STA. Du kan kontakte STA på denne måde fra konsollen på din sikre Portalserver og også fra enhver applikationstællingsserver, der er konfigureret til at bruge porten. Hvis du modtager en godkendelsesdialogboks, der beder dig om en adgangskode, offentliggøres STA ikke anonymt, og godkendelseskravene skal fjernes.

for at kontrollere, at applikationstællingsserveren med succes anmoder om STA-billetter, skal du se på de Ica-filer, den genererer. 2.0, kan du højreklikke på et offentliggjort programikon og gemme resultatet som lancering.ica. Åben lancering.Ica i Notesblok og se adressen= linje. For normal sikker Portdrift vil Adresseparameteren indeholde en billet i stedet for en faktisk serveradresse.

spørgsmål: hvordan fortolker jeg STA-logfilerne?

A: hvis du aktiverer logning ved at indstille LogLevel=3 i Ctsta.config, du vil se detaljer om hver billet og dataanmodning modtaget af STA. Husk, at en billetanmodning genereres af en applikationstællingsserver som f.eks. Hvis logfilen viser flere billetanmodninger, men ingen dataanmodninger, indebærer dette, at applikationstællingsserveren kan nå STA, men den sikre Portserver kan ikke. Det kan også betyde, at brugerne ikke kan nå serveren.

under normal drift kan ICA-klientens sessionsdelingsfunktion få billetter til at blive anmodet om fra STA, men aldrig krævet af porten. Overvej følgende scenario:

• en bruger logger på Internetgrænsefladen og klikker på Outlook-ikonet. Internetgrænsefladen anmoder om en billet fra STA og sender den til brugeren i en ICA-fil.
• brugeren opretter forbindelse via sikker Port og præsenterer billetten til optagelse. Det er muligt for brugeren at oprette forbindelse til en Outlook-server.
• efter at have arbejdet i et par minutter vender brugeren tilbage til programlisten på Internetgrænsefladesiden og klikker på ikonet. Internetgrænsefladen anmoder om en anden billet fra STA og sender den til brugeren i en ICA-fil.
• før du opretter forbindelse til en ny server, kontrollerer Ica-klienten først, om eksisterende servere, som klienten allerede er tilsluttet, har det offentliggjorte program tilgængeligt.
• serveren, hvor klienten allerede kører Outlook, er også installeret, så Ica-klienten kasserer ICA-filen og starter Ica-sessionen.
• den anden billet, der anmodes om af Internetgrænsefladen, bruges aldrig, fordi en anden ICA-session ikke var nødvendig. Som standard går billetten ud efter 100 sekunder.

dette scenario ville resultere i en række sta logfilposter svarende til følgende:

CSG1305 Request Ticket - Successful 8DE802AE5A2F561233450B6CFD553035 ...CSG1304 Request Data - Successful 8DE802AE5A2F561233450B6CFD553035 ...CSG1305 Request Ticket - Successful 63EF3EAB182D846958143D19C1FDAEBA ...CSG1303 Ticket Timed Out 63EF3EAB182D846958143D19C1FDAEBA

mere mistænkelig aktivitet kan se sådan ud:

CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB804 CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB805 CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB806 CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB807 CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB808 CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB809

her ser vi, hvad der ser ud til at være en angriber, der prøver forskellige billetter en ad gangen og øger billet-ID ‘ et med hvert forsøg. I begge tilfælde blev forbindelsen afvist, og STA loggede en post, der angav, at klienten præsenterede en billet, der ikke blev anerkendt som gyldig. Hvis du vil identificere angriberens IP-adresse, skal du kigge efter følgende meddelelse i begivenhedsviseren på den sikre Portalserver:

CSG3207 Service received error from STA or Authentication Service , Client IP connection dropped.

fortolk ikke nogle” Ticket NOT found ” – meddelelser som et angreb. Ica-klienten kan forsøge at genoprette forbindelse til en afbrudt session, hvis brugerens netværksforbindelse tabes øjeblikkeligt. Auto Client Reconnect-funktionen fungerer ikke for brugere, fordi klienten under hvert genforbindelsesforsøg sender den brugte STA-billet, som den oprindeligt var tilsluttet. Klienten forsøger normalt at oprette forbindelse igen tre eller flere gange, før han giver op, så du vil se tre eller flere “Ticket NOT found” – meddelelser, der henviser til den samme billet i STA-loggen for hver forekomst af dette problem. Klientgenforbindelsesforsøg er kendetegnet ved forsøg på genbrug af en tidligere vellykket billet:

CSG1305 Request Ticket - Successful 766D558270CE32695903698AFA0F67A6 …CSG1304 Request Data - Successful 766D558270CE32695903698AFA0F67A6 …CSG1203 Request Data - Ticket NOT found766D558270CE32695903698AFA0F67A6 CSG1203 Request Data - Ticket NOT found766D558270CE32695903698AFA0F67A6 CSG1203 Request Data - Ticket NOT found766D558270CE32695903698AFA0F67A6

Afbryd forbindelsen til Auto Client Reconnect for sikre brugere ved at tilføje TransportReconnectEnabled=Off til sektionen af ICA-filen. Den rigtige måde at genoprette forbindelse til en afbrudt session, når du bruger sikker Port er at vende tilbage til applikationstællingsserveren og klikke på applikationsikonet igen.

spørgsmål: Hvad er nogle af de almindelige konfigurationsfejl, der ses af teknisk Support?

• mappen /Scripts eller hele Standardhjemmesiden er deaktiveret som et resultat af at køre Iislåsning eller overholde virksomhedens politik for beskyttelse af internetservere.
• logning er aktiveret.config, men den brugerkonto, under hvis myndighed STA udfører (iusr_machinename som standard) har ikke skriveadgang til logfilmappen.
• IIS på STA-serveren er konfigureret til at kræve SSL, men sikker Port er konfigureret til at få adgang til STA ved hjælp af normal HTTP.
• hvis app-lanceringen mislykkes, er det første, der skal kontrolleres, om STAs på StoreFront/Internetgrænseflade og NetScaler er angivet på nøjagtig samme måde eller ej, dvs.hvis STAs er angivet som IP-adresse på SF/vi, skal den gives ved hjælp af IP-adresse på NS og tilsvarende i tilfælde af FKDN.