3 · Infraestructura·7 min de lectura

Las cuentas se llamaban planta4 y contabilidad2. Nadie podía saber quién había ocupado la licencia.

10 sep 2026InfraestructuraMétodoIdentidad

Cuando el gestor de licencias de un ERP dice quién tiene un asiento ocupado, dice algo así:

Invoke-WebRequest
(Invoke-WebRequest 'http://127.0.0.1:1947/_int_/tab_sessions.html').Content

"fn":"Ventas", "usr":"planta4", "scrn":"375", "seats":"1"
Un asiento del módulo de Ventas, tomado por planta4, en la sesión 375 del servidor.

`planta4` no es nadie. Es una cuenta de Windows compartida, con nombre de puesto de trabajo, que usa quien se siente en esa máquina. No se le puede pedir que suelte el asiento, no se sabe a quién frenó, y no se puede escribir un reporte con eso.

Del otro lado, dentro del ERP, los usuarios sí son personas. Pero son otros nombres: iniciales, nombres de pila, el apellido de alguien. Dos padrones que describen a la misma gente y no se tocan en ningún punto.

Ése es el estado normal de casi cualquier servidor con años encima. Y es la razón por la que las alertas de infraestructura suelen terminar en «alguien dejó algo abierto» — porque alguien es literalmente todo lo que el sistema sabe.

El plan obvio, y por qué es malo#

Lo primero que se le ocurre a cualquiera —se nos ocurrió a nosotros— es levantar un censo. Preguntar quién usa qué cuenta, anotarlo en una hoja, y listo.

Ese documento es una foto, y las fotos se pudren. Alguien cubre una incapacidad, entra un empleado nuevo, dos personas se turnan la misma máquina en distintos horarios. A los quince días la hoja dice una cosa y el servidor otra, y como nadie recuerda cuándo se llenó, se le sigue creyendo.

Peor: un censo da trabajo nuevo —mantenerlo— para resolver un problema que nadie tenía ganas de resolver. Eso se abandona. Siempre.

Lo que el sistema ya guardaba#

La base de datos del ERP publica una tabla interna con todas las conexiones abiertas. Entre sus columnas hay una que casi nadie usa:

ColumnaQué guarda
MON$USERquién se autenticó en el ERP
MON$REMOTE_PIDel número de proceso del programa que se conectó

Columnas del catálogo de conexiones vivas. La primera es la persona; la segunda, el identificador que el sistema operativo le dio a su programa.

Y Windows, por su lado, sabe perfectamente en qué sesión corre cada proceso. El número de proceso es el mismo de los dos lados.

Es un gancho, y es de los buenos: no es una coincidencia de nombres, ni una heurística por horario, ni un parecido. Es el mismo número, puesto por el sistema operativo, que ninguno de los dos padrones eligió.

select
select mon$user, mon$remote_pid from mon$attachments;

MON$USER    MON$REMOTE_PID
========    ==============
ARANDA                6248
ARANDA               15468
OSORIO                8480
BELMONT              12424
BELMONT              20468

Get-Process -Id 6248,15468,8480,12424,20468 | Select-Object Id, SI

Id SI -- -- 6248 372

salida
15468 372
 8480 373
12424 375
20468 375
El cruce, en vivo. Cinco procesos, tres personas, tres estaciones. Cero preguntas hechas a nadie.

Y de paso apareció algo que ningún censo habría capturado nunca:

Get-Process
Get-Process Microsip | Select-Object Id, SI, StartTime

Id SI StartTime -- -- --------- 1060 328 02/09/2026 08:12

Un programa abierto desde hace seis días en una sesión desconectada… sin ninguna sesión en el ERP detrás.

Es el lanzador, el menú inicial, abierto sin que nadie se haya autenticado. Parece un fantasma acaparando una licencia y no consume ningún asiento. Si hubiéramos hecho el censo, esa cuenta habría quedado apuntada como usuaria de un módulo que nunca abrió.

Por qué se guarda como acumulado y no como foto#

La tentación es tomar el cruce de hoy y llamarlo el padrón. No: se guarda cada observación, y cada pareja lleva la cuenta de cuántas veces se ha visto.

Así, si alguien cubre a un compañero un martes, esa pareja aparece una vez y no borra al titular, que lleva doscientas. Y si un cambio es de verdad —alguien se movió de puesto—, se nota porque la pareja nueva empieza a ganar terreno, no porque alguien avisó.

El padrón deja de ser una declaración y pasa a ser una medición. Nadie tiene que mantenerlo, y por lo tanto nadie lo va a abandonar.

Una trampa que casi nos come#

El cruce se hace contra la base del cliente, y esa consulta tiene una caché por si la base no responde. La primera versión aceptaba la respuesta viniera de donde viniera.

Un número de proceso sólo significa algo ahora. El sistema operativo los recicla: el proceso 6248 de hace dos horas y el 6248 de este momento no tienen por qué ser la misma persona. Cruzar una lista guardada contra procesos vivos no habría dado un error — habría dado parejas inventadas, con nombre y apellido, indistinguibles de las buenas.

Se corrigió para rechazar cualquier respuesta que no venga en vivo:

salida
if (r.source !== 'bridge') return { cruce: null, motivo: 'dato de cache' }
Si el dato viene de caché, no se mide. Preferimos no saber a saber mal.

Lo que sigue#

Con una semana de observaciones, la conversación cambia de tono. Ya no es «hay que ponerle nombre a las cuentas» —que suena a orden y a trabajo para alguien— sino «esta máquina la usa esta persona el 94% del tiempo, aquí está el registro».

Es la misma diferencia de siempre: llegar con el dato o llegar con la corazonada. Y el dato ya estaba ahí, en una columna que nadie había abierto, esperando a que alguien se preguntara si el sistema ya sabía la respuesta antes de ir a preguntarle a la gente.


Caso real, anonimizado. Las cuentas, los usuarios y los nombres de máquina fueron sustituidos; los mecanismos, los tiempos y el comportamiento de las herramientas son los que medimos.