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!
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.keytabUma 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)
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