Dcm training guide

Module 01

Delinea Credential Manager
Browser Extension

DCM is a browser extension that enables end users to log into web applications using credentials stored in Secret Server — without ever seeing, knowing, or copying the password. Credentials are injected directly and securely.

0 Passwords Exposed

4 Supported Browsers

1-click Login Experience

RBAC Access Control

What Problem Does DCM Solve?

Traditional shared-account access creates serious risks: users see passwords, copy them into clipboards, save them in browsers, or share them out-of-band. DCM eliminates these exposure points entirely. The credential flow stays entirely server-side — the browser extension acts only as a UI trigger, never as a credential carrier.

⛔ Without DCM

User must view or copy password from vault
Credential sits in clipboard (exploitable)
Passwords saved to browser's local store
Screenshots or shoulder-surfing risk
No audit trail for web-app login events

✅ With DCM

Credential auto-injected — never visible
Clipboard never touched
No browser-local credential storage
Nothing to see, nothing to leak
Full audit log in Secret Server

Who Uses DCM?

End Users

Employees who need access to shared web-app accounts without knowing the password.

Admins

IT and PAM admins who configure web password secrets, map URL patterns, and manage access policies.

Security Teams

Auditors and security staff reviewing access logs, verifying zero-exposure, and managing secret lifecycle.

01 / 07

Module 02

How DCM Works

DCM intercepts the login workflow in the browser and replaces manual credential entry with a server-side injection pipeline. Click each step below to explore the detailed flow.

🌐

User Navigates

🔍

URL Match

📋

DCM Popup

🔐

Auth Request

💉

Injection

✅

Login Complete

Step 1 — User Navigates to Login Page: The end user opens a web application in their browser. DCM is silently monitoring the URL in the active tab against the URL patterns configured in Secret Server.

Step 2 — URL Pattern Matching: The DCM extension compares the current page URL against all Web Password Secrets the authenticated user has access to. If one or more matches are found, the DCM toolbar icon becomes active, signaling available credentials.

Step 3 — User Clicks DCM Icon: A popup displays the list of matching secrets (by name) — not the passwords. The user sees only the secret name and username. They select the account they want to use.

Step 4 — Authenticated API Call to Secret Server: DCM makes an HTTPS API call to Secret Server on behalf of the user's authenticated session. The extension does not store or cache credentials locally. The request is signed using the user's session token.

Step 5 — Credential Injection: Secret Server returns the credential fields to DCM over an encrypted channel. DCM programmatically populates the username and password fields in the DOM — without ever rendering the password as visible text, writing it to the clipboard, or exposing it to JavaScript in the page.

Step 6 — Login Complete & Audited: The form is submitted. The session is established. Secret Server logs the access event — including the secret name, user, timestamp, and target URL — providing a complete, tamper-evident audit trail.

The Architecture in Context

DCM functions as a thin UI client that talks to Secret Server's REST API. The extension itself holds no credentials between sessions. All secrets remain encrypted at rest in Secret Server's database. The extension's only job is to (1) detect matching pages, (2) let the user pick an account, and (3) inject the fields programmatically from the API response.

ℹ️ DCM requires the user to be authenticated to Secret Server (either via SSO, Windows Auth, or username/password) before credentials can be injected. If the session expires, DCM will prompt for re-authentication.

02 / 07

Module 03

Supported Browsers & Platforms

DCM is available as a native extension from each browser's official extension store. There is no separate client installer required for end-users beyond the browser extension itself.

🌐

Chrome

✓ SUPPORTED

🦊

Firefox

✓ SUPPORTED

🔷

Edge

✓ SUPPORTED

🧭

Safari

✓ SUPPORTED

Platform Compatibility Matrix

PLATFORM	CHROME	FIREFOX	EDGE	SAFARI
Windows 10 / 11	✓	✓	✓	—
macOS 12+	✓	✓	✓	✓
Linux (Ubuntu/RHEL)	✓	✓	✓	—
ChromeOS	✓	—	—	—

1

Secret Server 11.4+ (or Delinea Platform)

DCM requires Secret Server version 11.4 or later for full feature support including automatic URL-pattern matching and the modern REST API endpoints used by the extension.

2

HTTPS Connectivity to Secret Server

The user's machine must be able to reach the Secret Server URL over HTTPS (port 443). Internal deployments should ensure the certificate is trusted by the browser.

3

Valid Secret Server User Account

Each end user must have a Secret Server account with appropriate permissions on the relevant Web Password Secret(s). Anonymous access is not supported.

4

Web Password Filler Feature Enabled

The "Web Password Filler" feature flag must be enabled in Secret Server's configuration (Admin → Configuration → Features). DCM depends on this feature being active.

Admins can deploy the DCM extension silently to managed endpoints using standard browser policy mechanisms:

