sqlnet.ora SQLNET.AUTHENTICATION_SERVICES en Windows & Unix

Confieso que mi relación laboral con las consultorías la mayoría de la veces ha estado en términos "delicados", cuando me toca coordinar o recibir un proyecto procuro apegarme a lo que se establece en el libro  Análisis y Diseño de Sistemas - Kendall & Kendall (http://www.pearsoneducacion.net/kendall/). Lo que nos ha llevado a severas discusiones acerca de lo que pretenden entregar y lo que deben entregar. Pero bueno, ese no es el tema de esta publicación, el tema de que manera afecta las conexiones locales y remotas el archivo sqlnet.ora. 

Hace un par de días recibí un ambiente de Oracle eBS el cuál entre las cosas que se hicieron mal, las que no se hicieron y las que no se entregaron estaban los passwords de acceso a la base de datos. Después de varios correos me mandaron los passwords de acceso. Por lo regular siempre procuro hacer una validación con conexión remota.

Cuando se lo comenté, la respuesta inmediata fue que YO estaba mal, que él se podía conectar sin problemas.

Definitivamente alguien estaba equivocado, lo primero que me vino a la mente: el password que me mandó era incorrecto, pero antes de reclamar tenía que probar de la misma manera que el consultor estaba conectándose... de manera local.

¡Sorpresa! si me pude conectar. Volví a validar la conexión remota y volvió a fallar. ¡Damn!  Bueno, había que analizar... ¿que puede marcar la diferencia entre una conexión remota y una conexión local?

1. Tnsnames.
2. Listener.

Estos primeros dos quedaron descartados con un tnsping.

Lo siguiente era trabajar del lado del servidor, y de ese lado todo apuntaba al archivo SQLNET.ORA (%ORACLE_HOME%\network\admin) Este archivo controla el acceso a la base de datos por medio de los protocolos de red, métodos de autenticación, definir los tiempos de comprobación de actividad de las sesiones de los clientes. 

Esta es la configuración inicial del archivo:

La única línea existente era: NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT). No había nada más.

Los parámetros más relevantes que se pueden especificar en este archivo son los siguientes:

SQLNET.EXPIRE_TIME
El valor de este parámetro es en minutos. Es utilizado para especificar el intervalo de tiempo en que se validar si las conexiones clientes/servidor están activas. Esto permite asegurar que las sesiones a la base de datos no queden abiertas indefinidamente. El valor recomendado es de 10.

TCP.EXCLUDED_NODES
Aquí se especifican los clientes que NO podrán conectarse a la base de datos. El listado debe ir separado por coma ( , ) y puede ser por la IP (recomendable) o host.

TCP.INVITED_NODES
Aquí se indican los clientes SI podrán conectarse a la base de datos. El listado debe ir separado por coma ( , ) y puede ser por la IP (recomendable) o host.

TCP.VALIDNODE_CHECKING
Se se utilizan los parámetros TCP.INVITED_NODES y TCP.EXCLUDED_NODES. Este debe habilitarse a YES. De lo contrario no se tomará la configuración especificada. Por default el valor es NO.
 NAMES.DIRECTORY_PATH
En este parámetro se especifica el orden y método para resolver el Identificador de Conexión, y el Nombre del Servicio de Red. Los que están especificados son los siguientes:

• TNSNAMES: Resuelve el nombre del servicio de red especificado en el archivo Tnsnames.ora del cliente o desde donde se vaya a hacer la conexión a la BD. 
• EZCONNECT: Permite las conexiones a la base de datos, sin ninguna configuración. Los clientes usan una dirección TCP/IP sencilla, con un nombre de Host, Puerto y servicio opcional (Conn usuario/password@:puerto/nombre_servicio). 

SQLNET.AUTHENTICATION_SERVICES
Permite uno o más servicios de autenticación a nivel de sistema operativo. Este último es el que me interesa.

Para obtener más información acerca de los parámetros de sqlnet.ora pueden consultar la documentación oficial de Oracle Aquí

Este parámetro al igual que los demás, al NO estar especificados en el archivo toman un valor por default durante la instalación. En el caso de este parámetro permite que las conexiones LOCALES que se hagan con el usuario de sistema operativo propietario de la instalación se pueda conectar a la base de datos con privilegios de DBA, por ejemplo:

Tengo una abierta una consola de comandos con el usuario que hizo la instalación del RDBMS y la creación de la base de datos (Para este ejercicio me cambie a un equipo con Sistema Operativo Windows).

