> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/rdm/da/knowledge-base/knowledge-base-articles/going-passwordless-with-remote-desktop-manager-and-cyberark.md).

# Arbejd uden adgangskode med Remote Desktop Manager og CyberArk

Konfigurer privilegeret adgang uden adgangskode i Remote Desktop Manager ved hjælp af CyberArk Application Access Manager og godkendelse med privat nøgle.

Som følge af partnerskabet mellem Devolutions og CyberArk er alle vores integrationstyper blevet forbedret, så de udnytter CyberArks forbedrede API'er fuldt ud. Disse opdateringer gør det nu muligt for organisationer at indføre arbejdsflows uden adgangskode i den daglige drift, så adgangen forenkles, samtidig med at sikkerheden styrkes.

For at udnytte disse forbedringer skal Deres organisation medtage CyberArks ***Application Access Manager*** (AAM) i installationen. Dette modul muliggør godkendelse med ***privat nøgle***, så Deres IT-afdeling kan styre hele identifikations- og godkendelsesprocessen. Dermed bliver traditionelle adgangskoder unødvendige i CyberArk-arbejdsflowet.

{% hint style="info" %}
Udtrykket uden adgangskode gælder specifikt for CyberArk-integrationen. De skal stadig godkende Dem over for Remote Desktop Manager, afhængigt af det arbejdsområde, De bruger.
{% endhint %}

### Oversigt

Dette arbejdsflow giver sikker privilegeret adgang uden adgangskode ved hjælp af CyberArk-integration i Remote Desktop Manager:

1. Brugeren logger på Remote Desktop Manager med en konto med mindst mulige rettigheder, som giver adgang til indholdet i Remote Desktop Manager i henhold til de tilladelser, der er defineret i vores system til brugergruppebaseret adgangskontrol.
2. Når der kræves en privilegeret konto for at starte en forbindelse med en understøttet teknologi, henter Remote Desktop Manager den tilhørende private nøgle fra brugerens arbejdsstation. Nøglen skal være tilgængelig i brugerens certifikatlager.
3. Den private nøgle bruges derefter til at godkende over for CyberArk-boksen. Boksen er konfigureret med et programobjekt, der fungerer som en brugerproxy til at forespørge boksen.
4. Remote Desktop Manager henter legitimationsoplysningerne til den relevante privilegerede konto. Det afgørende er, at brugeren aldrig ser eller håndterer den faktiske adgangskode til sin egen privilegerede konto.
5. Remote Desktop Manager bruger den privilegerede konto til at:

* starte en PSM-forbindelse (Privileged Session Manager),
* oprette forbindelse til PVWA (Password Vault Web Access),
* eller starte en hvilken som helst anden understøttet sessionstype. Alt dette sker, mens adgangskoden holdes skjult, og godkendelsesprocessen forbliver gnidningsfri og sikker.

### Konfiguration af CyberArk Application Access Manager (AAM)

De skal først generere og udrulle private nøgler for hver bruger på vedkommendes arbejdsstationer. CyberArks officielle dokumentation er fortsat den autoritative kilde til denne proces, men vi giver grundlæggende vejledning i vores integrationsdokumentation.

I Remote Desktop Manager tilbyder vi flere måder at administrere private nøgler på, afhængigt af Deres miljø og graden af administrativ kontrol:

#### Mulighed 1: lagring af oplysninger om den private nøgle i en post i brugerboksen

Dette er den enkleste metode, og den etablerer en en-til-en-relation mellem brugere, nøgler og konti. Hver bruger er ansvarlig for at administrere sin egen post og oplysningerne om den private nøgle. Det er enkelt, men decentraliseret.

#### Mulighed 2: lagring af oplysninger om den private nøgle i Mine kontoindstillinger

Denne metode adskiller ansvarsområderne. Administratorer konfigurerer AAM-posterne i Remote Desktop Manager, mens brugerne angiver deres egne oplysninger om den private nøgle via deres personlige indstillinger.

Afhængigt af Deres fremgangsmåde kan opslag af privilegerede konti håndteres på to måder:

**Administreret i CyberArk**

* Hver bruger skal have en dedikeret privilegeret konto, der er tilgængelig via delte nøgleord, som er defineret i AAM-posten.
* Administratorer er ansvarlige for at placere hver brugers konto i isolerede safes og for at sikre ensartet brug af nøgleord på tværs af alle relevante konti.

**Administreret i Remote Desktop Manager**

* Administratorer opretter en entydig AAM-post pr. bruger, hver konfigureret med brugerspecifikke nøgleord.
* Adgangen til disse poster styres med den brugergruppebaserede adgangskontrol i Remote Desktop Manager, så brugerne kun kan se og bruge deres egne tildelte poster.

