Skip to main content

Connector auth and setup reference

Connect docs via MCP

This reference lists the auth methods, grants, network prerequisites, and scoping limits that most often trip up connector setup. Full setup forms, credential fields, and current availability live on each connector's own page on docs.atlan.com—this page complements those, it doesn't replace them. Facts are current as of the latest review date; confirm release-sensitive specifics (default thresholds, availability status, supported APIs) against the live connector doc.

Choosing an auth method. Where a connector offers a choice, prefer a service principal or managed identity backed by a secret store over long-lived keys or plain-text credentials; use a key pair or personal access token only where the source has no service-principal path. Recommended methods are marked inline below.

Cross-connector facts​

  • Cross-connection lineage isn't supported. Splitting one system across many connections (for example, BigQuery per GCP project, SQL Server per database) means lineage won't stitch across those connections automatically—it needs custom lineage.
  • Deletion-threshold circuit breaker: fires after the miner computes its diff: delete_percentage = delete_count / old_total_count * 100; the workflow fails fast above a configurable threshold. The threshold applies to both crawler and miner and is raised via support ticket; confirm the current default against the connector documentation. There is no native RBAC gate on the bypass. Deleting and recreating the only workflow on a connection deletes the connection and its configuration.
  • Programmatic connection management: create via REST API (where credentials are specified); subsequent updates (filters, schedules) via the Python SDK—updates don't re-specify credentials. The admin role passes as a GUID-wrapped attribute.
  • Secrets: credentials can live in the Atlan UI or be fetched from a secret store (GCP Secret Manager, AWS Secrets Manager). Workload Identity Federation / secret-manager integration is the production-grade path over plain-text JSON keys. "Failed to fetch secret" / JSON parse errors are typically path-format or escaping issues.
  • Data access posture (for security reviews): Atlan reads metadata, not production data, under the service principal's scope; data preview can be disabled centrally.
  • Filter-granularity limitations: ADLS supports prefix-only filtering with no exclusion; SAP can't filter below module level; Sigma and Tableau lack folder-based include/exclude.

Per-connector notes​

Snowflake​

  • Service principal (recommended) or key pair; preset roles preferred over custom grants.
  • Very large table volumes can time out the workflow: split large databases into separate connections; see the Snowflake connector doc for current volume and timeout guidance.
  • The connector can load and reverse-sync tags (PII/PI) to Snowflake.
  • JWT/private-key parse errors are a common initial-connection failure mode.

