Feb 4, 2020

Error de autenticacion de usuarios OPS$ en versiones 12.1 o superiores [ORA-01017 Invalid Username/password (Doc ID 1927261.1)]

Hola amigos,

 Les comparto un tema que estuve revisando con un cliente dónde tenían una problemática luego de migrar a BD12.2. Les acontece un problema con cuentas de usuario específicamente un problema que afecta a las cuenta del tipo OPS$xxxxx. En dónde hasta antes de la versión 12.1 dichas cuentas podian entrar sin password con autenticación de SO y también podían entrar haciendo uso de clave (ambas alternativas para una misma cuenta). Eso desde 12.1 ya no va más, no podrán utilizar ambos método sólo 1 de ellos. A continuación explico el porque.

Para que quede más claro hasta antes de de 12.1 una cuenta llamada por ejemplo OPS$TEST podía entrar de las siguientes maneras incluyendo ambas:

1.- Usando una password ejemplo:
sqlplus "OPS$TEST/password@ALIAS_TNS"


2.- con autenticación por SO (ejemplo usuario OPS$TEST).
[test@oraclelab ~]$ export TWO_TASK=ALIAS_TNS
[test@oraclelab ~]$ sqlplus /

SQL*Plus: Release 12.1.0.2.0 Production on Mon Feb 3 11:57:35 2020

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

Last Successful login time: Mon Feb 03 2020 11:50:56 -03:00

Connected to:
Oracle Database 12c EE Extreme Perf Release 12.2.0.1.0 - 64bit Production

SQL> exit


El cliente me reporta que sus cuentas ya no pueden ingresar al ambiente de DEV usando la autenticación por SO. Estuve revisando y lamentablemente desde las versiones 12.1 en adelante se comenzó a aplicar un cambio de seguridad que afecta a las conexiones del tipo OPS$. Les hago un poco el resumen de lo que menciona esta nota de soporte donde se explica el problema (les recomiendo mirarla):
ORA-01017: Invalid Username/password; Logon Denied when using 'OPS$' user with a password (Doc ID 1927261.1)

En dicha se nota se comenta que en las versiones de base de datos anteriores a 12.1 los usuarios del tipo OPS$xxx podían conectarse a la base de datos de cualquiera de las dos maneras anteriormente comentadas (cualquiera de ellas al mismo tiempo a pesar que la cuenta fuese creada usando password: identified by xxx ). Pero desde 12.1 especialmente por el tema de cloud esto cambio. Esta situación no les pasaba en la base de datos OnPrem pues  la versión de base de datos era 11.2 y podían conectarse sin problemas de las dos maneras anteriores para una misma cuenta OPS$xxx. Pero en 12.1 la nota anterior explica que ahora una cuenta de ese tipo OPS$ solo podrá conectarse sólo de 1 manera a la vez, o usando password o con autenticación de SO, pero no ambas al mismo tiempo.

Para el ejemplo que me comentaba el cliente para una cuenta llamada OPS$C_VMERYV en esta versión en la que esta el ambiente de bd cloud 12.2 sólo podrá conectarse usando password (en el OmPremise la cuenta fue generada de esa manera create user OPS$C_VMERYV identified by xxxx pero en esa versión 11.2 era válido conectarse de las dos maneras como comenté anteriormente )


La única solución que proponen que para que la cuenta pueda conectarse usando la autenticación de SO (sin password y para seguir usando el acceso con la variable TWO_TASK) se debe alterar esa cuenta forzando a que sólo entre via ese modo es decir:

alter user "OPS$C_VMERYV" identified externally ;

Aquello permitirá que la cuenta pueda conectarse sin usar password, pero no dejará que dicho usuario OPS$xxxxx se conecté desde otra aplicación en otro computador usando una clave. Ese es el punto del tema y es una gran problemática para algunos clientes que usan autenticación de OPS$xxxx.

En la misma nota profundizan un poco más al respecto del porque de este comportamiento y este cambio (Por eso les recomiendo leerla):

 La única alternativa como comenté anteriormente sería como dice la nota que todas las cuentas que necesiten conectarse sin usar password se les fuerze el método de identificación externa, pero aquello invalidará que esas mismas cuentas puedan conectarse desde otros ambientes usando una clave. 

Espero sirva para que tengan cuidado en migraciones a versiones 12 o superiores sobre todo para cloud que con la seguridad Oracle se está poniendo un poco más exigente.

No comments:

Post a Comment