LDAP, SAML, OIDC, External Identity, Credential Rotation, and Authentication Troubleshooting: Diagnostics, Failure Modes, Security, and Performance
Diagnose LDAP search, SAML audience/ACS/cookie, OIDC issuer/redirect/claim, stale mapping, rotated-secret, certificate, rate-limit, and authorization failures using evidence-first isolation.
Learning objectives
- Use an evidence-first authentication diagnostic sequence.
- Separate LDAP connection/bind/search/group failures.
- Interpret SAML audience, ACS, cookie, metadata, and signing problems.
- Interpret OIDC issuer, redirect, client-secret, JWK/certificate, and claim problems.
- Recognize 429 authentication rate limiting and avoid destructive “fixes”.
Edition boundary. The diagnostic concepts apply to all editions, but self-hosted SAML and OIDC are Pro-only. Community learners use the synthetic evidence in this lesson rather than enabling those integrations.
1. Diagnostic sequence: identify the layer before changing state
- Preserve concise client/browser status, timestamp, username source, request URL, and correlation clues.
- Confirm Nexus version, edition/license, Java runtime, and whether the intended feature exists.
- Confirm client mode: browser SSO, Basic/token client, or local account.
- Inspect active realms and username-collision risk. Confirm the local recovery identity still works before changing external realm state.
- Inspect the external connection: DNS/TLS/proxy, then protocol-specific endpoint.
- For LDAP: bind → user search → group search/membership → external mapping.
- For SAML/OIDC: redirect → assertion/token validation → subject/claim mapping → external mapping.
- Inspect Nexus roles/privileges only after identity is proven.
- Inspect authentication/security logs and rate-limit evidence.
- Apply the smallest controlled correction, then retest one request.
Do not troubleshoot authentication by editing Nexus database/blob internals, deleting caches broadly, disabling TLS validation, enabling anonymous access, or granting nx-admin. Those actions either touch the wrong subsystem or destroy the evidence you need.
2. LDAP: “bind works” is not “user works”
| Evidence | Likely layer | Smallest next check |
|---|---|---|
| TCP/LDAPS connection fails | DNS, route, firewall, certificate trust | Resolve host/port; inspect certificate chain; do not alter user filters yet. |
| Bind fails | Bind DN/password or auth method | Verify service account state and secret rotation. |
| Bind succeeds; zero users | User base DN/filter/schema | Use the LDAP verify-user step against one synthetic user. |
| User found; no groups | Group base/object/member attribute | Inspect group mapping and membership method. |
| User authenticates; 403 repository | External role mapping / Nexus privilege | Inspect exact external group and role grants. |
Current Nexus caches LDAP authentication information. If a corrected directory state appears stale, use the supported LDAP cache control rather than deleting files or restarting unrelated services blindly.
3. SAML: browser success has several checkpoints
A user can authenticate successfully at the IdP and still fail Nexus
SSO. Check Entity ID/audience, ACS recipient/destination, signature
validity, attribute names, groups, and browser cookie state. Since
3.89.0-09, Nexus SAML login requires the
SAML2_AUTH_REQUEST cookie to complete the flow.
IdP authentication: SUCCESS
Assertion audience: https://old-nexus.example.invalid/service/rest/v1/security/saml/metadata
Expected Nexus base: https://nexus.example.invalid
ACS recipient: https://nexus.example.invalid/saml
SAML2_AUTH_REQUEST cookie: missing
Groups attribute: nexus-academy-readers
Result: login cannot be completed
Do not “repair” this by granting the user a repository role. The failure occurs before authorization. Compare the current Nexus SP metadata with the IdP registration, preserve the intended base URL, and test in a private browser after cookie/proxy corrections.
4. OIDC: validate issuer, redirect, keys, then claims
| Symptom | Likely cause | Evidence |
|---|---|---|
| Immediate redirect error | Redirect URI not registered or wrong authorization endpoint | Provider application + browser redirect URI |
| Invalid token after provider login | Issuer, client secret, signing algorithm/JWK mismatch | OIDC config and provider discovery/JWK document |
| PKIX path building failed | Provider certificate not trusted by Nexus | TLS chain and Nexus truststore option; Pro 3.92+ for custom cert support |
| Login succeeds; no roles | Groups claim name/value or external mapping mismatch | Decoded non-secret claim names + Nexus mapping |
| User identity fields empty/wrong | Username/email/name claim mapping | Configured claim fields versus token payload |
Never log raw access tokens or client secrets to an evidence packet. A claim-name inventory and token header metadata are usually enough for mapping diagnosis.
5. Rotated secret or certificate not deployed
Rotation incidents often look like network failures because authentication suddenly stops at a known cutover time. Compare timestamps with the change record. For an LDAP bind password, prove the service account works with the new secret and that Nexus was updated. For SAML signing keys, confirm new IdP metadata/signing certificate. For OIDC client-secret rotation, confirm both provider and Nexus hold the same active secret.
Certificate changes must be distinguished from hostname verification. Importing a CA cannot fix a certificate issued to the wrong host. Likewise, changing reverse-proxy headers cannot fix a bad OIDC issuer.
6. Authentication rate limiting is not a network outage
Current Nexus authentication attempt rate limiting is enabled by
default. The documented defaults are three consecutive failures, a
30-second base delay, and a maximum delay of 900 seconds. When
throttled, Nexus returns 429 Too Many Requests with
Retry-After. It applies to Basic and token-based
authentication; SAML SSO login attempts are handled by the IdP
instead.
HTTP/1.1 429 Too Many Requests
Retry-After: 30
Content-Type: application/json
{"message":"Authentication attempts are temporarily rate limited"}
The wrong response is to restart Nexus or change firewall rules. Preserve the 429, stop retry storms, wait the indicated interval, fix the bad credential, then make one controlled request.
7. Authentication success can still produce authorization failure
A 403 after successful login is usually an authorization question: external group changed, role mapping is stale/wrong, group name differs in case, or the mapped Nexus role lacks the required privilege. Return to the Chapter 14 matrix: test the exact repository/path/action and inspect every role that can grant it.
8. Performance boundaries
| Layer | Can affect auth? | Do not confuse with |
|---|---|---|
| LDAP latency/cache | Yes | Blob-store throughput |
| IdP redirect/token endpoints | Yes for SAML/OIDC | Nexus proxy-cache hit rate |
| Reverse proxy/TLS | Yes | Repository group member order |
| Nexus database | Can affect security-config/session operations | External directory lookup itself |
| Blob store | Normally artifact-byte path after authorization | LDAP bind/search |
| JVM/task load | Can raise overall response latency | A specific invalid audience/claim error |
| Package-client local cache | Can hide repository requests | Browser SSO state |
9. Minimal incident evidence packet
- timestamp + Nexus version/edition/runtime;
- active realm IDs/order;
- caller type: browser, Basic/token package client, local account;
- non-secret endpoint/issuer/entity IDs;
- LDAP stage reached: connect, bind, user search, group search;
- SAML/OIDC stage reached: redirect, validation, claims, mapping;
-
HTTP status including 401/403/429 and
Retry-Afterif present; - mapped role IDs/privilege IDs;
- certificate fingerprints, not private keys;
- the one correction applied and controlled retest.
10. Knowledge check
Why is a 429 different from a DNS failure?
Nexus received and processed the authentication attempt but throttled repeated failures; Retry-After is direct evidence of that layer.
An LDAP user is found but has no Nexus roles. What is the next likely layer?
Directory group resolution and external group-to-role mapping.
What does a missing SAML2_AUTH_REQUEST cookie suggest?
A browser/SSO flow problem before repository authorization; current Nexus SAML requires that cookie.
Why should OIDC troubleshooting avoid logging raw access tokens?
They are bearer credentials; claim names and non-secret metadata can diagnose mapping without exposing reusable secrets.
What is the least-destructive response to a stale role mapping?
Correct the external group/mapping or refresh the relevant supported auth state, then retest; do not broaden privileges globally.
11. Next step
Lesson 5 combines the model into one operator checkpoint: a synthetic LDAP integration, exact external group mapping, fake bind-secret rotation, three independent authentication failures, recovery-path verification, and cleanup.
Official references and version notes
- Sonatype: Authentication and Realms.
- Sonatype: LDAP — bind/search, user/group mapping, LDAP cache, LDAPS trust.
- Sonatype: SAML — Pro-only browser SSO, metadata, ACS, signing, external role mapping.
- Sonatype: OpenID Connect — self-hosted Pro from 3.86, claim mapping, OAuth2 realm, truststore support.
- Sonatype: Security Management API — users, roles, privileges, realms and Pro OIDC configuration endpoints.
- Sonatype: Authentication Attempt Rate Limiting.
- Self-Hosted Nexus Repository Feature Matrix — LDAP Community/Pro; SAML and User Tokens Pro.
- Sonatype: Download and Java Runtime Compatibility Matrix.
Version-sensitive statements were rechecked on 2026-08-26. The current official direct-download page lists Nexus Repository 3.95.0. Nexus 3.87+ on H2/PostgreSQL requires Java 21. The mandatory learning path is Community-compatible and models external identity with local fixtures; SAML and OIDC are optional Pro-only integrations for self-hosted Nexus.
Keep the academy open
Support free, practical DevOps education.
Every lesson is designed to remain readable in a browser, downloadable from GitHub, and usable without a paid learning platform. Contributions help expand and maintain the curriculum.
0x716c4Ab160C4B66F31a28AE2448BfF68fc3a2ef0
Send only Ethereum/ERC-20 compatible assets to this
address.