Att använda en USB-dongel via RDP misslyckas ofta: enheten är ansluten lokalt, men det fjärrkörda programmet upptäcker den inte. Detta är ett vanligt problem med licensdonglar, USB-token och säkerhetsnycklar.
Orsaken är arkitektonisk. RDP:s USB-omdirigering fungerar bra för standardenheter men har svårt med specialiserad hårdvara som licensdonglar, certifikattoken och säkerhetsnycklar, som kräver en nivå av direkt enhetsåtkomst som RDP aldrig var utformat för att tillhandahålla. Windows erbjuder visserligen inbyggda alternativ som USB-passthrough och omdirigering av smartkort, men de är begränsade, kräver omfattande konfiguration och är ofta opålitliga för licenshårdvara.
För tillförlitlig åtkomst till donglar via fjärrskrivbord är en nätverksbaserad lösning som Donglify mer effektiv. Den delar USB-enheten över nätverket så att den visas som lokalt ansluten på fjärrmaskinen, vilket helt undviker begränsningarna i inbyggd RDP-omdirigering.
Varför USB-donglar och säkerhetsnycklar inte fungerar över RDP
RDP utformades för att leverera en fjärrsession till en lokal skärm. Tangentbordsinmatning, bildskärm, urklipp och ljud mappas naturligt till den. USB-donglar, certifikattoken och säkerhetsnycklar gör det inte, och orsakerna skiljer sig åt beroende på enhetstyp.
Mjukvarulicensdonglar som Sentinel, HASP och CodeMeter förlitar sig på proprietära drivrutiner och kontinuerliga närvarokontroller. Applikationen frågar av dongeln med jämna mellanrum, och om USB-kommunikationen avbryts eller fördröjs låser sig programvaran eller stängs ned helt.
Certifikattoken och nycklar för digital signering är beroende av mellanprogramvara som PKCS#11 eller Microsoft CryptoAPI. Problemet över RDP är inte polling utan åtkomst: fjärrmaskinen behöver rätt bibliotek installerade och ett sätt att komma åt den fysiska enheten som om den vore lokal.
Hårdvarusäkerhetsnycklar, inklusive många FIDO2-enheter, beter sig åter annorlunda. Vissa fungerar ganska bra med inbyggd RDP-omdirigering av smartkort, beroende på den specifika enheten och Windows-miljön.
Windows har stöd för bredare USB-omdirigering via Grupprincip, och för standardenhetstyper som lagring, skrivare och PIV-kompatibla smartkort fungerar det tillförlitligt. För licensdonglar är det värt att prova först i en kontrollerad Windows-miljö, men resultaten varierar beroende på dongeltyp, drivrutinsstöd, Windows-version och nätverksförhållanden. Även när det fungerar stöder inbyggd omdirigering bara en RDP-session i taget och kräver ytterligare konfiguration: policyändringar, drivrutinshantering och en Windows-only-miljö.
Sömlös lösning för att omdirigera USB-dongel via RDP: Donglify
Där inbyggd RDP inte räcker till för omdirigering av USB-donglar, erbjuder Donglify ett mer praktiskt alternativ. Det gör att en fjärrskrivbordssession kan komma åt en USB-dongel som är ansluten till en lokal dator via nätverket, så att enheten visas som om den vore direkt ansluten. Inga protokollworkarounds, inga begränsningar till en enda session och ingen konfiguration av grupprinciper krävs.
Donglify stöder många stora varumärken och modeller av USB-donglar, inklusive Sentinel-, HASP- och CodeMeter-nycklar som ofta används i ingenjörs- och designmiljöer. Med enkel installation och utan behov av komplexa infrastrukturändringar är det en praktisk lösning för team som behöver tillförlitlig dongelåtkomst över RDP.
Donglify Huvudfunktioner
Stöd för flera anslutningar. För donglar som stöds låter Donglify flera fjärrmaskiner komma åt en fysisk USB-dongel samtidigt.
Ingen beroende av inbyggd USB-vidarebefordran i RDP. Donglify delar dongeln över nätverket, vilket gör den användbar i fjärrskrivbords- och VM-scenarier där USB-vidarebefordran är begränsad.
Krypterad trafik. Donglify uppger att dess delade anslutningar är krypterade, och dess säkerhetsmaterial beskriver TLS 1.2 och end-to-end-kryptering.
Konfiguration endast med programvara. Ingen extra maskinvara krävs för att börja dela en dongel över nätverket. Donglify är tillgängligt för Windows och macOS.
Så här konfigurerar du Donglify för åtkomst till RDP-dongel
Installationsprocessen är relativt enkel. Inga Group Policy-redigeringar krävs och ingen drivrutinsmatchning mellan datorer, även om fjärrdatorn fortfarande behöver att rätt enhetsdrivrutiner installeras separat.
1. Skapa ett gratis Donglify-konto på donglify.net.
2. Installera Donglify på servermaskinen, den som USB-dongeln är fysiskt ansluten till, och på varje fjärrklientmaskin som kommer att behöva åtkomst till den.
3. Starta Donglify på båda datorerna och logga in med samma kontouppgifter.
4. På servermaskinen klickar du på ikonen ”+” för att visa en lista över anslutna USB-enheter.
5. Välj den dongle du vill dela genom att använda alternativknappen bredvid dess namn och klicka sedan på Dela.
6. På klientdatorn hittar du den delade dongeln i Donglify-gränssnittet och klickar på Anslut.
7. När anslutningen har upprättats visas dongeln i den fjärranslutna datorns Enhetshanteraren som en lokalt ansluten enhet. För de flesta standardlicensdonglar, inklusive Sentinel HL-, HASP HL- och CodeMeter-stickor, känner den licensierade programvaran igen den och sessionen körs normalt. Mycket specialiserade eller firmware-skyddade donglar kräver fortfarande testning mot din specifika enhet innan du förlitar dig på den i produktion.
Välja mellan inbyggd RDP och en nätverksnivåbaserad metod
Inbyggd RDP-USB-omdirigering är värd att prova först, särskilt för PIV-kompatibla smartkort, standardenheter som stöds av Windows och kontrollerade VDI-miljöer där konfigurationsarbetet är hanterbart. Den kräver ingen ytterligare programvara och hanterar många vanliga scenarier tillräckligt bra.
För licensdonglar som inte fungerar med inbyggd RDP, certifikattoken med leverantörsspecifik mellanprogramvara, krav på fleranvändaråtkomst eller plattformsoberoende miljöer, adresserar ett USB-delningverktyg på nätverksnivå som Donglify problemet på en annan nivå. Arkitekturen undviker översättningsproblemet i stället för att försöka kringgå det. Det är den praktiska orsaken till att det tenderar att fungera där inbyggd omdirigering inte gör det, inte för att det är en universallösning, utan för att det inte förlitar sig på samma abstraktionslager som orsakar felet från första början.