Menu de navegação

[jgomezParticipante]

Boa tarde pessoal!

Estou enfrentando um problemão, migrei um Oracle XE para Standard e está rodando tudo bem, acesso aos dados, inserção de dados etc…

Mas precisei criar um novo usuário concedo as permissões de acesso e mesmo assim ele não acessa a aplicação, sempre recebo erro de conexão, mesmo dentro do servidor.

E isso só acontece com este novo usuário, qualquer outro usuário que já existia antes da migração funciona perfeitamente.

Alguém tem alguma dica ?, estou entrando em pânico já.

Attachments:

• SSJ.PNG

[José Laurindo ChiappaModerador]

Bom, vc não diz mas esse printscreen parece demonstrar que a conexão ** não está ** sendo feita por um client Oracle diretamente, mas sim por alguma aplicação externa ao banco, e talvez (dado o “SQLserver” aí misturado na mensagem) tenha middleware tipo ODBC aí na parada, algum link/conexão compartilhada entre um banco sqlserver e esse banco Oracle…
Acredito, dado esse cenário E dado o fato de que SQLs contendo comandos DML funcionam, que vc deve ter permissões ** FORA ** do banco que estejam pegando – por exemplo, tua aplicação mantém em alguma tabela interna um cadastro de usuários da aplicação e suas permissões na aplicação, e vc não cadastrou esse novo usuário nas tabelas da aplicação… Ou talvez nas camadas FORA do banco (digamos, arquivo de config do ODBC) esse novo usuário não esteja presente…
Enfim, pra mim o meu palpite é que vc tem alguma permissão ** FORA DO DATABASE ** sendo controlada pela aplicação ou por middleware ou por componentes / bibliotecas usadas pela aplicação – não tem o que nós, especialistas de banco, fazermos nesse caso, é reconfig de aplicação e de seus componentes…

Apenas por questão de método, para confirmar que não tem nada pegando no banco, tente checar no banco XE original e no novo banco se :

a. nesse database vc tem ROLES de usuário que precisem ser dadas ao novo usuário (além de permissões que vc dá diretamente pro usuário, no RDBMS Oracle podemos ter GRUPOS de PERMISSÔES, as chamadas ROLES, que podem ser atribuídas a um usuário)

b. veja se vc tem PROFILES nesse database que precisem ser alterados/direcionados a esse novo usuário : PROFILEs são perfis de uso de recursos que vc permite ou nega a um grupo de usuários

c. veja se vc tem TRIGGERS que possam estar disparando , e no código dessas triggers não está previsto o novo usuário

d. veja se vc tem DATABASE LINKS particulares que necessitam ser criados no schema desse novo usuário

==> e também, conectado com usuário SYSDBA, rode no sqlplus (ou peça pro DBA rodar) o script abaixo que lista TODAS as permissões dadas a um usuário uma vez no banco xe contra um usuáio pré-existente e uma outra vez no novo banco contra o novo usuáio : se assegure que as perms são as mesmas nos dois bancos pros dois usuários..

Em todas essas verifs de banco não trazendo nada, imho tá Comprovado que é alguma config da Aplicação, do middleware, dos componentes,é coisa FORA DO BANCO, aí não tenho como te orientar mais, nesse caso o escopo foge da minha especialidade…

[]s

Chiappa

[José Laurindo ChiappaModerador]

Uops, ficou faltando eu mostrar o scripot, é este :