# Chrome/Edge — Group Policy (GPO or Intune)
ExtensionInstallForcelist: [
  "dcm-extension-id;https://clients2.google.com/service/update2/crx"
]

# Firefox — policies.json
{
  "policies": {
    "ExtensionSettings": {
      "dcm@delinea.com": {
        "installation_mode": "force_installed"
      }
    }
  }
}
      

⚠️ After force-installing the extension, users will still need to authenticate to Secret Server the first time DCM is used in their browser session. This is by design — the extension validates identity before any credential retrieval.

03 / 07

Module 04

Configuring Web Password Secrets

For DCM to inject credentials into a web application, that application's credentials must be stored in Secret Server using the Web Password secret template — and the secret must be configured with the correct URL pattern.

Step-by-Step: Creating a Web Password Secret

1

Choose the "Web Password" Template

In Secret Server, navigate to Secrets → + New Secret and select the Web Password template. This template includes the URL field required by DCM. Do not use the generic "Password" template — it lacks the URL-binding field.

2

Enter the Target URL (Pattern)

In the URL field, enter either the exact login URL or a wildcard pattern. DCM supports * wildcards. Example: https://app.example.com/* will match any page under that domain.

3

Enter Username and Password Fields

Populate the Username and Password fields as normal. The password can be generated by Secret Server's password generator to ensure complexity. DCM will read these fields at injection time.

4

Configure Field Mapping (Advanced)

If the target web application uses non-standard HTML field names (e.g., loginEmail instead of username), use the Web Password Filler Mappings section to specify the exact field IDs or CSS selectors DCM should target.

5

Set Permissions on the Secret

Grant View permission to the users or groups who need to use this credential via DCM. Granting View permission does NOT mean the user will see the password — DCM uses it server-side. Only users with explicit access will see the secret listed in the DCM popup.

6

Enable "Autolaunch" (Optional)

If Autolaunch is enabled on the secret, DCM can automatically fill the login form when the matching URL is detected — without requiring the user to click the extension icon. This is suitable for non-sensitive shared accounts where frictionless access is the priority.

URL Pattern Reference

# EXACT MATCH — only that specific URL
https://login.salesforce.com/

# PATH WILDCARD — any path under a domain
https://app.example.com/*

# SUBDOMAIN WILDCARD — any subdomain
https://*.example.com/login

# MULTI-URL (separate entries for same secret)
https://us.example.com/auth
https://eu.example.com/auth
    

