No post anterior fiz uma breve introdução de como conectar no Oracle autenticando pelo Windows Active Directory (Oracle Active Directory)
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!
![oracle autenticação active directory](https://static.wixstatic.com/media/0366b6_8062c1c84cad41469f9a50b2d7225647~mv2.png/v1/fill/w_69,h_25,al_c,q_85,usm_0.66_1.00_0.01,blur_2,enc_auto/0366b6_8062c1c84cad41469f9a50b2d7225647~mv2.png)
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.
![oracle autenticação active directory token](https://static.wixstatic.com/media/0366b6_d9fc8e39dc8c48aa96b46a542a11f038~mv2.png/v1/fill/w_56,h_48,al_c,q_85,usm_0.66_1.00_0.01,blur_2,enc_auto/0366b6_d9fc8e39dc8c48aa96b46a542a11f038~mv2.png)
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.
![oracle autenticação active directory](https://static.wixstatic.com/media/0366b6_0f2ac468654c4b0495253f98a6fadeb6~mv2.png/v1/fill/w_78,h_19,al_c,q_85,usm_0.66_1.00_0.01,blur_2,enc_auto/0366b6_0f2ac468654c4b0495253f98a6fadeb6~mv2.png)
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.
![oracle autenticação active directory](https://static.wixstatic.com/media/0366b6_fcdf63de3ef24440af247471b4c4dd46~mv2.png/v1/fill/w_81,h_26,al_c,q_85,usm_0.66_1.00_0.01,blur_2,enc_auto/0366b6_fcdf63de3ef24440af247471b4c4dd46~mv2.png)
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!!!
![oracle autenticação active directory](https://static.wixstatic.com/media/0366b6_60b5475deffa45eda7cf9672d56e90bb~mv2.png/v1/fill/w_56,h_48,al_c,q_85,usm_0.66_1.00_0.01,blur_2,enc_auto/0366b6_60b5475deffa45eda7cf9672d56e90bb~mv2.png)
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...
![oracle autenticação active directory](https://static.wixstatic.com/media/0366b6_4d33a47e76754291876efa4680335fa0~mv2.png/v1/fill/w_69,h_25,al_c,q_85,usm_0.66_1.00_0.01,blur_2,enc_auto/0366b6_4d33a47e76754291876efa4680335fa0~mv2.png)
- 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.
![oracle autenticação active directory](https://static.wixstatic.com/media/0366b6_9de0f42f219c44c6859b095cfb2431bd~mv2.png/v1/fill/w_66,h_49,al_c,q_85,usm_0.66_1.00_0.01,blur_2,enc_auto/0366b6_9de0f42f219c44c6859b095cfb2431bd~mv2.png)
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:
![oracle autenticação active directory](https://static.wixstatic.com/media/0366b6_6fdcb10245ab4561ba94c8b97cc37948~mv2.png/v1/fill/w_82,h_65,al_c,q_85,usm_0.66_1.00_0.01,blur_2,enc_auto/0366b6_6fdcb10245ab4561ba94c8b97cc37948~mv2.png)
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"
![oracle autenticação active directory](https://static.wixstatic.com/media/0366b6_bc689701f63b4986a3fd6bbb61cdef2c~mv2.png/v1/fill/w_78,h_27,al_c,q_85,usm_0.66_1.00_0.01,blur_2,enc_auto/0366b6_bc689701f63b4986a3fd6bbb61cdef2c~mv2.png)
Agora vamos carregar o token o usuário prodapp01 e prodapp02.
![oracle autenticação active directory](https://static.wixstatic.com/media/0366b6_991e303f186545e48e9ba7663f842c73~mv2.png/v1/fill/w_79,h_28,al_c,q_85,usm_0.66_1.00_0.01,blur_2,enc_auto/0366b6_991e303f186545e48e9ba7663f842c73~mv2.png)
Verificando o status dos 2 tokens:
![oracle autenticação active directory](https://static.wixstatic.com/media/0366b6_5ac051d665e740c98033927e326f10cf~mv2.png/v1/fill/w_83,h_45,al_c,q_85,usm_0.66_1.00_0.01,blur_2,enc_auto/0366b6_5ac051d665e740c98033927e326f10cf~mv2.png)
Pronto, uma vez os tokens devidamente carregados, vamos montar um novo tnsnames, mas porque fazer isso?
![oracle autenticação active directory](https://static.wixstatic.com/media/0366b6_9a11664f72004bd5b27c11825376d9c7~mv2.png/v1/fill/w_48,h_22,al_c,q_85,usm_0.66_1.00_0.01,blur_2,enc_auto/0366b6_9a11664f72004bd5b27c11825376d9c7~mv2.png)
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:
![oracle autenticação active directory](https://static.wixstatic.com/media/0366b6_a6ff8b1687c94842b3f282d4e945e7a3~mv2.png/v1/fill/w_83,h_45,al_c,q_85,usm_0.66_1.00_0.01,blur_2,enc_auto/0366b6_a6ff8b1687c94842b3f282d4e945e7a3~mv2.png)
Agora vamos fazer a conexão com os 2 usuários para ver se tudo está ok.
![oracle autenticação active directory](https://static.wixstatic.com/media/0366b6_7fb12bd7c71340c8a6ea533ef4c21fc9~mv2.png/v1/fill/w_73,h_58,al_c,q_85,usm_0.66_1.00_0.01,blur_2,enc_auto/0366b6_7fb12bd7c71340c8a6ea533ef4c21fc9~mv2.png)
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)
Autor: Diogo Fernandes - diogo.fernandes@datacosmos.com.br
Linkedin: https://www.linkedin.com/in/diogo-sfg/
Link do artigo original: https://www.linkedin.com/pulse/draft/AgHxUYvoCdiSVAAAAYmTx53_LO9QgHZdsLSVuI8a8teV_BuUPb8n2JwgeiaaGqoS7tfNdJU