— Script de listagem de privs
set echo off
set verify off
set pages 9999
col granted_role form a25
col owner form a15
col table_name form a33
col privilege form a33
ACCEPT username prompt ‘Enter Username : ‘
PROMPT Roles granted to user
SELECT granted_role,admin_option,default_role
FROM dba_role_privs
WHERE grantee=UPPER(‘&username’)
ORDER BY 1;
PROMPT Table Privileges granted to a user through roles
SELECT granted_role, owner, table_name, privilege
FROM ( SELECT granted_role
FROM dba_role_privs WHERE grantee=UPPER(‘&username’)
UNION
SELECT granted_role
FROM role_role_privs
WHERE role in (SELECT granted_role
FROM dba_role_privs WHERE grantee=UPPER(‘&username’)
)
) roles, dba_tab_privs
WHERE granted_role=grantee
ORder by 1,2,3,4;
PROMPT System Privileges assigned to a user through roles
SELECT granted_role, privilege
FROM ( SELECT granted_role
FROM dba_role_privs WHERE grantee=UPPER(‘&username’)
UNION
SELECT granted_role
FROM role_role_privs
WHERE role in (SELECT granted_role
FROM dba_role_privs WHERE grantee=UPPER(‘&username’)
)
) roles, dba_sys_privs
WHERE granted_role=grantee
ORDER BY 1,2;
PROMPT Table privileges assigned directly to a user
SELECT owner, table_name, privilege
FROM dba_tab_privs
WHERE grantee=UPPER(‘&username’)
ORDER BY 1,2,3;
PROMPT System privileges assigned directly to a user
SELECT privilege, admin_option
FROM dba_sys_privs
WHERE grantee=UPPER(‘&username’);
undefine username
— fim do script

salva esse script num arquivo .SQL e o executa via sqlplus, numa conexão adequadamente privilegiada…

[]s

Chiappa

[Natanael AmaroParticipante]

Junior, dado o seu problema, essa mensagem é um erro de TNS na parte da aplicação, verifique o se o tnsnames.ora do cliente não está incorreto, provavelmente o tns esta com o nome de instância errado, ou o host pode ter mudado, verifique e compare o tnsnames.ora de uma máquina que esteja funcionando, e preencha os parâmetros igualmente, deve sanar o problema.

Regards, Amaro!

[jgomezParticipante]

jlchiappa,

Valeu pela aula hehehe..

A conexão é feita através de um cliente instalado no PC, testei vários usuários todos que já existiam estão funcionando perfeitamente, inclusive o meu B) .

Já criei o usuário e adicionei as permissões via SQL Plus e via PL SQL, em ambos o resultado é o mesmo.

O usuário criado consigo conectar ele na base através do PL SQL, só não funciona via aplicação.

Acessei o ambiente XE e criei o usuário da mesma forma, comparei todos os detalhes, roles de acesso, perfil, tablespace padrão etc… no XE funciona, o FULL “no way”. Uma coisa que chamou a atenção é que nas propriedades do usuário criado no XE o campo de expirar a senha está aberto e posso definir este campo, no FULL ele está ativado para expirar a senha e está “cinza” bloqueado sem poder alterar.

Valeu!

[jgomezParticipante]

Amaro,

O problema não é de conexão, o teste foi feito no meu PC e qualquer outro usuário se conecta na aplicação sem erro, já este usuário novo não, só não entendi porque ele disparou este erro como se fosse configuração errada.

Tanto o IP como a instancia estão corretas no tnsnames.ora tanto que outros usuários funcionam perfeitamente.

PS: Adicionei duas imagens, a imagem da esquerda é do STD e a da direita é do XE, notem que apenas o campo de expirar senha é diferente.

Valeu!

[jgomezParticipante]

Em tempo…

Eu faço a criação do usuário direto na aplicação e seleciono as roles que ele terá acesso, mas também posso criar o usuário via PL SQL ou SQL+ e depois só associo ele na aplicação.

Eu costumo criar os usuários na aplicação adiciono as roles que ele terá acesso, e depois via PL SQL, duplico um usuário existente do mesmo depto para ter certeza que as permissões ficaram idênticas.

Abraços!

[José Laurindo ChiappaModerador]

