Permissões Reporting Services AX2012 R2

Neste video eu tento explicar como configurar as permissões de acesso aos relatorios do Dynamics AX2012 R2.

Até a próxima!!!

AX2009 - Grupos de Usuários - Permissões

Este post está um tanto quanto atrasado tendo em vista que já estamos trabalhando em ambientes de produção com o AX2012 R2 CU1!

Hoje tive a oportunidade de novamente utilizar um recurso extremamente útil na configuração dos Grupos De Usuários do AX2009, nesta oportunidade notei que não publiquei este post, apesar de tê-lo criado a muito tempo. Este post se publicado anteriormente talvez pudesse ter sido útil a muitos incumbidos da árdua responsabilidade de configurar os grupos de usuários para o AX2009.

Mesmo estando atrasado tenho certeza de que muitos AX2009 estão entrando em produção e que muitos já em produção ainda encontram problemas na configuração destes grupos.

Por esta razão segue abaixo uma dica de grande utilidade para este trabalho.

A criação e configuração inicial destes grupos de usuários pode ser vista neste post, Apesar de ser para a versão 4.0 o conceito continua o mesmo pelo menos na versão 2009!

Durante a configuração e testes dos grupos de segurança é comum encontrar erros de acesso a determinadas tabelas, e em sua grande maioria, estas tabelas se esforçam muito em se esconder completamente da nossa visualização!

Existem ferramentas como o Security Profiler Tool mostrado neste post do Brandon George.

Existe também o método força bruta, ou seja, procure até encontrar!

Um método que acho extremamente interessante, útil e, na minha opinião, muito mais fácil é a consulta via AOT. Este método dispensa ferramentas adicionais e basta ter permissão de acesso a AOT.

Na imagem abaixo temos um erro comum na configuração de permissões no AX2009. Criei em minha VM o grupo de segurança Teste1 e vinculei a este grupo o usuário de nome Teste1 (usuário e grupo como mesmo nome sim!). concedi a este grupo permissão de "controle total" e "em cascata" no modulo de contas a receber. Ao acessar o AX e tentar consultar o formulário de "Detalhes do Cliente" do modulo de "Contas a Receber" ainda assim eu recebi a mensagem de erro abaixo.

A mensagem diz que o usuário "Teste1" não possui permissão para acessar a tabela "Clientes". É comum que estas mensagens exibam também o nome (Label) da tabela, e é exatamente este o nome com o qual vamos trabalhar. No caso da mensagem acima o nome da tabela é "RBOCustTable".

Lembrem-se de que este método é valido para qualquer tabela, mas que é necessário obter o nome exato da tabela para que possamos localiza-la na AOT.

Agora abra a AOT do AX e expanda a opção "Data Dictionary" > Tables e localize a tabela "RBOCustTable". Clique com o botão direito sobre ela e selecione propriedades.

Vejam que na imagem acima selecionei o nome da tabela, RBOCustTable, Selecionei também a Label Cliente (Varejo) que é exibida na mensagem de erro e também selecionei a "SecurityKey" desta tabela.
Até o momento temos as seguintes informações, a tabela é a Clientes (varejo) e sua "SecutiryKey" é a "RBOTables". Precisamos agora encontrar esta "SecurityKey" e verificar suas propriedades.

Ainda na AOT expanda agora as opções "Data Dictionary" > "Security Keys" e abra as propriedades da SecurityKey "RBOTables".

Agora temos a SecurityKey, na imagem acima podemos ver a "Label" que é "Tabelas". Isto significa que a tabela "Clientes (Varejo)" esta dentro das tabelas de algum modulo, mas qual é este modulo tendo em vista que todos os módulos do AX possuem a opção tabelas? A resposta está na opção "ParentKey". Vejam que a ParentKey é a "RBO". Ainda nas SecutiryKeys localize esta ParentKey e veja qual a Label dela.

A Label da ParentKey "RBO" é a "BackOffice". E oque isso significa? este é o modulo do AX no qual temos que conceder a devida permissão!

Vamos rever os passos executados aqui:

Vimos que o erro estava na falta de acesso a tabela "Clientes (Varejo)" ou "RBOCustTable"
Localizamos e visualizamos as propriedades da tabela "RBOCustTable"
Localizamos a SecurityKey da tabela "RBOCustTable". "SecurityKey = RBOTables"
Localizamos a SecurityKey "RBOTables" e localizamos a "Label" e "ParentKey" dela.
Localizamos a "ParentKey" e vimos o nome da "Label" dela.

Desta forma chegamos a seguinte conclusão:

Tabela com falta de permissão:
RBOCustTable. Sua Label é "Clientes (Varejo)

A SecurityKey da tabela com problema é a:
RBOTables. Sua Label é a "Tabelas"

A "ParentKey" da "SecurityKey" é a:
"RBO". Sua Label é "BackOffice".

E desta forma encontramos exatamente onde está o problema de permissão.

BackOffice > Tabelas > Clientes (Varejo).

Basta agora conceder a devida permissão no caminho acima e pronto.

E assim concedemos permissão ao usuário na tabela correta!

Espero ter sido claro o suficiente em meu post.

Caso tenham duvidas referente a este processo por favor entrem em contato comigo!

AX2012 R2. Importação de usuário. Dica!

Esta dica é valida para todas as versões do AX!

Para importar um usuário no AX é necessário que o usuário tenha permissão de leitura no AD, caso contrario este não conseguirá visualizar todos os usuários criados no AD. Mas como conceder a permissão correta no AD?

O procedimento abaixo deverá ser executado no AD. Ao acessa-lo altere o modo de visualização do AD para avançado.

Agora acesse as propriedades do usuário, clique na aba Security, selecione o grupo Authenticated Users e permita a leitura.

Clique em Ok e feche as janelas!

Agora este usuário conseguirá visualizar todos os usuários do AD!

Permissões no Dynamics AX2012. Parte 2!

Neste post vou tentar detalhes o funcionamento da segurança no AX2012, explicando o passo a passo para a autenticação no AX2012 e como funciona cada permissão. também vamos entender em detalhes o significado de cada termo utilizado nestes posts, estes termos serão amplamente utilizados aqui neste blog ou em qualquer outro que fale sobre permissões no AX2012!

No AX2012 novos termos foram adicionados, estes termos podem ser vistos na imagem abaixo, esta imagem é o diagrama de arquitetura de segurança do AX2012.

Vamos entender cada passo desta arquitetura.

Autenticação.
Por padrão somente os usuários de domínio autenticados no AD DS podem acessar o AX2012. Este usuário deve ser membro de no minimo uma role, caso contrario este usuário não terá nenhuma permissão no AX2012.

O AX2012 poderá utilizar outros métodos de autenticação diferentes do padrão

Autorização.
Autorização é o controle de acesso à aplicação do AX2012. As permissões de segurança são utilizadas para controlar o acesso aos elementos da aplicação tais como menus, itens do menu, botões de ação e comandos, relatórios e campos no AX Client e no Enterprise Portal.
No AX2012 as permissões de segurança individuais são combinadas dentro de "privilégios" e estes "privilégios" são combinados dentro das "duties". Para que uma role possua determinadas permissões é necessários que privilégios e duties sejam concedidos e estas roles.

Segurança de Dados.
A autorização é utilizada para conceder permissões enquanto a segurança de dados é utilizada para negar permissões em tabelas, campos e linhas do banco de dados.

A utilização deste recurso permite que você limite o acesso a dados transacionais. As politicas de segurança de dados podem limitar o acesso a dados baseados em datas, baseados em dados de usuários.
A segurança de nível de registro pode ser utilizada para limitar o acesso a dados baseados em query. Nas próximas versões do AX a segurança em nível de registro se tornará obsoleta, por este motivo é aconselhado que seja utilizado as politicas de segurança de dados.

Dica de prova:
Extensible Data Security Framework pode ser utilizado para restringir acesso a dados baseados em data, baseados em dados do usuário e em dados baseados em query!

Agora vamos nos aprofundar no conceito de autorização do AX2012, entendendo o que significa cada um de seus termos.

Na segurança baseada em regras (Role-Based Security), o acesso é garantido as "Security Roles" e não aos usuários individualmente. O usuário membro de uma security role terá acesso ao conjunto de privilégios associados a aquela Security role.

Nesta versão do AX, as Security Roles são alinhadas com a estrutura de negócios. Os usuários são adicionados as security roles baseados em suas responsabilidades na organização, domínio, e em sua participação em cada processo do negócio.

Este modelo de segurança é hierárquico, em cada elemento desta hierarquia temos um diferente nível de detalhes.

Permissões representam o acesso a objetos protegidos individualmente, como menus, tabelas e itens.

Privilégios são compostos por permissões e representam o acesso a determinadas tarefas como cancelar uma ordem de pagamento.

Duties são compostos por privilégios e representam parte de um processo de negocio como manter transações bancárias.

Duties e privilégios podem ser utilizados para conceder as devidas permissões de acesso ao Dynamics AX.

