Database Links and Linked Servers: Finding Stored Credentials and Trust Paths Between Databases

Database links and linked servers store a credential for one database inside another, so a foothold in the least important database can become a session in the most important one. SQL Server linked servers, Oracle database links and PostgreSQL foreign data wrappers exist for good reasons: reporting, migrations, replication and cross-system queries. Each one is a non-human identity with a remote login, a password or a delegated identity, and a trust path that rarely appears on any diagram. This guide explains how each platform stores and maps these credentials, how to find every link and the path it creates, and how to replace fixed passwords with narrower designs. It is for database administrators, identity and NHI teams, and security engineers mapping lateral movement risk. Platforms are listed alphabetically by vendor.

Key takeaways

• A link is a stored credential. Fixed-login linked servers, fixed-user Oracle links and PostgreSQL user mappings with passwords all keep a remote secret in the local database.
• The dangerous setting is the "everyone" mapping. A SQL Server mapping with @locallogin = NULL, an Oracle PUBLIC fixed-user link or a PostgreSQL PUBLIC user mapping gives every local user the remote account's rights.
• Links chain. Database A links to B, which links to C, so the effective reach of a low-privilege login can be several hops away. Map paths, not just links.
• Prefer the caller's own identity. Self-mapping with Kerberos delegation, Oracle connected-user or CURRENT_USER links and PostgreSQL GSSAPI or SCRAM pass-through avoid a shared stored password.
• Inventory links as NHIs. Each needs an owner, a purpose, a remote account with least privilege and a review date.

How each platform stores the remote identity

Microsoft SQL Server

• Default mapping: Microsoft's documentation states that sp_addlinkedserver creates a default mapping for all local logins, equivalent to @useself = true. Each caller then connects with their own credentials, which is the safer starting point.
• Fixed remote login: @useself = false with a remote user and password stores that credential on the server. With @locallogin = NULL it applies to every local login. Explicit per-login mappings take precedence over the global one.
• Microsoft's guidance: the sp_addlinkedserver documentation notes that the default self-mapping applies to all local logins and that, for non-SQL Server providers, SQL Server authenticated logins might reach the provider under the SQL Server service account; it suggests administrators consider removing the global mapping with sp_droplinkedsrvlogin. For Windows identities, Microsoft documents Active Directory pass-through with full delegation and, from SQL Server 2017 CU17, with constrained delegation; use one of these documented delegation modes for multi-hop access.
• Remote permissions are remote: once connected, object permissions are decided by the remote server for the mapped login, not by the local server.
• Encryption: with MSOLEDBSQL 19 and SQL Server 2025, Microsoft documents Encrypt=Mandatory as the default and advises against TrustServerCertificate=Yes in production. Use the MSOLEDBSQL provider rather than the legacy SQLNCLI or SQLOLEDB providers.
• Managed Instance: Azure SQL Managed Instance supports managed identity and Microsoft Entra pass-through for linked servers, which removes the stored password.

Deeper SQL Server hardening is in the SQL Server Security Guide.

Oracle Database

• Fixed-user links connect as the named account whoever uses the link. As a PUBLIC link, every local user gets that remote account's privileges; Oracle's documentation states that a PUBLIC link is visible to all users, so choose its identity with care (our recommendation).
• Connected-user links use the local user's own credentials on the remote side, so the user must exist there.
• CURRENT_USER links use the current user in scope: inside a definer-rights stored object that is the object's owner, inside an invoker-rights unit it is the caller. The user must be a global user with an account on the remote database. Review definer-rights code that uses these links, because callers inherit the owner's remote reach.
• Credential objects: CONNECT WITH uses a credential managed by DBMS_CREDENTIAL; another user can use it only if granted EXECUTE. This separates the password from the link definition and lets you rotate it in one place.
• Shared links require an authentication clause for the users allowed to use the shared connection.

See the Oracle Database Security Guide for wider Oracle hardening.

PostgreSQL

• User mappings hold the secret: user, password and sslpassword cannot be server options in postgres_fdw; they live in a user mapping or a service file.
• password_required: only a superuser can set password_required 'false'. The PostgreSQL documentation warns this can let a mapped user connect as a superuser to the mapped database, and says not to set it for the public role.
• SCRAM pass-through: use_scram_passthrough avoids storing plain-text passwords in the catalogue, provided the remote server requests scram-sha-256, both servers hold identical SCRAM secrets for the user, and the incoming client connection also uses SCRAM. The option is documented from PostgreSQL 18; confirm it in the documentation for your release.