Não uso essa GUI que vc mostra, então não faço Idéia do que representa essa tal “coluna com a password que fica cinza” – vou me ater ao core de banco, mesmo… Em cima disso : vc *** EXECUTOU *** no sql*plus, com um usuário privilegiado (pode ser o SYSDBA) o script que mostrei e que lista as permissões, uma vez para um usuário que “funciona” e uma vez para o usuário recém-criado em busca de Quaisquer diffs, e CONSULTOU a DBA_USERS pra ver qual o PROFILE assignado pros dois usuários e o status deles, tipo :

==> check do usuário HR :

SQL> select profile, account_status, lock_date, expiry_date, external_name, default_tablespace, temporary_tablespace from dba_users where username=’HR’;

PROFILE ACCOUNT_STATUS LOCK_DATE EXPIRY_DA EXTERNAL_NAME DEFAULT_TABLESPACE TEMPORARY_TABLESPACE

---

DEFAULT OPEN USERS TEMP

SQL> @D:dba_scriptsprivs_by_user
Enter Username : HR
Roles granted to user

GRANTED_ROLE ADM DEF

---

CONNECT NO YES
RESOURCE NO YES

Table Privileges granted to a user through roles

no rows selected

System Privileges assigned to a user through roles

GRANTED_ROLE PRIVILEGE

---

CONNECT CREATE SESSION
RESOURCE CREATE CLUSTER
RESOURCE CREATE INDEXTYPE
RESOURCE CREATE OPERATOR
RESOURCE CREATE PROCEDURE
RESOURCE CREATE SEQUENCE
RESOURCE CREATE TABLE
RESOURCE CREATE TRIGGER
RESOURCE CREATE TYPE

9 rows selected.

Table privileges assigned directly to a user

OWNER TABLE_NAME PRIVILEGE

---

SYS DBMS_STATS EXECUTE

System privileges assigned directly to a user

PRIVILEGE ADM

---

ALTER SESSION NO
CREATE DATABASE LINK NO
CREATE SEQUENCE NO
CREATE SESSION NO
CREATE SYNONYM NO
CREATE VIEW NO
UNLIMITED TABLESPACE NO

7 rows selected.

SQL>

==> check do usuário SCOTT :

SQL> select profile, account_status, lock_date, expiry_date, external_name, default_tablespace, temporary_tablespace from dba_users where username=’SCOTT’;

PROFILE ACCOUNT_STATUS LOCK_DATE EXPIRY_DA EXTERNAL_NAME DEFAULT_TABLESPACE TEMPORARY_TABLESPACE

---

DEFAULT OPEN 27-DEC-16 USERS TEMP

SQL>

SQL> @D:dba_scriptsprivs_by_user
Enter Username : SCOTT
Roles granted to user

GRANTED_ROLE ADM DEF

---

CONNECT NO YES
RESOURCE NO YES
RL_SIST NO YES

Table Privileges granted to a user through roles

no rows selected

System Privileges assigned to a user through roles

GRANTED_ROLE PRIVILEGE

---

CONNECT CREATE SESSION
RESOURCE CREATE CLUSTER
RESOURCE CREATE INDEXTYPE
RESOURCE CREATE OPERATOR
RESOURCE CREATE PROCEDURE
RESOURCE CREATE SEQUENCE
RESOURCE CREATE TABLE
RESOURCE CREATE TRIGGER
RESOURCE CREATE TYPE
RL_SIST CREATE ANY TABLE

10 rows selected.

Table privileges assigned directly to a user

no rows selected

System privileges assigned directly to a user

PRIVILEGE ADM

---

CREATE SESSION NO
UNLIMITED TABLESPACE NO

====> Com as consultas acima fica fácil de ver as diferenças em termos de permissão, como a ROLE DEFAULT chamada RL_SIST que o SCOTT tem e o HR não, o privilégio de ALTER SYSTEM que só um dos dois tem, etc….. AGORA, se vc *** EXECUTOU DIREITINHO *** as consultas e não achou NENHUMA DIFERENçA, posso te ASSEGURAR que não é NADA A VER com o banco de dados, os privilégios DO USUÀRIO no banco de dados estão OK – nesse caso vc vai ter que :

