GH Genaro HernandezThe Journal
THEJOURNAL-INCIDENT ES
Back to incidents

INC-2026-0001 / Closed

Authentication Service Disruption

GLC experienced a partial authentication disruption caused by an undocumented DNS dependency. The correct authentication service was healthy, but some users were routed to a legacy identity endpoint.

01

Incident Overview

A partial authentication disruption prevented multiple operational users from accessing applications required for daily logistics work.

The investigation found that the authentication platform, portal, Active Directory, and network were individually healthy. The failure lived in how some users discovered the authentication service.

Duration: 92 minutesSeverity: HighOrganization: Grupo Logístico del CaribeRoot category: Dependency failure
02

Executive Report

The primary impact was operational delay: warehouse preparation slowed, customer service had limited order visibility, and dispatch processing required manual workarounds.

The final executive assessment was that the organization had insufficient visibility into service dependencies after migration work.

Impacted: warehouse, customer service, dispatchStable: email, internet, file services, corporate communicationsFinal state: closed and restored
03

Technical Analysis

Initial hypotheses focused on the authentication platform, domain controllers, web application, and network. Each path was discarded because the components were available and healthy.

The turning point came when affected and unaffected workstations resolved the same service name to different destinations. The incident was not authentication itself; it was service discovery.

Client A resolved identity.glc.local to 10.10.10.15Client B resolved identity.glc.local to 10.10.10.99Only one destination represented the current production service
04

Root Cause Analysis

The immediate cause was that some clients reached an incorrect identity endpoint. The technical cause was a legacy DNS record left behind after a prior migration.

The systemic cause was weak dependency management: validation covered primary authentication flows but not every DNS route used by clients and legacy systems.

Immediate cause: incorrect service destinationTechnical cause: legacy DNS pathOrganizational cause: incomplete dependency inventory
05

Dependency Landscape

The service path was: Operational User -> Operational Portal -> Authentication Service -> DNS Resolution -> Internal DNS Infrastructure.

The business impact path was: failed access -> warehouse delays -> dispatch delays -> customer impact. The dependency failed before users reached the healthy service.

Healthy route: DNS -> current identity service -> authentication successFailed route: DNS -> legacy identity service -> authentication failure
06

Operational Timeline

07:05 first warehouse reports. 07:08 Yessenia escalated multiple affected workstations. 07:12 Laura Santana confirmed operational impact. 07:18 the incident was formally activated.

07:48 DNS investigation began. 07:55 the legacy route was identified. 08:12 correction started. 08:37 service was fully restored.

Longest phase: identifying the hidden dependencyCorrection was faster than diagnosis
07

Lessons Learned

Availability does not guarantee accessibility. DNS is part of the service. Migrations end only when all dependencies and alternate paths are validated.

Operations users are part of the observability system. The first reliable signal came from warehouse operations, not dashboards.

Short term: remove legacy routes and update documentationMedium term: distributed functional validationLong term: service maps and dependency observability