Si intento hacer una conexión LOCAL como as sysdba no debo tener ningún problema.

Esto es porque en el archivo sqlnet.ora de este equipo el parámetro SQLNET.AUTHENTICATION_SERVICES tiene el valor NTS. Lo que permite hacer conexiónes con autenticación del sistema operativo (Autentificación de Windows sin contraseña).

 La conexión es con el usuario SYS.

Esto puede ser mal interpretado, ya que se puede tener la impresión de hacer una conexión local con determinado usuario cuando en realidad la conexión que se hace con SYS. En los siguientes ejemplos se emuló la conexión con determinado usuario, uno de ellos no existe y cuando se solicitaba el password se ponía cualquier serie de caracteres, la conexión fue exitosa y en todos los casos el usuario conectado era SYS.

Si el parámetro SQLNET.AUTHENTICATION_SERVICES= (NTS) se pone como comentario:
 

El resultado es el siguiente:

Para los siguientes ejemplos se sigue manejando un entorno local, el host esta especificado como 10.10.10.10 porqué se tiene un "Adaptador de Bucle Invertido" Aquí explique el tema.

Ahora para hacer las conexiónes se tiene que hacer especificando usuario/contraseña y ALIAS de la base de datos especificado en el TNSNAMES.

Para hace la conexión con SYSTEM debe ser sqlplus system@orcl:

 La conexión de SYS como SYSDBA debe ser sys@orcl as sysdba:

 Los usuarios que no tienen privilgios y que intenten conectarse como SYSDBA no podran conectarse:

 Los usuarios inexistentes obviamente no se pueden conectar:

Bueno, ahora a poner las cosas en su lugar, después de las pruebas hay que poner esta configuración en Producción. Así que manos al teclado.

En Unix por default el parámetro SQLNET.AUTHENTICATION_SERVICES permite las conexiones locales sin autentificación, por lo que hay que ponerlo en NONE. 

*Como siempre, antes de editar cualquier archivo de configuración se debe hacer una copia de seguridad.

Listo, ahora probar, primero validar que se rechaza la conexión local sin autentificar:

Y confirmar que se puede hacer la conexión especificando el alias de la base de datos y usuario/password.

Una vez más confirmo que el password esta mal. Ahora si, a poner las cosas y a la gente en su lugar.

Voy con el consultor, me paro tras él y digo: "A ver, por favor intenta conectarte". Primero un sobresalto, voltea a verme con cara de fastidio. Abre una terminal, user/password de sistema operativo, sin problemas se conecta al servidor... 

Ya con una sesión en el servidor empieza a teclear los comandos... disfruto cada tecla que presiona... sqlplus "system as sysdba"...

Pocas veces mi sonrisa ha tenido que esforzarse para permanecer dentro de la dimensiones de mi cara. Sin voltear a verme dice:

-"Algo hiciste, no me deja conectar".

Respiro profundo para ocultar la risa, le contesto "Estoy haciendo que las conexiónes a la base de datos sean por autentificación, por lo que ahora tienes que poner usuario arroba y alias de la base de datos".

-"Y eso para qué" contesta de mala gana.

-"Para demostrarte que el password es incorrecto, Teclea el usuario, presiona enter y te va a pedir el password". Fue mi respuesta

Después de hacerlo y ver el mensaje en pantalla disfrute ver como sus orejas iban tomando el color de su rostro... rojo.

Se levanta de su lugar "a ver, hazlo tú" me dice. Tomo su lugar, presiono CTRL + C para interrumpir la sesión. Empiezo a teclear: sqlplus system@dev, la tecla ENTER casi sale del teclado después de presionarla.

"El password es..." me dice, pero lo interrumpo levantandome del lugar y cediéndolo mientras le contesto "hazlo, no vaya a ser que me equivoque".

Se sienta y teclea varias letras y números terminando con la tecla ENTER... aparece la leyenda "invalid username/password; logon denied" mi sonrisa esta a punto de estallar. Repite la tarea pero ahora más despacio y presionando cada tecla con un solo dedo... "invalid username/password; logon denied", se queda viendo la pantalla un par de segundos.

Le doy unas palmadas en la espalda mientras le digo "Cuando tengas el password correcto me lo mandas" me doy la vuelta y camino a mi lugar, por un momento tengo miedo de una agresión por la espalda... pero estoy trabajando con "Profesionales" así que sigo mi camino. Al llegar a mi lugar lo primero que hago es llamar a mi madre ¿por qué? porqué las mentadas de madre deben ser recordatorio para saludarlas.

Info de "Mentada de madre"