Security Roles
Para que seja possível acessar o Dynamics AX2012 é necessário que o usuário seja membro de pelo menos  uma security role. Esta secutiry role a qual o usuário faz parte determinará quais atividades o usuário poderá executar no AX. Os administradores podem aplicar politicas de segurança de dados para limitar o acesso que os usuários podem ter em determinados dados. Por exemplo, um usuário pertencente a uma role deve ter acesso a dados de apenas uma organização. O administrador pode ainda especificar o nível de acesso que o usuário de uma role terá em dados antigos, atuais e novos dados do sistema. Por exemplo, um usuário pode ter privilégios para visualizar dados de todos os períodos, mas pode alterar apenas os dados do período atual.

No AX2012 é possível especificar as permissões para grupos do AD. Imagine que você tenha um grupo do AD adicionado a uma role no AX, este grupo tem permissão para controlar as funções de RH do AX. Caso um novo funcionário entre para este departamento, basta adiciona-lo a este grupo no AD e este usuário já terá acesso ao AX com as permissões necessários para executar suas atividades. O mesmo é valido para quando este usuário for desativado no AD, desta forma este já não terá mais acesso ao AX.

As security roles podem ser organizadas hierarquicamente, desta forma podemos definir que uma security role é baseada em outra security role. Por exemplo, a security role pode ser "Gerente de Vendas" pode ser definida como parente da security role "Gerente", desta forma os membros da role "Gerente de Vendas" poderão executar todas as atividades da security role "Gerente".

O Microsoft Dynamics AX2012 já possui secutiry roles pré-definidas, estas podem ser editadas para que se adaptem as necessidades de cada caso, novas security roles também podem ser criadas caso necessário.

Dica de Prova:
O Dynamics AX já possui Security Roles padrões pré-definidas!

Process Cicles.
Proccess Cicles é um conjunto de atividades coordenadas nas quais um ou mais participantes consome, produzem e utilizam recursos econômicos para alcançar o objetivo da organização.

Para ajudar os administradores a localizarem as "duties" que devem ser associadas a roles, as duties foram organizadas por processos das quais elas fazem parte. Por exemplo, no processo (process cicle) de contabilidade você pode encontrar a duties Manter Diários e Manter Transações Bancarias.

Duties.
Duties correspondem a partes de um processo. O administrador deve conceder duties para as secutiry roles, uma duty pode ser concedida a mais de uma security role.

No modelo de segurança para o Microsoft Dynamics AX, duties contem privilégios. Por exemplo, a duty Manter transações bancarias contém os privilégios de  Gerar recibos de depósito e Cancelar privilégios de pagamentos. Embora tanto as duties os quantos privilégios podem ser atribuídos às funções de segurança, recomendamos que você use as duties para conceder acesso ao Microsoft Dynamics AX.

Privilegies.

No modelo de segurança para o Microsoft Dynamics AX, um privilégio especifica o nível de acesso que é necessário para realizar um trabalho, resolver um problema, ou completar uma tarefa. Privilégios podem ser atribuídos diretamente a security roles. No entanto, para facilitar a manutenção, recomendamos que você atribua apenas duties a security roles.

Um privilégio contém permissões para objetos individuais de aplicativos, como elementos de interface de usuário e tabelas. Por exemplo, o privilégio Cancelar pagamentos contém permissões para os itens do menu, campos e tabelas que são necessárias para cancelar pagamentos.

Por padrão, os privilégios são fornecidos para todos os recursos do Microsoft Dynamics AX. O administrador pode modificar as permissões que estão associados com um privilégio, ou criar novos privilégios.

Permissions.

Cada função no Microsoft Dynamics AX, como um formulário ou um serviço, é acessado através de um ponto de entrada. Os itens do menu, itens de conteúdo web, e operações de serviços são referidos coletivamente como pontos de entrada.

No modelo de segurança para o Microsoft Dynamics AX, permissões agrupam os objetos que podem ser protegidos e os níveis de acesso que são necessários para executar uma função. Isso inclui todas as tabelas, campos, formulários ou métodos que são acessados ​​através do ponto de entrada.

Apenas os desenvolvedores podem criar ou modificar as permissões. Para mais informações sobre como trabalhar com permissões, consulte a documentação do desenvolvedor do Microsoft Dynamics AX. Esteja ciente de que modificar permissões pode afetar seus requisitos de licenciamento.

Neste post tentei explicar o que significam as Security Roles, Process Cicles, Duties, Privilegies e Permissions no AX2012.
Sugiro que ao ler este post você tente visualizar o conteúdo das funções de segurança no AX2012, isso vai ajudar!