Som med mange funktioner i Remote Desktop Manager kan disse metoder kombineres, så de passer til Deres organisations særlige krav til sikkerhed og arbejdsflow.

{% hint style="info" %}
Et andet programnavn end ***AIMWebService*** skal angives i feltet ***programnavn***.
{% endhint %}

### Konfiguration af CyberArk Privilege Session Manager (PSM)

På grund af omfanget og kompleksiteten af CyberArks Privileged Session Manager (PSM) anbefaler vi at læse CyberArks officielle dokumentation for at få alle oplysninger om konfiguration og udrulning.

I Remote Desktop Manager er integrationen med PSM enkel, når De har konfigureret AAM som beskrevet i det foregående afsnit.

#### Hvis De bruger AAM-mulighed 1

Hvis De gemmer oplysningerne om den private nøgle i en post i brugerboksen, skal De bruge brugerspecifikke indstillinger i Remote Desktop Manager til at knytte hver brugers PSM-Server-post til den tilhørende AAM-post i boksen. Det sikrer, at hver brugers forbindelse bruger vedkommendes egen private nøgle til godkendelse.

#### Hvis De bruger AAM-mulighed 2

Hvis oplysningerne om den private nøgle er gemt under ***Mine kontoindstillinger***, anbefaler vi at konfigurere PSM-Server-posten til at bruge ***Legitimationslager*** sammen med ***Spørg ved forbindelse***.

Denne opsætning giver nye brugere en smidig start, hvor de bliver bedt om at vælge de relevante legitimationsoplysninger. Mere erfarne brugere kan senere tilpasse oplevelsen ved at skifte til brugerspecifikke indstillinger for at oprette et varigt link til deres tildelte AAM-post.

### Konfiguration af CyberArk Webservices SDK

Organisationer, der arbejder helt inden for CyberArk-platformen, bruger typisk kerneintegrationer som PSM og Application Access Manager (AAM), men vi understøtter også CyberArk Webservices SDK for at give yderligere fleksibilitet.

Denne integrationstype er særligt nyttig, når:

* Privileged Session Manager (PSM) er ikke en brugbar mulighed, eller
* De kan ikke bruge funktionerne til formidling af legitimationsoplysninger i Remote Desktop Manager til et bestemt brugsscenarie.

Med Webservices SDK kan Remote Desktop Manager hente bestemte legitimationsoplysninger direkte fra CyberArk-boksen og stadig sikre, at:

* Adgangen udføres på vegne af en privilegeret konto.
* Slutbrugeren hverken ser eller styrer adgangskoden.

Det giver sikker, politikbaseret adgang til legitimationsoplysninger, også i scenarier hvor de almindelige AAM- eller PSM-forløb ikke kan bruges, samtidig med at den strenge kontrol og efterlevelse bevares.

### Konklusion

For at se alle mulighederne i vores CyberArk-integrationer anbefaler vi at læse både CyberArks officielle dokumentation og vores egne detaljerede vejledninger. Nedenfor finder De links til hver understøttet integrationstype samt henvisninger til de funktioner i Remote Desktop Manager, der er nævnt i denne artikel:

* Integrationsvejledninger (downloadlink fra vores CDN)
  * [Vejledning til AAM-integration](https://cdn.devolutions.net/documents/cyberark/Devolutions%20Remote%20Desktop%20Manager%20-%20CyberArk%20AAM%20integration%20guide.pdf)
  * [Vejledning til PSM-integration](https://cdn.devolutions.net/documents/cyberark/Devolutions%20Remote%20Desktop%20Manager%20-%20CyberArk%20PSM%20integration%20guide.pdf)
  * [Vejledning til integration af Webservices SDK](https://cdn.devolutions.net/documents/cyberark/Devolutions%20Remote%20Desktop%20Manager%20-%20CyberArk%20Webservices%20SDK%20integration%20guide.pdf)
* Hjælp til Remote Desktop Manager
  * [Mine kontoindstillinger](/rdm/da/ribbon-menu-bar/file/my-account-settings.md)
  * [Brugerspecifikke indstillinger](/rdm/da/ribbon-menu-bar/edit/specific-settings.md)

Kontakt som altid vores kundesupport på <service@devolutions.net>, hvis De ønsker en gennemgang, eller hvis De har brug for en afklaring af bestemte forhold.

### Se også

* [Devolutions Blog - Fokus på: RDM CyberArk PVWA-legitimationspost til PSM-forbindelse](https://blog.devolutions.net/2025/05/spotlight-on-rdm-cyberark-pvwa-credential-entry-for-psm-connection/)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.devolutions.net/rdm/da/knowledge-base/knowledge-base-articles/going-passwordless-with-remote-desktop-manager-and-cyberark.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
