Nyligen implementerade vi en lösning på en Windows-terminalserver. Som vanligt skickade vi genvägar till anställdas skrivbord för att ansluta och sa – arbeta. Men användarna blev skrämda när det kom till cybersäkerhet. När de kopplade upp sig mot servern, med meddelanden som: "Litar du på den här servern? Är du helt säker?", blev de rädda och vände sig till oss – är allt okej, kan vi trycka på OK? Då beslöts det att göra allt snyggt så att det inte skulle finnas några frågor eller panik.

Om dina användare fortfarande kommer till dig med sådana rädslor, och du är trött på att sätta kryss i "Fråga inte igen" – välkommen under pressen.

Steg noll. Förberedelse och frågor om förtroende

Så vår användare klickar på den sparade filen med .rdp-tillägget och får en sådan begäran:

Ett "skadligt" anslutning.

För att bli av med detta fönster används ett speciellt verktyg som heter RDPSign.exe. Fullständig dokumentation finns, som vanligt, på den officiella webbplatsen, och vi kommer att gå igenom ett exempel på användning.

Först behöver vi ta ett certifikat för att signera filen. Det kan vara:

• Publikt.
• Utfärdat av en intern certifikatmyndighet.
• Helt självsignerat.

Det viktigaste är att certifikatet har möjlighet att signera (ja, det går att få tag i
från revisorerna med E-legitimation), och att klientdatorerna har förtroende för det. Här kommer jag att använda ett självsignerat certifikat.

Jag vill påminna om att förtroende för ett självsignerat certifikat kan organiseras med hjälp av grupprinciper. Lite mer detaljer — under spoilern.

Hur man gör certifikatet betrott med hjälp av GPO-magi

Först måste vi ta det befintliga certifikatet utan privat nyckel i .cer-format (detta kan göras genom att exportera certifikatet från "Certifikat"-snapin) och placera det i en nätverksmapp som användarna kan läsa. Efter det kan grupprincipen konfigureras.

Import av certifikatet konfigureras i avsnittet: Datorkonfiguration — Policies — Windows-konfiguration — Säkerhetsalternativ — Nyckelpolicies — Betrodda rotcertifikatutfärdare. Högerklicka för att importera certifikatet.

Den konfigurerade policyn.

Nu kommer klientdatorerna att lita på det självsignerade certifikatet.

Om problemen med förtroendet är lösta, går vi direkt till frågan om signering.

Steg ett. Skriv filen tydligt.

Certifikatet finns, nu behöver vi ta reda på dess fingeravtryck. Vi öppnar det bara i verktyget "Certifikat" och kopierar på fliken "Innehåll".

Det fingeravtryck vi behöver.

Bäst är att direkt formatera det korrekt – endast stora bokstäver och utan mellanslag, om det finns några. Detta kan enkelt göras i PowerShell-konsolen med kommandot:

("6b142d74ca7eb9f3d34a2fe16d1b949839dba8fa").ToUpper().Replace(" ","")

När vi har fingeravtrycket i rätt format kan vi säkert signera rdp-filen:

rdpsign.exe /sha256 6B142D74CA7EB9F3D34A2FE16D1B949839DBA8FA .contoso.rdp

Där .contoso.rdp är den absoluta eller relativa sökvägen till vår fil.

När filen är signerad kan vi inte längre ändra vissa parametrar via ett grafiskt gränssnitt, såsom servernamnet (annars, varför signera?). Om vi ändrar inställningarna i en textredigerare förlorar vi signaturen.

Nu kommer meddelandet vid dubbelklick på genvägen att vara annorlunda:

Nytt meddelande. Färgen är mindre farlig, nu har vi framsteg.

Låt oss också bli av med det.

Steg två. Återigen frågor om förtroende

För att bli av med detta meddelande behöver vi återigen grupprinciper. Denna gång leder vägen till avsnittet Konfiguration av dator — Policyer — Administrativa mallar — Windows-komponenter — Tjänster för fjärrskrivbord — Klient för fjärrskrivbord — Ange SHA1-certifikatets fingeravtryck som representerar betrodda RDP-utgivare.

Den politik vi behöver.

I policyn räcker det med att lägga till det redan kända fingeravtrycket från föregående steg.

Det är värt att notera att denna policy åsidosätter policyn "Tillåt RDP-filer från betrodda utgivare och användarinställningar för RDP, som anges som standard".

Den konfigurerade policyn.

Voilà, nu inga konstiga frågor – bara begäran om inloggning och lösenord. Hmm…

Steg tre. Transparent inloggning på servern

Verkligen, om vi redan har loggat in på en domändator, varför ska vi ange samma inloggning och lösenord igen? Låt oss överföra autentiseringsuppgifterna till servern "transparent". I fallet med enkel RDP (utan användning av RDS Gateway) hjälper grupprincipen oss.

Vi går till avsnittet: Konfiguration av dator — Policyer — Administrativa mallar — System — Överföring av autentiseringsuppgifter — Tillåt överföring av autentiseringsuppgifter som är inställda som standard.

Här kan du lägga till de nödvändiga servrarna i listan eller använda wildcard. Det kommer att se ut så här TERMSRV/trm.contoso.com eller TERMSRV/*.contoso.com.

Den konfigurerade policyn.

Nu, om vi ser på vår genväg, så kommer den att se ut ungefär så här:

Användarnamn kan inte ändras.

Om RDS Gateway används måste du också tillåta datatransfer på den. För detta måste du i IIS-hanteraren under "Autentiseringsmetoder" stänga av anonym autentisering och aktivera Windows-autentisering.

Konfigurerad IIS.

Kom ihåg att starta om webbservicen med kommandot:

iisreset /noforce

Nu fungerar allt bra, inga frågor och förfrågningar.

Endast registrerade användare kan delta i omröstningen. Logga in, tack.

Berätta, skriver du ut RDP-genvägar till dina användare?

• 43%Nej, de är vana vid att klicka på "OK" i meddelanden utan att läsa, vissa sätter till och med själva kryss i "Fråga inte igen".

• 29.2%Jag lägger själv försiktigt genvägen och gör första inloggningen på servern tillsammans med varje användare.

• 6.1%Självklart, jag älskar ordning i allt.

• 21.5%Jag använder inte terminalservrar.

65 användare röstade. 14 användare avstod.

Källa: habr.com