Nos próximos posts vou iniciar uma sequência onde mostrarei como instalar o AX e todos os seus recursos disponíveis  esta sequência será longa, mas ficará bem interessante. Depois de termos o AX instalado voltaremos a trabalhar com os usuários e permissões no AX2012!

Permissões no Dynamics AX2012 R2. O inicio!

Neste post vou tentar esclarecer, e ao mesmo tempo aprender, mais detalhes sobre as permissões de segurança do Dynamics AX2012 R2. Vou tentar diariamente incluir novos detalhes sobre cada nova função no que diz respeito a permissões de segurança do AX2012 R2.

Durante cada post vou incluir dicas importantes para a certificação MB6-872, espero que estas dicas ajudem aos interessados em conquistar esta certificação!

Como este post será atualizado diariamente tentem acompanha-lo e de preferencia comentem e façam perguntas, assim poderei ajuda-los e ao mesmo tempo aprender mais!

Sendo assim, vamos ao trabalho!

Configurando usuários e segurança no Microsoft Dynamics AX2012.

Obs: Este post é valido para todas as versões do AX2012!

O primeiro ponto é esquecer o conceito de grupos de segurança das versões anteriores deste ERP, desta forma será mais facil aprender todo este novo conceito!

No AX2012 a autenticação é feita de forma integrada com o serviço de AD DS, a diferença é que nesta versão é possível escolher outros métodos de autenticação, estes serão discutidos mais a frente!

Dica de prova: No AX2012 é possível conceder permissões diretamente para grupos importados do AD!

O primeiro ponto é entender o significado de alguns nomes que serão muito utilizados nas permissões, tendem entender ao maximo o significado dos termos abaixo, este entendimento os ajudará e muito na prova!

Com a introdução do AX2012 novos termos foram introduzidos, os termos como grupos de segurança já não serão mais tão utilizados. Termos como Security Roles, Duty, Previleges e outros passarão a ser utilizados e precisam ser bem entendidos por nós!

Veja o Diagrama da Arquitetura de Segurança do AX2012, este o ajudará a entender melhor este processo.

Nas versões anteriores do Dynamics AX os administradores precisavam criar manualmente os grupos de segurança e definir as permissões de acordo com a função do grupo criado. Sabemos que ao definir as permissões a um grupo é uma tarefa complicada, em determinados momentos se tornava extremamente difícil  e consumia um grande tempo, localizar determinada tabela ou menu para conceder permissão.

No AX2012 a segurança é baseada em "Regras", para facilitar o entendimento passaremos a nos referenciar  a estas "regras" como "Roles". Estas roles são grupos pré definidos já existentes no Dynamics AX2012. Agora não é necessário saber o nome da tabela ou menu para liberar a permissão, agora basta saber quais são os deveres, tarefas, a serem realizadas por determinado usuário e com isso conceder as determinadas permissões. Sendo assim será necessário um maior conhecimento nas demais funções do AX2012.

Os "deveres" mencionados anteriormente serão a partir de agora chamadas de "duty", nada além de sua tradução para o inglês!

Nas versões anteriores era necessário criar diversos grupos para que fosse possível gerenciar as mesmas permissões para pessoas diferentes em empresas, domínios, diferentes. Isso fazia com que fosse necessário criar inúmeros grupos, as vezes com exatamente as mesmas permissões para que pudéssemos gerenciar as permissões em diferentes domínios. No AX2012 poderemos utilizar uma mesma role em empresas, domínios, diferentes!

Como nas versões anteriores era necessário criar um grupo de segurança e conceder permissões manualmente, para que um grupo tivesse permissão para criar uma ordem de venda era necessário conceder diversas permissões em menus, tabelas e objetos diferentes, e sabemos que não era fácil achar todas!
Agora no AX2012 para que um usuário possa criar, editar ou excluir uma ordem de venda basta que este seja membro da duty "Manter Ordens de venda", esta duty já concede permissão a tudo oque é necessário para o usuário executar suas "duties" normalmente. Fácil né!

Logicamente você poderá criar novas roles ou editar as roles existentes!

Para o Enterprise Portal já não é mais necessário que o usuário possua uma conta no AD DS da empresa, usuários externos poderão acessar o EP sem a necessidade de uma conta de domínio.

Bom pessoal, por hoje é só!

No próximo post vamos nos aprofundar no diagrama de arquitetura de segurança e entender o significado de cada termo e como funciona a segurança no AX2012.