Como autenticar vários usuários de aplicações utilizando o A.D

No post anterior fiz uma breve introdução de como conectar no Oracle autenticando pelo Windows A.D.

Mas de fato o que são tokens? Como carregar vários tokens manualmente na estação? É isso que vamos ver neste post.

De forma macro, como tudo isso funciona? Vamos la!

Assim como descrito no artigo anterior, nos geramos um arquivo chamado databasenode1.keytab com o comando ktpass, do qual foi executado no A.D.

Posteriormente, transferimos esse arquivo para o servidor de banco de dados e referenciamos esse arquivo la no sqlnet.ora com o arquivo krb5.conf que contém as informações do A.D, ou seja, neste momento criamos uma ponte entre o Oracle e o A.D para se comunicarem através do protocolo kerberos.

SQLNET.KERBEROS5_CONF=/u01/app/oracle/product/19.0/dbhome_1/network/admin/krb5.conf
SQLNET.KERBEROS5_KEYTAB=/u01/app/oracle/product/19.0/dbhome_1/network/admin/databasenode1.keytab

Uma vez isso pronto, agora vamos para a parte de como a maquina cliente carregar o token.

Como a imagem acima demostra, a maquina client vai fazer uma requisição de "Credential Cache" essa credential cache é uma autorização que o A.D concederá a máquina client depois que o comando okinit for executado com sucesso, vamos ver como isso funciona na prática.

Acima, executamos o comando okinit para o usuário prodapp01, podemos ver que logo abaixo foi requisitado a senha do usuário, ou seja, nesse momento ele foi até o A.D para validar o usuário, uma vez a senha correta digitada, ele retorna para você uma Credential Cache.

O comando "oklist" sempre será utilizado para verificar o status da credential cache, na imagem acima podemos ver o local onde ela esta "armazenada" na linha "Ticket cache: File", a quem pertence "prodapp01@DATACOSMOS.COM.BR" e a validade "07/24/23 15:58:04". O local de armazenamento pode ser definido pelo sintaxe "-c" no comando "okinit" ou definir um local padrão no sqlnet.ora.

PS: O arquivo é criptografado.

SQLNET.KERBEROS5_CC_NAME=C:\temp\cc_name

Agora que a credential cache está na nossa máquina client, vamos fazer a conexão com o Oracle, esse passo, como funciona? Vamos la!!!

A maquina client, se apresenta ao Oracle com a seguinte apresentação:

- E ai Oracle! Blz? Tenho uma Credential Cache aqui, e gostaria de conectar.

Oracle:

- E ai jovem! blz? Espera aí que vou verificar com o AD...

- A.D, blz? Tem uma máquina client aqui com a credential cache do usuário "prodapp01" posso liberar a conexão?

A.D:

- Oracle, essa credencial que você me informou é valida, pode liberar o acesso.

Oracle:

- Blz! Vou liberar o acesso

Acabamos de ver a parte "gráfica", agora vamos para o "bash".

Na prática, é isso que acontece:

PS: Não façam isso em PRODUÇÃO hehe.

No banco:

[oracle@databasenode1 admin]$ sqlplus / as sysdba 


SQL*Plus: Release 19.0.0.0.0 - Production on Tue Jul 25 15:08:03 2023
Version 19.17.0.0.0


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




Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.17.0.0.0


SQL> alter user prodapp01 identified externally as 'prodapp01@DATACOSMOS.COM.BR' ; 


User altered.

PS: Esse alter user só precisa ser feito na primeira vez.

Na máquina de aplicação:

Agora que compreendemos como acontece a negociação com a credential cache adquirida pelo A.D vamos para a parte de como conectar mais de um usuário de aplicação.

Mas antes vamos a uma breve história, até na versão 19.9, não era possível utilizar mais de uma conexão partindo da mesma sessão, mas qual era a limitação?

Não existia a possibilidade do tnsnames ler várias credential cache ao mesmo tempo, porém, a partir da versão 19.10 do Oracle Client, possibilitou carregar mais de um token/credential cache e apontá-los diretamente no tnsnames para a conexão correta. Mas de fato como isso funciona na prática e como fazer?

Utilizaremos como exemplo o usuário prodapp01 e prodapp02.

Antes de carregar os tokens dos usuários, vamos destruir o que está no caminho "default"

Agora vamos carregar o token o usuário prodapp01 e prodapp02.

Verificando o status dos 2 tokens:

Pronto, uma vez os tokens devidamente carregados, vamos montar um novo tnsnames, mas porque fazer isso?

Quando temos que acessar via "strong authentication" com um tnsnames normal, ele sempre vai procurar a credential default e não é esse nosso objetivo, para realizarmos a conexão com as credential's que carregamos anteriormente vamos montar o seguinte tnsnames.ora.

PRODAPP01_KERB =
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=databaseno1.host)(PORT=1521)) 
    (CONNECT_DATA=
    (SERVICE_NAME=KERB)) 
      (SECURITY=(KERBEROS5_CC_NAME = c:\temp\cc_prodapp01) 
      (KERBEROS5_PRINCIPAL = prodapp01@DATACOSMOS.COM.BR)
    )
  )


PRODAPP02_KERB = 
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=databaseno1.host)(PORT=1521)) 
    (CONNECT_DATA=
    (SERVICE_NAME=KERB)) 
      (SECURITY=(KERBEROS5_CC_NAME = c:\temp\cc_prodapp02) 
      (KERBEROS5_PRINCIPAL = prodapp02@DATACOSMOS.COM.BR)
    )
  )

Neste novo tnsnames temos 2 campos adicionais:

SECURITY=(KERBEROS5_CC_NAME = c:\temp\cc_prodapp02)
      (KERBEROS5_PRINCIPAL = prodapp02@DATACOSMOS.COM.BR)

Esses 2 parâmetros permite que utilizemos a credential cache correta que nos carregamos anteriormente:

Agora vamos fazer a conexão com os 2 usuários para ver se tudo está ok.

Podemos ver que agora as aplicações podem utilizar vários usuários "strong authentication" oriundo da mesma sessão do windows.

Sqlnet utilizado nesta configuração:

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT
SQLNET.AUTHENTICATION_SERVICES= (KERBEROS5,KERBEROS5PRE,BEQ)
SQLNET.FALLBACK_AUTHENTICATION=TRUE
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=ORACLE
SQLNET.KERBEROS5_CONF=C:\Oracle\CLIENT19C\network\admin\krb5.conf
SQLNET.KERBEROS5_CLOCKSKEW=6000
SQLNET.KERBEROS5_CONF_MIT=TRUE
SQLNET.KERBEROS5_CC_NAME=C:\temp\cc_name)

Espero que este artigo contribua para aumentar a segurança do seu banco de dados e de suas aplicações.

Grande abraço!