See the PostgreSQL Security Guide for role and authentication hardening.

Finding every link and the path it creates

Discovery has two parts: list the link objects on every instance, then join them into a graph.

Then build the graph:

1. Collect from every instance, including development, reporting and migration servers that are often forgotten. The CMDB rarely records links; see the Asset Inventory and CMDB Security Guide for where to store the result.
2. Resolve the remote end: map the remote host and login to an instance and a role, and record that role's privileges on the target.
3. Draw edges: source instance and who can use the link (all logins, a named login, PUBLIC) to target instance and remote role.
4. Walk paths: find every chain from low-trust instances (development, reporting, internet-facing applications) to high-trust ones (finance, identity stores, production master data). A three-hop path from a reporting server to a finance database is the finding that matters.
5. Rank: fixed credential plus all-users mapping plus privileged remote role is the top priority.

Risk patterns and the safer alternative

Remediation roadmap

1. Discover (weeks 1 to 3): run the queries above on every instance and build the graph. Read-only, no risk.
2. Assign owners (weeks 2 to 4): each link gets an application owner and a stated purpose. Links with no owner after four weeks go on the removal list (our recommendation).
3. Remove unused links (weeks 4 to 8): enable auditing of link use first, wait a full business cycle including month end, then drop links with no use. Keep the definition script, minus the password, for rollback.
4. Narrow mappings (weeks 6 to 12): replace all-logins and PUBLIC mappings with named mappings; replace privileged remote logins with purpose-built accounts. Test each change in a lower environment with the real jobs.
5. Remove stored passwords (ongoing): move to delegation, managed identity, CURRENT_USER or SCRAM pass-through where the platform supports it; otherwise rotate remote passwords on your standard schedule and keep them in a credential object or secrets manager. See the Database Credential and Access Security Guide.
6. Prevent new risky links: restrict who can create links (ALTER ANY LOGIN, CREATE PUBLIC DATABASE LINK, superuser) and require a change record for each new link. See Database Change and Schema Migration Security.

Detection and measurement

• New link or mapping created: alert on sp_addlinkedserver, sp_addlinkedsrvlogin, CREATE DATABASE LINK, CREATE USER MAPPING and ALTER USER MAPPING outside approved changes.
• Remote logins arriving from database servers: on the target, sessions whose client host is another database server and whose login is used by a link. Unusual source servers or times are worth investigating.
• Link use by unexpected local users: where auditing captures distributed queries, a login that has never used the link before.
• Privileged commands over a link: administrative statements executed through a linked session.

The Database Audit Log Detection Guide covers how to collect these events per platform. Metrics to track:

• Total links, and the number with fixed credentials.
• Number of all-logins or PUBLIC mappings (target: zero).
• Number of links whose remote account has administrative rights (target: zero).
• Number of paths from lower environments to production.
• Percentage of links with a named owner and review date.

Framework mapping

Common failure patterns

• Linked server created in a hurry with the "sa" login for every local user, and never revisited.
• Inventory by instance, not by path: each server looks acceptable alone while the chain reaches production.
• Passwords in saved scripts: the link definition script with the remote password sits in a repository or share.
• Definer-rights code using CURRENT_USER links without review, so callers inherit the owner's remote access.
• Migration links never removed after cut-over, with the remote account still enabled.
• Certificate validation switched off on the link to "make it work", exposing the remote credential in transit.

Practitioner checklist

• List every linked server, database link and foreign server on every instance, including non-production.
• Join links into a graph and find paths from lower-trust to higher-trust databases.
• Remove all-logins, PUBLIC and password_required 'false' mappings.
• Replace administrative remote logins with purpose-built least-privilege accounts.
• Prefer self-mapping with delegation, managed identity, CURRENT_USER or SCRAM pass-through over stored passwords.
• Keep remaining passwords in credential objects or a secrets manager and rotate them.
• Restrict who can create links and alert on new links and mappings.
• Give each link an owner, a purpose and a review date, and review quarterly.

Standards and references

• Microsoft Learn: Linked servers (Database Engine)
• Microsoft Learn: sp_addlinkedsrvlogin (Transact-SQL)
• Oracle: CREATE DATABASE LINK, SQL Language Reference
• Oracle: DBA_DB_LINKS, Database Reference
• PostgreSQL: postgres_fdw documentation
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Database Security Guide, SQL Server Security Guide, Oracle Database Security Guide, Database Privileged Access Review Template.