Estações de trabalho on-line OnWorks Linux e Windows

Logotipo

Hospedagem online grátis para estações de trabalho

<Anterior | Conteúdo | Próxima>

1.7. Controle de acesso


O gerenciamento de que tipo de acesso (leitura, gravação, etc) os usuários devem ser concedidos aos recursos é conhecido como

controle de acesso. As diretivas de configuração envolvidas são chamadas de listas de controle de acesso ou ACL.


Quando instalamos o pacote slapd, várias ACLs foram configuradas automaticamente. Veremos algumas consequências importantes desses padrões e, ao fazer isso, teremos uma ideia de como as ACLs funcionam e como são configuradas.


Para obter a ACL efetiva para uma consulta LDAP, precisamos examinar as entradas ACL do banco de dados que está sendo consultado, bem como as da instância de banco de dados front-end especial. As ACLs pertencentes a este último agem como padrão no caso de o primeiro não corresponder. O banco de dados de front-end é o segundo a ser consultado e a ACL a ser aplicada é a primeira a corresponder ("a primeira correspondência vence") entre essas 2 fontes de ACL. Os comandos a seguir fornecerão, respectivamente, as ACLs do banco de dados mdb ("dc = example, dc = com") e do banco de dados front-end:


sudo ldapsearch -Q -LLL -Y EXTERNO -H ldapi: /// -b \ cn = config '(olcDatabase = {1} mdb)' olcAccess


dn: olcDatabase = {1} mdb, cn = config

olcAccess: {0} to attrs = userPassword por autoescrita por autenticação anônima por * nenhum olcAccess: {1} to attrs = shadowLastChange por self write por * read

olcAccess: {2} para * por * leitura


imagem

O rootDN sempre tem direitos totais ao seu banco de dados e não precisa ser incluído em nenhuma ACL.



sudo ldapsearch -Q -LLL -Y EXTERNO -H ldapi: /// -b \ cn = config '(olcDatabase = {- 1} frontend)' olcAccess


dn: olcDatabase = {- 1} frontend, cn = config

olcAccess: {0} to * by dn.exact = gidNumber = 0 + uidNumber = 0, cn = peercred, cn = external

, cn = autenticação gerenciada por * pausa

olcAccess: {1} para dn.exact = "" por * leitura

olcAccess: {2} para dn.base = "cn = Subschema" por * ler


As duas primeiras ACLs são cruciais:


olcAccess: {0} to attrs = userPassword por autoescrita por autenticação anônima por * nenhum olcAccess: {1} to attrs = shadowLastChange por self write por * read


Isso pode ser representado de forma diferente para facilitar a digestão:


para attrs = userPassword



por auto escrever

por autenticação anônima por * nenhum


para attrs = shadowLastChange por autoescrita

por * ler


Essas ACLs aplicam o seguinte:

• Acesso anônimo de 'autenticação' é fornecido ao senha do usuário atributo para que os usuários possam se autenticar, ou vincular. Talvez contra a intuição, 'por autenticação anônima' é necessário mesmo quando o acesso anônimo ao DIT é indesejado, caso contrário, isso seria um problema da galinha e do ovo: antes da autenticação, todos os usuários são anônimos.

• A por auto escrever ACL concede acesso de gravação ao senha do usuário atributo para usuários que se autenticaram como o dn onde o atributo mora. Em outras palavras, os usuários podem atualizar o senha do usuário atributo de suas próprias entradas.

• A senha do usuário de outra forma, o atributo está inacessível para todos os outros usuários, com exceção do rootDN, que sempre tem acesso e não precisa ser mencionado explicitamente.

• Para que os usuários alterem sua própria senha, usando passwd ou outros utilitários, o próprio usuário sombraLastChange atributo precisa ser gravável. Todos os outros usuários do diretório podem ler o conteúdo deste atributo.


Este DIT pode ser pesquisado anonimamente por causa de 'to * by * read' nesta ACL, que concede acesso de leitura a todo o resto, por qualquer pessoa (incluindo anônimo):


para *

por * ler


Se isso for indesejado, você precisará alterar as ACLs. Para forçar a autenticação durante uma solicitação de ligação, você pode, alternativamente (ou em combinação com a ACL modificada), usar a diretiva 'olcRequire: authc'.


Como mencionado anteriormente, não há nenhuma conta administrativa ("rootDN") criada para o banco de dados slapd-config. Há, no entanto, uma identidade SASL que tem acesso total a ela. Ele representa o superusuário do host local (root / sudo). Aqui está:


dn.exact = gidNumber = 0 + uidNumber = 0, cn = peercred, cn = externo, cn = auth


O seguinte comando exibirá as ACLs do banco de dados slapd-config:


sudo ldapsearch -Q -LLL -Y EXTERNO -H ldapi: /// -b \ cn = config '(olcDatabase = {0} config)' olcAccess


dn: olcDatabase = {0} config, cn = config

olcAccess: {0} to * by dn.exact = gidNumber = 0 + uidNumber = 0, cn = peercred, cn = externo, cn = auth gerenciar por * break


Uma vez que esta é uma identidade SASL, precisamos usar um SASL mecanismo ao invocar o utilitário LDAP em questão e já vimos isso várias vezes neste guia. É o mecanismo EXTERNO. Veja o comando anterior para um exemplo. Observe que:


1. Você deve usar sudo para se tornar a identidade raiz para que a ACL corresponda.

2. O mecanismo EXTERNO funciona via IPC (Soquetes de domínio UNIX). Isso significa que você deve usar o ldapi

Formato URI.


Uma maneira sucinta de obter todas as ACLs é esta:


sudo ldapsearch -Q -LLL -Y EXTERNO -H ldapi: /// -b \ cn = config '(olcAccess = *)' olcAccess olcSuffix

Há muito a dizer sobre o tema do controle de acesso. Veja a página de manual de slapd.access4.


Top OS Cloud Computing na OnWorks: