Bom dia a todos,
Após o post da semana passada sobre a adição de um livro centralizado de contactos ao ldap server que serve de base para o nosso IDM/IPA chegou a altura de configurar acessos ao mesmo.
Alem da disponibilidade da informação, é necessário garantir que apenas os elementos certos acedem a mesma.
Iremos assim aplicar uma política de acessos utilizando as contas já criadas em IDM/IPA para definir quem acede a informação e com que permissões.
Como tal, definimos os seguintes níveis de acesso:
a) Users de administração – vamos imaginar um user ldap de nome rollodex.
b) Permissões para um grupo geral de leitura.
c) Permissões para um grupo geral de administração.
O primeiro exemplo será o administrador, caso se opte por não se usar a opção c).
Será um utilizador apenas que irá fazer a gestão do rollodex.
Assim será necessário construir o ldif que irá atribuir as permissões, após a criação do utilizador rollodex em IDM:
# cat admin.ldif
dn: dc=domain,dc=com
changetype: modify
add: aci
aci: (targetattr = “*”) (target = “ldap:///ou=fornecedores,ou=addressbook,dc=domain,dc=com”) (version 3.0;acl “user_admin”;allow (all,proxy)(userdn = “ldap:///uid=rollodex,cn=users,cn=accounts,dc=domain,dc=com”);)
Em seguida, executaremos o ldapmodify de forma a carregar as permissões:
# ldapmodify -D “cn=directory manager” -p 389 -h idm.domain.com -f admin.ldif -W
Agora que temos um user de administração, iremos necessitar que o grupo comercial tenha acesso aos dados do repositório de contactos.
Para tal, e após criar o grupo “comercial” dentro do IDM, é altura de construir a ACI com o acesso:
# cat groupread.ldif
dn: dc=domain,dc=com
changetype: modify
add: aci
aci: (targetattr = “*”) (target = “ldap:///ou=fornecedores,ou=addressbook,dc=domain,dc=com”) (version 3.0;acl “grupo_de_leitura”;allow (read,proxy)(groupdn = “ldap:///cn=comercial,cn=groups,cn=accounts,dc=domain,dc=com”);)
Em seguida teremos de carregar o ldif dentro do nosso IDM:
# ldapmodify -D “cn=directory manager” -p 389 -h idm.domain.com -f groupread.ldif -W
Finalmente chegamos a possibilidade c) por exemplo para uma equipa que mantenha a informação dos contactos atualizada e correta.
Ou seja, as permissões dadas no exemplo a) utilizando a sintaxe do exemplo b) aplicada a um novo grupo de ACIs:
# cat groupadmin.ldif
dn: dc=domain,dc=com
changetype: modify
add: aci
aci: (targetattr = “*”) (target = “ldap:///ou=fornecedores,ou=addressbook,dc=domain,dc=com”) (version 3.0;acl “grupo_de_leitura”;allow (all,proxy)(groupdn = “ldap:///cn=gestaoinformacao,cn=groups,cn=accounts,dc=domain,dc=com”);)
O processo de carregamento é idêntico aos anteriores.
Considerações finais:
Todos os exemplos anteriores onde são utilizados ldapgroups, pressupõe que os grupos sejam criados (por exemplo em interface IDM), e os grupos sejam populados com utilizadores válidos existentes em IDM/IPA.
Outra consideração importante a ter é como em todos os casos em que se utilizam e alteram sistemas dinâmicos e complexos, existe sempre a necessidade de backups válidos e testados.
É necessária a noção, que o IDM/IPA tem um comportamento de AD e como tal snapshot’s das máquinas envolvidas não são backups válidos por várias razões, sendo a principal que a reposição de um snapshot pode contaminar e deixar inutilizável uma floresta IPA/IDM inteira.
Para backups e restore o IDM/IPA fornece ferramentas apropriadas para o efeito. Por favor utilizem elas.
Chegamos entretanto ao fim deste pequeno livro de receitas que mostra a versatilidade do IDM/IPA e da stack que o compõe, que alem de um ponto centralizado de gestão de identidade, pode ainda ser utilizado para melhorar a comunicação dentro de uma empresa fomentado a partilha de informação (neste caso contactos de fornecedores), de uma forma totalmente segura.
Caso tenham duvidas, estou como sempre disponível para quaisquer duvidas que possam ter.
Abr.
Nuno
