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"

La misteriosa relación de Oracle E-Business Suite y NLS_LANGUAGE

En el equipo con el que estoy trabajando tengo instaladas varias herramientas para la realización de las funciones del día a día, por ejemplo:

• SQL Developer.
• Oracle Client 10g
• Oracle RDBMS 10g
• TOAD 9.6

Esto un poco por decidía y otro porque no he encontrado una herramienta que realmente cumpla mis expectativas al 100%, el caso es que un día me di cuenta que si me conecto con ellas a la base de datos (10.2.0.4) de la aplicación Oracle E-Business Suite no siempre se obtienen los mismos resultados ¿¡!?.

Vayamos a los hechos.

Estando conectado a la BD desde SQL Developer a la base de datos ejecuto una simple consulta para validar los datos de la misma.

El usuario con el que me conecte es el propietario de la tabla, en este caso es APPS.

Hasta aquí nada nuevo, nada extraña... todo Ok. pero si ejecuto unas consultas sobre una determinada tabla los resultados son los siguientes:

Supongamos, la escena:

Suena la extensión... contesto y...

Usuario - ¡Hola! Por favor me puedes mandar el listado de registros de la tabla PER_PEOPLE_V7
Yo -Claro, dame unos minutos...

Cuelgo y voy abriendo SQL Developer. Me conecto a la BD, tecleo usuario y password, la conexión se hace de manera exitosa, empiezo a teclear y los comandos aparecen en pantalla y presiono ENTER, 

Yo - (Pensando) mmmm, no tiene nada, a ver un count... no, no tiene nada.

Levanto el auricular de la extensión, marco los dígitos...

Usuario - ¿Si?
Yo - Hola, oye... esta tabla que me estas solicitando... ¿que información es la que esperas que te mande?
Usuario - Ah mira, es el listado del Personal que esta asignado a un usuario dentro de la aplicación, queremos hacer una depuración y bueno, pensamos que podemos empezar por saber que personal existe.
Yo -  Perfecto, solo era una pequeña duda, estoy trabajando en ello, dame unos minutos.
Usuario- Bye.

Cuelgo y mi mano va al teclado, sé que algo esta mal... es lo bueno; lo malo... es que no tengo ni la menor idea de qué sea. Acudo a quién siempre me ha ayudado en estos momentos de ignorancia e incertidumbre... Google. Después de varios minutos y buscar, buscar y buscar, se empieza a ver luz al final del túnel, parece que algo tiene que ver NLS_LANGUAGE.

Reviso el valor que tiene la sesión desde SQL Developer.

Inicio una sesión desde SQL Plus, habilito la conexión a la base de datos y hago unas consultas.

Lo siguientes es cambiar el valor del parámetros de la sesión que tengo en SQL Developer.

Lanzó un count para validar si ya muestra información.

¡Perfecto! ahora a extraer la información.

Como siempre, quedo para cualquier duda o comentario al respecto.

Oracle Database, DHCP y Loopback adapter

 Es muy común que cuando se empieza en el misterioso mundo del RDBMS de Oracle se haga la instalación  en equipos con Sistema Operativo Windows que no tienen un dirección IP fija, es decir, utilizan el comúnmente conocido DHCP para tomar una dirección IP (Si no tienes idea de lo que es una dirección IP, te recomiendo des una leída al siguiente articulo de Wikipedia Aqui).

También es muy común que nunca se lean los Requisitos de Instalación, ahí se menciona que se debe hacer cuando se vaya a instalar en equipos con DHCP.

"Dynamic Host Configuration Protocol (DHCP) assigns dynamic IP addresses on a network. Dynamic addressing allows a computer to have a different IP address each time it connects to the network. In some cases, the IP address can change while the computer is still connected. You can have a mixture of static and dynamic IP addressing in a DHCP system.

In a DHCP setup, the software tracks IP addresses, which simplifies network administration. This lets you add a new computer to the network without having to manually assign that computer a unique IP address. However, before installing Oracle Database onto a computer that uses the DHCP protocol, you must install a loopback adapter to assign a static, non-routable IP address to that computer"

O lo que es lo mismo:

"Dynamic Host Configuration Protocol (DHCP) asigna direcciones IP dinámicas en una red. Direccionamiento dinámico permite que una computadora tenga una dirección IP diferente cada vez que se conecte a la red. En algunos casos, la dirección IP se puede cambiar mientras la computadora está encendida. Se puede tener una mezcla de IP estática y dinámica en un sistema de direccionamiento DHCP.

En una configuración DHCP, el software rastrea las direcciones IP, lo que simplifica la administración de la red. Esto le permite agregar un nuevo equipo a la red sin tener que asignar manualmente ese equipo una dirección IP única. Sin embargo, antes de instalar la base de datos Oracle en un equipo que utiliza el protocolo DHCP, debe instalar un adaptador de bucle invertido (Loopback adapter) para asignar una estática, no enrutable dirección IP para esa computadora."

La siguiente serie de imágenes muestran como configurar un bucle invertido  o Loopback adapter, como quieran llamarlo. Es sobre un Sistema Operativo Windows 7,  aunque en versiones anteriores la secuencia es muy similar. 

Lo primero es abrir el Asistente para agregar Hardware, para lo cual se teclea el comando hdwwiz.exe.

Debido a que no es un componente "físico" se debe seleccionar la opción de "Instalar el hardware seleccionado manualmente de una lista (avanzado)".

En la siguiente pantalla se debe seleccionar la opción de "Adaptadores de red".

Se debe seleccionar "Microsoft" y "Adaptador de bucle invertido de Microsoft" respectivamente en las siguientes opciones. 

En la siguiente pantalla se debe confirmar lo que se desea instalar, así que una vez confirmado que es lo que se desea se continua con la instalación.

De no presentarse errores la instalación se debe completar. En caso de que se presente un error hay que revisar que se hayan seguido las indicaciones acorde a las imágenes. 

Hasta este punto se ha completado la instalación, a continuación la configuración. Lo primero es abrir el Panel de Control y entrar a la opción de Redes e Internet.

Posteriormente entrar a la opción Centro de redes y recursos compartidos y posteriormente entrar a la opción Cambiar configuración del adaptador.

Se desplegará una pantalla con las Conexiones de red existentes en la computadora que se esta utilizando. La que nos interesa es la que dice "Adaptador de bucle invertido". Vamos a entrar a las propiedades de ese adaptador. Clic con el botón derecho del Mouse y posteriormente clic en Propiedades.

Ya dentro de las propiedades, vamos a seleccionar el elemento Protocolo de Internet versión 4 (TCP/IPv4) y posteriormente clic en Propiedades. En la pantalla de propiedades hay que proporcionar  algunos datos, los 2 principales son Dirección IP y Máscara de subred. 

El primero de ellos debe ser un valor ficticio, recomiendo usar 10.10.10.10, así nos evitamos de muchos problemas (y explicaciones). La Máscara de subred no debe tener problema si le asignamos la que se maneja por default 255.255.255.0

El valor de Puerta de enlace predeterminada se puede omitir, en este ejemplo se esta poniendo un valor que corresponde al de la red en la que esta el equipo donde esta conectada la computadora. Una vez proporcionados los datos se debe hacer clic en Aceptar.

Si se especificó un valor en Puerta de enlace predeterminada se desplegaran unos mensajes de advertencia, en ambos se debe hacer clic en Si.

Hasta este punto se ha terminado la mitad de la configuración, estamos por entrar a la configuración final. Se debe editar el archivo "hosts", este archivo se encuentra en la ruta:

C:\Windows\System32\drivers\etc\hosts, aunque dependiendo de la instalación puede variar.

Para editar el archivo vamos a utilizar Notepad.

En este archivo vamos a agregar una línea que haga referencia a la IP 10.10.10.10 y asociarla a un nombre "servidor".

Para este ejercicio a la IP 10.10.10.10 se le asigna el nombre de ORCL (puede ser cualquier nombre). Una vez hecho el cambio se debe grabar el archivo.

Hay que probar que los cambios hayan sido registrados de manera correcta. Para lo cual se puede hacer un ping tanto al nombre como a la IP.

La última prueba es hacer la instalación del RDBMS, la parte de la validación de requisitos de instalación debe ser correcta y obvio, la instalación finalizar sin errores.

Espero les sea de utilidad, cualquier duda o comentario al respecto no duden en contactarme.