Databricks​

  • Auth: PAT, service principal, or Secure Agent—per workspace (service principal recommended where available).
  • Use the System Tables method for lineage extraction, not the REST API. A SQL warehouse is required for mining even when the REST API is used.
  • Unity Catalog gives native system lineage; Hive metastore limits upstream lineage (notebook transformations aren't parsed out of the box).
  • Required inputs: for Azure Databricks, the Azure Resource ID (/subscriptions/.../workspaces/<ws>); plus workspace URL/FQDN and region. Watch for source-vs-tenant region conflicts; use chunked/incremental extraction on high lineage volume; Unity Catalog service principals may need the "browse" privilege.

dbt Cloud / dbt Core​

  • Cloud: API token + account ID; crawls job metadata (schedules, run history, status), model metadata, model-to-model lineage, docs.
  • Core: Git access + manifest.json location; your orchestration uploads manifest.json, run_results.json, and catalog.json to S3/GCS/Azure. A dbt crawl returning zero assets is usually a missing artifact upload or wrong path, not an auth failure.
  • Multi-environment dbt (dev/QA/stage) can cross-link or surface only one environment—scope per environment.

Power BI​

  • Service principal + Azure AD app registration (delegated permissions where needed). The connector is read-only. It offers more than one crawl mode with a coverage/lineage tradeoff: a Scanner-API mode where a single connection covers the whole tenant but page/measure-level lineage is sacrificed, and a non-scanner (per-workspace) mode that captures richer lineage but requires the service principal to be added to every workspace. See the Power BI connector doc for the current mode names, their lineage tradeoffs, and required permissions.
  • Cross-workspace lineage requires consolidating all workspaces into a single connection and using the Scanner API with admin access: workspace-level scanning only suits strict single-workspace isolation.
  • Microsoft Fabric is a different connector with different lineage behavior than legacy Power BI.
  • Page/column-level lineage needs a separate package plus a registered Azure app with read+list on the storage container; see the current package documentation for setup.
  • PBIR/ADLS setup: the expected folder structure is one folder per report (by report ID) containing a definition subfolder.

Tableau​

  • Personal access token (recommended) or connected app; the Metadata API must be enabled. Cloud or Server; scoping by project / published workbook / certified source.
  • Embedded data sources (queries inside reports) break upstream stitching to the warehouse.

Looker​

  • API Client ID + secret; LookML Git integration optional.

Fivetran (and pure load/replication ETL)​

  • API key + secret.
  • For pure load/replication tools with no column renaming (HVR, Fivetran), lineage is obtainable without scanning the ETL tool itself.

Glean​

  • One-way sync Atlan → Glean—glossary terms, names, descriptions, READMEs, certificate status, owners. No write-back from Glean to Atlan. Check the Glean connector doc for current availability status and the exact included-metadata list.

Salesforce​

  • The current connector doc lists the Salesforce "View All" permission as the required permission—check the live connector doc for whether a narrower metadata-scoped permission is now supported. If reusing an existing OAuth app that already holds View All, verify the auth flow type matches (JWT bearer vs OAuth 2.0 client credentials differ; credential reuse fails across flows) and the hostname matches.

Teradata​

  • Confirm the instance is configured for LDAP (vs basic / TD2 / TDII). LDAP username format is user@domain or domain\user, not a bare username.
  • With GCP Secret Manager, the password path must use .../versions/latest (a pinned version breaks on rotation).

Redshift​

  • The crawler needs GRANT USAGE ON SCHEMA per schema: SELECT on catalog tables alone isn't sufficient for the miner.

Azure SQL / Cosmos DB / Cloud SQL / DynamoDB​

  • Cosmos DB: the native connector covers the MongoDB API; see the current Cosmos DB connector doc for the full list of supported APIs.
  • Azure SQL Managed Instance: the connectivity diagnostic is public internet vs VNet private endpoint.
  • A single Azure app registration can serve multiple connectors (analogous to one AWS IAM role across policies).
  • Cloud SQL via Self-Deployed Runtime: the connector expects the PSC endpoint directly reachable in the SDR VPC: it doesn't natively route through a Cloud SQL auth proxy.
  • DynamoDB: adding a new region is a manual setup step (not autodiscovered); cross-region private link shouldn't be assumed without checking.

MicroStrategy​

  • On-prem connectivity requires site-to-site VPN / proxy / DNS resolution on both sides—a network prerequisite, not a standard cloud connection.

Partner-built connectors (for example, SSRS, SAP BusinessObjects)​

  • Carry limited metadata versus native connectors: see each partner-connector page for its supported-attributes list.

Self-Deployed Runtime (SDR)​

  • SDR supports crawlers deployed on your own infrastructure; see the SDR documentation for current secure-agent miner support.
  • SDR generally doesn't require inbound connectivity: it's outbound only.
  • Deployment choices: SDR Orchestrator (multi-app) vs per-source Docker Compose (single-app).
  • Required scoping inputs: deployment location (server/VM), server specs (OS/memory/CPU), egress rules, firewall rules, server owner, JDBC connection string, and the list of outbound URLs to allowlist. A connectivity test must precede full deployment.
  • Connectors & ingestion best practices: auth-pattern selection, crawl scoping, sequencing.
  • Feature maturity matrix: connector-adjacent maturity flags (SageMaker private preview, Databricks foreign Iceberg tables private preview).
  • Per-connector setup docs on docs.atlan.com—full setup forms, credential fields, and current availability for each connector.