a) verificar se os objetos a nível de banco, como TRIGGERs e DBLINKs, estão corretamente criados nos dois bancos

E

b) DEBUGAR A APLICAÇÂO, para ver se há, digamos, alguma tabela de usuários que precise ser preenchida, ou coisa assim….

[]s

Chiappa

[jgomezParticipante]

Chiappa,

Rodei os script sim, comparei tudo e estão idênticos.

Limpei o texto que não era mais necessário B) , consegui descobrir o problema, e vocês não vão acreditar, mas fiz vários testes e o resultado foi o mesmo.

Resultado: o meu Banco não está aceitando senha com letras, só aceita se for apenas números, eu imagino que isso deve ser a coisa mais banal pra vocês, mas eu realmente penei para descobrir :sick: :sick: , agora alguém saberia me informar como mudar essa “macumba” ?.

Pois muitos usuários usam senhas com letras e números, mas não são complexas.

Abraços,

[José Laurindo ChiappaModerador]

Legal, mais que comprovado que ** não tinha a ver com Privilégios **, Muito bem…
Bom, vc não dá a versão exata mas vou assumir que teu Standard é 11g alguma coisa : a configuração built-in de verificação de complexidade para senhas no RDBMS Oracle é uma FUNCTION criada no banco e indicada a ser usada no PROFILE do usuário, podendo ser Inclusive no profile DEFAULT que atende todo mundo… https://docs.oracle.com/cd/B28359_01/network.111/b28531/authentication.htm#i1007341 é o Manual onde isso é explicado, e para alterar vc re-escreve a função, podendo até mesmo usar como Modelo a function pre-definida que está no arquivo UTLPWDMG.SQL , OU se vc quiser remover completamente qualquer verificação de complexidade de senha vc usa o comando :

ALTER PROFILE nomedoprofile LIMIT PASSWORD_VERIFY_FUNCTION NULL;

e é isso, trabalho Comum e Rotineiro pra DBAs…

[]s

Chiappa

OBS : fazendo um select * from dba_profiles, vc vai ver ** TODAS ** as restrições para os PROFILEs existentes, veja que há OUTROS ELEMENTOS relacionados com senhas (como PASSWORD LIFE TIME, por exemplo) que talvez vc queira/precise alterar ou remover, se o seu ambiente não pode seguir best practices de Segurança…

[jgomezParticipante]

Chiappa,

Falha minha é 11g Standard mesmo.

Graças as suas dicas, consegui resolver os problemas.

A questão da senha expirada e com o campo “password expire” cinza resolvi com o comando abaixo e agora está ok igual no XE.

ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;

E o problema do sistema só entender números na senha, resolvi com o comando abaixo.

ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON=FALSE;

O estranho que no BD a senha funcionava tanto com apenas números como com letras, mas a aplicação não aceitava, só rodava se colocasse apenas números, após ler muito, achei algo falando do case sensitive no 11g e após rodar o comando para desativar funcionou 100%.

Agradeço pela sua paciência em ajudar um novato, com certeza sem suas valiosas dicas eu não teria conseguido.

Abraços,
José Gomes.

[José Laurindo ChiappaModerador]

Blz… Na verdade o SEC_CASE_SENSITIVE_LOGON se refere a diferenciar letras maiúsculas de minúsculas na senha, provavelmente o que acontece aí é que em algum momento a aplicação enviava pro banco senha sem respeitar maiúsculas/minúsculas e por isso o banco não aceitava,o que (óbvio) não acontece quando vc só tem números na senha, aí não tem letras a converter/respeitar maisuc/minusc e funcionava ok…
OK, importante é que vc descobriu as causas e no processo aprendeu um pouco mais sobre o RDBMS Oracle…

[]s

Chiappa

[Autor]

Posts