✅ Best Practice: Use the narrowest URL pattern that covers your login page. Overly broad patterns (e.g., https://*/*) will cause DCM to match on every page, degrading performance and user experience.

⚠️ Hiding Passwords vs. Blocking View: Granting a user View access on a Web Password Secret does NOT automatically block them from using the "View Password" button in Secret Server's UI. To prevent password visibility, configure a Secret Policy that hides the password field and requires DCM-only access.

04 / 07

Module 05

The User Experience

From the end user's perspective, DCM is designed to feel invisible. They see account names, they click once, and they're in — with no password interaction at any point.

Interactive Demo

This simulation shows how DCM behaves in the browser. Click the key icon (🔑) in the browser toolbar below to see the DCM popup, then click a credential to fill the form.

https://app.example-corp.com/login

🔑

👆 Click the 🔑 key icon to see available credentials for this page

What the User Sees vs. What Happens

👁️

What the User Sees

The secret name (e.g., "Marketing Shared Account") and the username in the DCM dropdown. The password field in the browser shows bullet characters (••••••••) after auto-fill — the actual value is never rendered as text.

🔧

What Actually Happens

DCM calls Secret Server's API, retrieves the encrypted credential, decrypts it in the extension's isolated context, and programmatically sets the input field values. JavaScript running in the web page cannot read the password from an autofilled field due to browser security policies.

📋

Clipboard Handling

DCM never writes to the clipboard during an injection. Passwords are set directly on form elements — bypassing clipboard entirely. This prevents credential theft via clipboard monitoring tools.

📝

Session-Only Retention

Credentials retrieved by DCM are held in memory only for the duration of the injection operation — typically milliseconds. They are not cached, stored in localStorage, or retained after the browser tab is closed.

05 / 07

Module 06

The Security Model

DCM's security posture is built on a layered architecture where credentials remain encrypted and server-side at all times. Each layer independently enforces the zero-exposure principle.

Layered Security Architecture

L1

Transport Security — TLS 1.2+

All communication between DCM and Secret Server is over TLS 1.2 or higher. Certificate validation is enforced — self-signed or expired certificates will block the connection. This protects credentials in transit from man-in-the-middle interception.

L2

Authentication — Session Tokens, not Stored Credentials

DCM authenticates to Secret Server using the user's existing browser session or OAuth token. The extension never stores master passwords or API keys locally. If the session expires, the user must re-authenticate — ensuring continuous identity verification.

L3

Authorization — RBAC + Secret Permissions

Even with DCM installed, a user can only access secrets they have been explicitly granted View or higher permissions on in Secret Server. Role-based policies, group memberships, and secret-level permissions all apply. DCM does not bypass any authorization controls.

L4

Extension Isolation — Chrome Extension Security Model

Browser extensions operate in an isolated context, separate from the web pages they interact with. The DCM extension's memory space is not accessible to scripts running in the web page. This prevents malicious JavaScript on a compromised web application from reading the injected credentials.

L5

Audit Logging — Immutable Access Records

Every credential injection creates a log entry in Secret Server recording: the user, the secret accessed, the source IP, the target URL, and the timestamp. These logs can be forwarded to SIEM systems via syslog and are protected from modification by non-admin users.

L6

Secret Policies — Enforced Access Workflows

Admins can apply Secret Policies that enforce: require checkout before injection, require MFA for high-value secrets, time-limit access windows, and hide the password field entirely — so even users with View access cannot see the underlying password through the Secret Server UI.

What DCM Cannot Protect Against

⚠️

Endpoint Compromise: If the user's endpoint has malware with kernel-level access, an attacker could potentially intercept the HTTP request from the browser to the web application after injection. DCM protects credentials up to the point of form submission — but a compromised browser process may still capture submitted form data. Endpoint protection is a complementary, required layer.

Credential Exposure: Before and After DCM

EXPOSURE SURFACE COMPARISON

Without DCM

📋 Clipboard
🖥️ Screen / display
🧠 Human memory
📁 Browser password store
📤 Sent via email or chat
🔍 Shoulder surfing

With DCM

✓ Never touches clipboard
✓ Never displayed as text
✓ User never learns password
✓ Not stored in browser
✓ Nothing to share
✓ Nothing visible to observe

06 / 07

Module 07

Knowledge Check

Test your understanding of DCM. Select the best answer for each question. Results are tracked locally — no personal data is sent anywhere.

QUESTION 01 / 05

When a user selects a credential from the DCM popup, what does the extension display in the browser's password field?

A The plaintext password in a tooltip

B Bullet characters (••••••) — the actual value is never rendered as readable text

C A temporary masked string that the user can reveal by hovering

D Nothing — the user must manually submit the empty form

QUESTION 02 / 05

Which Secret Server secret template must be used for DCM credential injection to work?

A Generic Password

B Active Directory Account

C Web Password

D SSH Key

QUESTION 03 / 05

A user has View permission on a Web Password secret. What does this guarantee about password visibility?

A The user can never see the password in any context

B By default, the user CAN view the password in the Secret Server UI unless a Secret Policy hides the field

C The user sees the password only when DCM injects it

D The user sees the password once, then it is masked permanently

QUESTION 04 / 05

Which of the following correctly describes how DCM handles the clipboard during credential injection?

A DCM writes the password to the clipboard temporarily and then clears it after 10 seconds

B DCM requires clipboard access to paste credentials into the browser fields

C DCM never writes to the clipboard — credentials are injected directly into form DOM elements

D DCM uses the clipboard only for the username, not the password

QUESTION 05 / 05

What is the purpose of configuring a URL pattern on a Web Password secret?

A To restrict which users can access the secret based on their IP address

B To set the password rotation schedule for the web application

C To define which Secret Server folder the credential belongs to

D To tell DCM which web pages should trigger display of that credential in the extension popup

07 / 07

Delinea Credential ManagerBrowser Extension

What Problem Does DCM Solve?

Who Uses DCM?

How DCM Works

The Architecture in Context

Supported Browsers & Platforms

Platform Compatibility Matrix

Secret Server 11.4+ (or Delinea Platform)

HTTPS Connectivity to Secret Server

Valid Secret Server User Account

Web Password Filler Feature Enabled

Configuring Web Password Secrets

Step-by-Step: Creating a Web Password Secret

Choose the "Web Password" Template

Enter the Target URL (Pattern)

Enter Username and Password Fields

Configure Field Mapping (Advanced)

Set Permissions on the Secret

Enable "Autolaunch" (Optional)

URL Pattern Reference

The User Experience

Interactive Demo

🏢 Example Corp Login

What the User Sees vs. What Happens

What the User Sees

What Actually Happens

Clipboard Handling

Session-Only Retention

The Security Model

Layered Security Architecture

Transport Security — TLS 1.2+

Authentication — Session Tokens, not Stored Credentials

Authorization — RBAC + Secret Permissions

Extension Isolation — Chrome Extension Security Model

Audit Logging — Immutable Access Records

Secret Policies — Enforced Access Workflows

What DCM Cannot Protect Against

Credential Exposure: Before and After DCM

Knowledge Check

Delinea Credential Manager
Browser Extension