Design de Uma Dit

Robson
Oliveira
Pgina inicial
@ Meus projetos C# Sharp
ArthurKenPo
InfoOS
Loto Sorte!
MegaQuina v1.0
O Labirinto do rslayer
Onde est Wally?
Pedra, Papel e Tesoura
rBeba gua
rBusca CEP
rIP
rMultiSkype
Tabelinha Virtual 2.0
@ Meus projetos em Visual
Basic
3 vXs 3
Dicas_XP 1.0.1
IMC
Kama Sutra v6.9
Key Ascii-Code
Meu IP
Psycho rslaer
Psycho rslaer 2
Purrinha Slayer
Resistor-X
rslaer Hacker Game
ShutWINdowS
Tabelinha Virtual
The Cracking
Total-DOS
Tudo sobre MS_DOS
VB Error!
A histria secreta dos
computadores
ABNT
ABNT 1
Artigos Computacional >
Design de uma DIT
Resumo
possvel fazer um diretrio LDAP servir para muitas aplicaes numa
organizao. Esta tem sido uma vantagem de reduzir esforos necessrios
para manter os dados, mas significa que o layout deve ser planejado muito
cuidadosamente antes de iniciar sua implementao.
Diretrios LDAP so estruturados como uma rvore de entradas, onde
cada entrada consiste de um conjunto de pares (atributos/valores)
descrevendo um objeto. Estes objetos so frequentemente pessoas,
organizaes, e departamentos, mas podem ser qualquer coisa. Schema
um termo usado para descrever uma forma de um diretrio e as regras que
descrevem os contedos.
Uma organizao hipottica descrita, com necessidades parecidas como
uma "lista de telefones" e tambm ser utilizada para autenticao,
autorizao, e necessidades de aplicaes especficas. As
implementaes dos padres LDAP so discutidos, mostrando os
problemas de manter a compatibilidade com um ampla quantidade de
clientes LDAP que existem.
Um plano proposto para o layout da rvore de diretrios (DIT), com
nfase principamente em evitar a necessidade de uma reorganizao
posterior. Isto envolve separar cuidadosamente os dados que descrevem
pessoas, departamentos, grupos e objetos especficos de aplicaes. Uma
simples tcnica para definir as entradas mostrada, baseando-se no uso
de classes de objetos locais. Os efeitos dos tipos de schemas so
mostrados e a performance discutida. Alguns "problemas" e "pontos de
falha" so apresentados, baseados em recentes experncias de
consultoria.
6 - LDAP
Pesquisar o site
Design de uma DIT - Robson Oliveira https://sites.google.com/site/rslayer/dicas-truques...
1 of 25 21-08-2014 21:58
ABNT 2
ABNT 3
ABNT 4
ABNT 5
ABNT 6
Numerao
Sumrio
Active Directory
Como Instalar
Diretivas de Grupo
2008 - GPO
Disponibilidade
DNS Avanado
Endereamento IP
Extenses
FTP Banner
GPMC
Implementando DFS
Instalao Remota
Instalao Server 2003
R2
Monitoramento
Objetos
OS Fingerprint
Replicao DFS
Requisitos
Servidor DHCP
SMTP Banner
Split DNS
Vdeos
Apple x Microsoft
Artigos Computacional
Access Point
Atalhos rpido
Ataques de Negao de
Servios
Backup
Design de uma DIT
Firewall
Instalao Ldap Samba
O Proxy
Protocolo DHCP
Scanners
LDAP pode ser utilizado para acessar informaes que descrevem
pessoas, organizaes, regras, servios, e muitos outros tipos de
entidades. um prototolo padro amplamente implementado, que torna
extremamente valoroza a integrao de mltiplas aplicaes que
necessitam compartilhar dados comuns.
importante entender o modelo de dados do LDAP quando considerar
'schemas'. diferente do formato do modelo relacional utilizado pela
maioria dos j consagrados sistemas de banco de dados, e isto altera a
maneira de projetar sistemas que utilizam o LDAP.
Tecnicamente falando, LDAP um protoloco - o "Lightweight Directory
Access Protocol". No um banco de dados e nem mesmo um diretrio
LDAP como frequentemente utilizado para descrever um servio de
diretrio que acessado atravs do protocolo LDAP. LDAP deriva dos
padres X.500/ISO-9594, e foi originalmente concebido como um protocolo
para computadores de pequeno porte conseguirem utilizar quando fosse
necessrio acessar sistemas X.500. Recentemente, LDAP expandiu-se e
hoje to complexo quando o X.500 mas ainda compartilha o mesmo
modelo de dados e parte do mesmo modelo de servios distribudos.
[RFC3377]
6.1 - A estrutura do LDAP
Um Diretrio LDAP armazena informao numa estrutura de rvore
conhecida como Diretctory Information Tree (DIT). Os ns da rvore so
entradas de diretrios, e cada entrada contm informao na forma
atributo-valor. Alguns atributos podem ter mltiplos valores; outros so
restritos um simples valor. O conjunto de atributos que podem ser estar
presentes numa entrada determinado pelo atributo objectClass, que
estar sempre presente. O atributo objectClass multi-valorado e para
cada valor define um conjunto de atributos obrigatrios e/ou opcionais.
Cada n da DIT tem um nome chamado Relative Distinguished Name
(RDN) que nico entre os ns do seu pai. Mas tambm tem um nico
nome globalmente chamado Distinguished Name (DN) que formado pelo
seu prprio n mais os nomes de todos os ns superiores at a raiz da
DIT.
6.2 - O modelo do Servio Distribudo do LDAP
X.500 foi concebido como um servio de diretrio global. Como tal,
esperava-se que ele gerenciasse centenas de milhares de entradas e
fosse gerenciado por centenas de organizaes diferentes. Isso apontava
para um modelo de servio baseado em muitos servidores interligados
conhecidos como DSAs (Directory System Agents). Cada DSA poderia
2 of 25 21-08-2014 21:58
Servidor Web
Sistema - NFS
Switch 3Com
Viso Geral de Redes
TCP/IP
BookCast & WebCast
GDHBookcast
GDHCast
Carlos Eduardo Morimoto
CCNA
Certificao
Exame 70-291
Exame 70-640
Conceitos de Redes
Arquiteturas de Rede
Bsico de Protocolo IP
Crimpar um Cabo de
Rede
Infra-estrutura de Rede
Introduo bsica
Padres
Para Saber Mais
Projeto de Rede
Protocolos
Protocolos e Clientes
de Rede
Qual Porta est
Conectado?
Terminologia
Crie Regras de Iptables
Digerati Segurana
Revista H4CK3R-CD1
Revista H4CK3R-CD2
Revista H4CK3R-CD3
Direito Digital
Direito Digital 1.0
Direito Digital 2.0
Direito Digital 3.0
Direito Digital 4.0
Direito Digital 5.0
Pirataria
Diversos
Como funciona
armazenar dados de um ou mais ramos de uma DIT, e era fornecido como
"conhecimento" para que podesse direcionar consultas para dados no
locais aos servidores apropriados. Expera-se que consultas sejam muito
mais frequentes do que atualizaes, e a consistncia absoluta de dados
entre as DITs no suportada, ento dados podem ser replicados
facilmente para performance e resistncia.
Um servidor LDAP efetivamente um DSA e segue as mesmas regras,
embora LDAP no tenha seja um modelo muito bom para servios
distribudos para grandes redes. A maioria dos desenvolvimentos em
LDAP se limitam a uma nica organizao, embora a replicao de dados
seja normalmente utilizada, as outras caractersticas de um modelo de
servio distribudo no demandam muito trabalho.
X.500 e LDAP tem muitas semalhanas com DNs em termos de modelo de
dados e modelo de servio, mas os sistemas de diretrios so capazes de
operaces mais complexas.
7 - Requisitos
Quando considerar um desenvolvimento de um LDAP para servir mais que
uma aplicao, importante obter a maior viso possvel da organizao e
suas futuras necessidades. Isso importante pois uma simples alterao
na forma da DIT num determinado estgio de projeto pode ser difcil de ser
implementada, uma vez que podem existir dados na DIT e aplicaes
funcionando.
7.1 Organizao Exemplo
Considere uma organizao hipottica chamada O Exemplo. Ela tem um
domnio chamado exemplo.org e deseja integrar vrios sistemas que
manipulam dados relacionados s pessoas. Os servios necessrios so:
Pginas de pesquisas para Pessoas e Regras, atravs de
diversas interfaces de usurios;
Autenticao - simples (ex: portal web) e com dados adicionais
(ex: Samba para Clientes Windows e Unix NSS/PAM)
Autorizao - grupos de diversas formas, permisses, controle de
acessos para aplicaes particulares;
Armazemamento de dados de aplicaes especficas -
configuraes, personalizao, tabelas de mapeamentos;
Integrao da configurao de sistema de email com pesquisas
de diretrios.
certamente possvel atender todas essas necessidades com um simples
diretrio baseado em LDAP, embora necessitar de alguns cuidados
relacionando como os dados devem ser gerenciados.
3 of 25 21-08-2014 21:58
WIndows
MS-DOS
O Vrus das Escutas
Storage feito em Casa
Downloads
Andrew S. Tanenbau
Diversos
Diversos
Endereo IP
Esprito Livre
Games antigos
Historia do UNIX
Humor
10 coisas que voc no
deve fazer na Lan
House
Banda Djafu - Pacote
TCP
Bill Gates vs Steve
Jobs
Helpdesk
Suporte tcnico
Usurio de Computador
Vida de Programador
Vida de Programador
Vida de Suporte
Vida de Suporte
Vida de Suporte
Vida de Suporte
Info.Abril Cursos Flash
ITIL/Cobit e Governana
Cobit
Excelncia em Projetos
Governana de TI
ITIL
PMBOK
Link's
Linux
20 anos do Linux
Canonical
Como instalar o Ubuntu
11.04 Natty Narwhal
Instalando o MRTG
8 - Princpios de Projetos em LDAP
8.1 - Evite renomear as coisas
Depois que um objeto tiver sido criado no diretrio LDAP comum que o
nome daquele objeto seja utilizado por outros objetos, ou mesmo fora do
diretrio. Isto nos sugere que objetos no devem ser renomeados, o que
torna mais restrita a escolha de como eles devem ser identificados no
cadastramento.
A maioria dos exemplos nos documentos padres X.500 utiliza nomes
"naturais" para os objetos. Ento as representaes de uma pessoa
normalmente mostrada com um RDN do nome da pessoa. Isso nos remete
a dois problemas: o que fazer se a pessoa tiver seu nome alterado, e como
fazer para diversas pessoas que possuam o mesmo nome. A tcnica
"padro" usar um atributo extra no RDN para resolver a ambiguidade.
Ento multiplos "Fred Smiths" teram seus RDNs no formato "cn=Fred
Smith + uid=67354. Isso no resolve o problema com a alterao do
nome, ento eu recomendo que todas entradas representando pessoas ou
outras entidades que podem ter seus nomes alterados tenham seus RDNs
contendo apenas o atributo uniqueIdentifier: este valor pode ser
simplesmente um nmero serial, que no tenha significado fora do
diretrio.
H um problema potencial com esta tcnica tambm: algumas interfaces
de usurios utilizam o valor do RDN como ttulo da entrada a ser mostrada.
Um nmero serial sem significado seria mostrado nesta interface.
Felizmente este comportamento muito raro atualmente, e os padres
fornecem um atributo que explicitamente fornecido para este
trabalho: displayName. Ento uma boa idia incluir o
atributo displayName em todas entradas do diretrio.
8.2 - No modifique as definies de schemas
padres
Um conjunto de atributos e classes de objetos descritos nas RFCs do
LDAP algumas vezes aparentam ser inadequadas. Isto no surpresa,
como eles so derivadas de muitos padres postais e de
telecomunicaes diferentes, e alguns novos padres esto sendo criados
juntamente com desenvolvimento dos servios de diretrios para
contemplar novas funcionalidades. Como resultado, muitas pessoas so
frequentemente tendenciadas a fazerem "alteraes" ou "correes" nos
schemas padres. Isso uma ideia ruim, pois sabemos que os atributos
padres esto embutidos nos produtos mais utilizados. Para complicar
ainda mais, muitos autores de produtos criam seus prprios schemas e
4 of 25 21-08-2014 21:58
Instalando o Nagios 3.0
Java Linux
Linus Torvalds
Ubuntu 11.04 Natty
Narwhal
Ubuntu 11.04 Natty
Narwhal no VirtualBox
com Unity
Ubuntu 11.04 Partilhe
facilmente a sua Home
Folder
Vdeos
Lista de Portas TCP/UDP
Material de Faculdade
Interligao de Redes
Linux
Mercado de Trabalho
Prof. Anderson Sidinei
Redes Convergentes
Redes sem Fio
Roteadores e
Roteamento
Vlans, Vtp etc...
Windows 2003
Notcias
Olhar Digital
Vdeos
Vdeos
Vdeos
Vdeos
Vdeos
Outros Assuntos
Beep do GNU Linux
Dez anos de Mac OS X
Do bit ao Yottabyte
Fliperama em casa
George Hotz
Joomla 1.6
Ligaes de celular..
Packet Tracer
Programao
Algoritmo
Visual Basic - 1
conjuntos de atributos conflitantes para enriquecer as "experincias de
livros de endereos".
Felizmente, os melhores clientes LDAP podem ser configurados para usar
os atributos que voc desejar ver e como ignorar as partes "quebradas"
dos conjuntos padres e criar suas prprias substituies. Alguns clientes
no permitem isso, tornando mais difcil a tarefa de encontrar o que voc
deseja e sequer permitem alguma flexibilidade nestes casos.
8.3 - Cuidado com as Classes de Objetos
Estruturais
Cada entrada tem uma classe de objeto Estrutural. Ela define as
caractersticas fundamentais, e no pode ser alterada depois que uma
entrada criada.
Se voc definir novos atributos, ou desejar combinar alguns existentes em
novas formas, voc ir necessitar criar novas classes de objetos que
permitam que isso acontea. A maioria dos exemplos padres mostram
isto sendo feito por uma subclasse exitente, mas isto criam problemas. Os
padres LDAP divergem do X.500 apenas antes do desenvolvimento do
X.500 (1993), e tem adotado partes de verses posteriores. Uma das
inovaes a "diviso" dos objectClass em trs tipos de classes e como
elas podem ser combinadas. Servidores LDAP agora so forados a
assegurar estas regras, e como um resultado dessas classes de objetos
estruturais podem seriamente limitar a flexibilidade de um sevio de
diretrio.
Eu recomendo que voc selecione uma classe estrutural bem conhecida
para cada tipo de entrada, e ento adicione classes de
objetos Auxiliares onde forem necessrias. As regras para combinar estas
classes so muito mais simples, e elas podem ser adicionadas ou
removidas onde forem necessrias. Algumas classes estruturais so:
Objetos Classes Estruturais
Pessoas inetOrgPerson
Regras organizationalRole
Departamentos organizationalUnit
Organizaes organization
9 - Layout da DIT
9.1 - Nveis Superiores
5 of 25 21-08-2014 21:58
Visual Basic - 2
Visual Basic - 3
Rede Wireless
Revistas GDH
Segurana em T.i
Antispam.br
Engenharia Reversa e
Anlise
Fraudadores
Marcos Flvio
Marcos Flvio -
DefHack
Segurana da
Informao
WireShark
Software Livre
Inproprietrio
J Soares
Lula e Dilma
Srgio Amadeu
TechNet
Implantando o
Windows 7
Licenciar seu Ambiente
Nuvem Privada
Server 2008 R2
Small Business Server
2011
Virtualizao
Windows 7
Windows Server 2008
Windows Server 2008
R2
Tecnologia
Memrias ROM e RAM
Processadores
Processadores AMD
Processadores Intel
Sistema Linux
Tipos de Conexo
Tudo sobre HD's
Cache/Buffer
Como os HDs
Os padres so pouco restritivos quando ao formato da DIT, embora se ela
for utilizada com maioria dos softwares clientes h algumas convenes
que devem ser observadas. Existem dois formatos normalmente utilizados
para nveis superiores na rvore: geogrfico e baseado em domnio. O
formato geogrfico era utilizado em todos exemplos originados dos
padres X.500, com a finalidade de permitir a procura numa escala global.
rvores baseadas em domnios foram introduzidas posteriormente, para
que os instaladores no precisassem envolver autoridades de registro
nvel do pas e fornecer uma maneira simples de mapear nomes de
domnios da Internet na DIT. As duas formas so mostradas abaixo:
Tipos de rvores:
Tipos-de-Arvores.png
Para sistemas de diretrios isolados faz pouca diferena qual forma
escolher, embora seja melhor escolher um nome baseque no "colida"
com outros diretrios que podem ser adicionados no furuto. Se for
necessrio, as duas formas podem co-existirem abaixo da mesma raiz
virtual.
Para a maioria de servios de diretrios "internos", a rvore "DC - Domain
Component" a melhor escolha. H um mapeamento direto entre nomes
DNS e nveis superiores da rvore, que permite que o endereo do
servidor LDAP seja armazenado no DNS e possa tornar a configurao do
cliente mais simples. Eu geralmente recomendo utilizar nomes DCabaixo
de uma parte "local" da rvore, por tornar mais fcil dividir a rvore atravs
de vrios servidores. caso venha a ser necessrio.
Nossa Organizao Exemplo tem seu nome de domnio exemplo.org e
ns escolhemos ds.exemplo.org como base para o servio de diretrio.
Isso traduzido no sufixo LDAP _dc=ds,dc=exemplo,dc=org*.
9.2 - Nveis Inferiores
9.2.1 - Onde colocar as pessoas
Quando construmos um servio de diretrio, h uma forte tendncia de
construir uma DIT que espelhe minimamente a estrutura da prpria
organizao. H nestas padronizaes uma viso de um projetista que a
maioria dos exemplos mostram. Elas tambm mostram uma boa maneira
de delegar gerenciamento: se todas pessoas no Departamento de
Clientes so listadas abaixo da prpria entrada do departamento, deve ser
facilmente manipulvel pelo administrador do departamento.
Infelizmente, um recurso constante na maioria das organizaes a
alterao. Departamentos so criados, so renomeados e mesclados, e a
maioria dos empregados sobrevive a essas mudanas e continuam a fazer
6 of 25 21-08-2014 21:58
funcionam
Correo de Erros
Desempenho
MTBF
NCQ
Os Discos
Vdeos e Palestras
A Filosofia do Unix
Asterisk
ExtendVoIP - Asterisk
GIMP
Jon 'Maddog' Hall
registro.br
Shell Script
Voip
Windows
Ol, eu sou o Windows
3.11, muito prazer.
RAID por Software
Samba para AD
Servidor VPN Bsico
VPN 2008 Bsico
VPN Bsico
Windows 3.1
(Emulador)
Sitemap
1259
dias aps
o seu lanamento
Visualizaes
Contato
trabalhos similares. Se ns tivermos que renomear e/ou mesclar entradas
a cada ano, as entradas das pessoas abaixo desses departamentos
tambm sero afetadas e ns j sabemos que isso ruim.
A soluo usual para este problema colocar todas as pessoas abaixo de
um simples n da DIT. Assim, como exemplo podemos criar um
n dc=pessoas,dc=ds,dc=exemplo,dc=br para este propsito. A maioria
das organizaes tem significados ligeiramente diferentes para
"fornecedores", "contratos", "parceiros nos negcios", "clientes",
"visitantes". H um senso comum para agrupar tipos de pessoas em um
lugar para que quaisquer distines necessrias sejam feitas
adicionando-se atributos s entradas individuais, ou utilizando-se grupos
de objetos.
Uma boa conveno atribuir um identificador nico para cada entrada ao
invs de a prpria entrada refletir seu contedo. Exemplo de DN:
uniqueIdentifier=67325,dc=pessoas,dc=exemplo,dc=br
9.2.2 - Representando uma Organizao
Os estilos de rvores de organogramas de uma organizao ainda so
utilizados, mesmo se nos no colocarmos as entradas para pessoas reais.
Em contextos de pginas de pesquisas, alguma procura no diretrio nem
sempre saber o nome da pessoa que necessita ser contactada: elas
apenas sabem o nmero do "Helpdesk" ou do "Departamento de
Finanas". Depois de uma grande reorganizao, muitas pessoas nem
mesmo sabero o nome do departamento que desejam contactar, ento
uma listagem geral pode ser a nica opo.
Para atender essas demandas, possvel adicionar um ramo (sub-rvore)
na DIT denominado dc=departamentos ou similar. A estrutura da
organizao pode ser representada utilizando-se um
n organizationUnit ou organizationRole. Onde for possvel, a
informao de contato dessas entradas devem ser especficadas para
a regra e no para as pessoas. Dessa forma deve ser melhor mostrar os
endereos no formato financeiro@exemplo.br do que mostrar o endereo
da pessoa que atualmente trabalha neste departamento. Se for necessrio
fazer um link para a pessoa real, utilize o atributo roleOccupant, que
efetivamente um ponteiro para a entrada em dc=pessoas da rvore.
9.2.3 - Grupos
Pessoas fazem uso de grupos para diversos propsitos. O diretrio deve
ter como representar comits, listas de emails, clubes, pessoas com
poderes particulares ou previlgios, etc. Alguns grupos podem ter
significados numa organizao (Departamento de Suporte Tcnico) mas
7 of 25 21-08-2014 21:58
E-mail: rslayer@Gmail.com
Twitter: @RobsonSlayer
outras podem somente ter significado para uma pessoa (Grupo Particular
do Joo).
Grupos so normalmente representados por objetos LDAP da
classe groupOfNames. Nestes objetos, membros de grupos so
representados pelo atributo member, cujos valores so DNs dos prprios
membros. O atributo member pode obviamente ter vrios valores. Este
um schema simples, mas j temos dois problemas significantes:
A classe groupOfNames tem o atributo member como obrigatrio.
Isso significa que no possvel criar um grupo vazio, o que torna o
gerenciamento dos dados mais trabalhoso.
No possvel anexar nenhuma informao extra ao valor DN para
mostrar porque a pessoa um membro. Isso torna o trabalho mais
difcil para os administradores, onde voc pode precisar saber quem
a Secretria e quem um observador.
H algumas maneiras de contornar estes problemas, mas eles envolvem a
alterao de classes de objetos e a estruturas desses objetos. Isso pode
quebrar a compatibilidade com as aplicaes existentes, ento
cuidadosamente analise se essa necessidade essencial.
Grupos podem ser colocados em qualquer parte da DIT, mas as
necessidades para um conjunto de grupos compartilhados comum que
seja criado um ramo da rvore especialmente para este propsito.
Dependendo da complexidade da organizao, isto pode ser simplesmente
um n dc=grupos, or pode ser uma sub-rvore dividido em categorias
diferentes.
9.2.4 - Dados Especficos de Aplicaes
A maioria das aplicaes necessitam armazenar configuraes de dados
em algum lugar. Para aplicaes de rede existem vantagens em
armazenar estas informaes no diretrio LDAP:
Mltiplos servidores podem facilmente acessar as configuraes.
Configuraes podem ser gerenciadas com um editor genrico de
LDAP ou um editor de aplicaes.
Armazenar configuraes num LDAP, pode tornar possvel
desenvolver servidores de aplicaes efetivamente "dataless" pois
elas podem ser replicadas facilmente e no necessitam serem
backupeadas.
Muitas aplicaes de rede usam o LDAP para autenticao.
Colocando os dados referentes s autorizaes no mesmo LDAP
pode ajudar nas consistncias e eficincia.
Elas podem ser um ramo da DIT para cada aplicao. O gerenciamento
dessas sub-rvores podem ser delegadas aos gerentes de aplicaes. O
servio LDAP pode ele mesmo ser uma aplicao de rede, que poder
8 of 25 21-08-2014 21:58
ento ter uma sub-rvore na qual se armazenam grupos usados para
compor o "controle de acesso" do LDAP.
9.3 - Resumo da DIT
A DIT para a Organizao Exemplo agora tem ramos (sub-rvores) para
diversos propsitos especficos, como mostrado abaixo:
Viso de DIT:
Visao-de-DIT.png
10 - Atributos e Classe de Objetos
Toda informao numa entrada de diretrio pode ser armazenada como
pares de atributos-valores. Esses conjuntos de atributos que podem
aparecer numa determinada entrada definido pelo objectClass. Alguns
desses atributos so obrigatrios, mas a maioria so opcionais. Novos
atributos podem ser definidos caso seja necessrio, e novas classes de
objetos podem tambm serem adicionadas para permitir que novos
atributos sejam inseridos nas entradas.
Os padres j definem um grande quantidade de atributos, ento uma
parte importante de um projeto de schema decidir quais iremos
realmente utilizar. Esta seo prope um sub-conjunto razovel para
iniciar.
Os atributos mais comuns dividem-se em vrios grupos:
Atributos Postais: esses relacionam-se com a localizao fsica e
entrega de objetos fsicos.
Atributos Nominativos: referem-se aos nomes reais dos objetos
do mundo real que esto representando, e so normalmente
usados para pesquisa.
Atributos Descritivos: fotos, descrio textuais, etc.
Atributos de Telecomunicao: nmeros de telefone, endereos
de email, etc.
Atributos de Autenticao: nomes de usurios, identificadores
nicos, dados do Samba e Kerberos, Certificados X.509.
Atributos de Gerenciamento: donos, gerentes, listas de controle
de acessos.
10.1 - Atributos Nominativos
A maioria desses so derivados de um tipo de atributo genrico. Else tem
um comprimento limite de 32768 caracteres, utilizam o conjunto de
caracteres UTF-8, e as operaes so "case-insensitive".
Nas descries abaixo, pargrafos em itlicos so estrados
diretamente dos documentos padres LDAP ou X.500.
9 of 25 21-08-2014 21:58
10.1.1 - cn (Common Name)
Este o atributo X.500 commonName, que contm um nome de um
objeto. Se o objeto correnponde a uma pessoa, este normalmente
o nome completo da pessoa.
cn frequentemente multi-valorado, para permitir pesquisa no diretrio,
ex.:
cn: Dino da Silva Sauro
cn: Sr D S Sauro
cn: Animal Dino Sauro
um campo obrigatrio para a classe person, e um dos mais
importantes atributos utilizados para pesquisas. Tambm utilizado em
entidades que no so person: salas, regras, impressoras, grupos, etc.
Note que algumas informaes que aparecem no cn tambm aparecem
em outros atributos, particularmente sn, givenName, personalTitle,
e displayName. Este uso do cn muito importante para fornecer suporte
s pesquisas, principalmente onde nomes podem incluir caracteres onde
no estejam disponveis em todos teclados. Exemplo de nomes em
Portugus Brasileiro:
cn: Usurio Nio Jnior
cn: Usuario Nino Junior
Neste caso, o atributo CN armazena o nome "real" e tambm o formato
simplificado que pode ser digitado ser levar em conta a acentuao. Os
CN simplificados permitem uma busca mais fcil, e o nome real est
disponvel juntamente co os atributos displayName, sn e givenName.
10.1.2 - displayName
Quanto mostrando uma entrada, especialmente numa resumo de
lista "on-line", ele utilizado para parmitir a identificao do nome a
ser utilizado. Considerando que outros tipos de atributos como 'cn'
so multi-valorados, um tipo de atributo adicional necessrio.
'displayName' definido para este propsito.
Este um atributo de um nico valor. fortemente recomendado que este
atributo seja preenchido com o formato do nome preferido (que dever
tambm aparecer como um valor do cn). Todas marcaes de acentuao
devem ser includas.displayName deve ser usado em todas entradas que
necessitam ser identificadas com acentuao.
10.1.3 - sn (Surname)
Este o atributo X.500 surname, que contm o sobrenome de uma
pessoa.
10 of 25 21-08-2014 21:58
uma entrada obrigatria e pode armazenar mltiplos valores. Os padres
utilizados seguem o modelo Ocidental, e eu sugiro que onde as pessoas
no tenham 'sobrenomes', portanto o nome inteiro deve ser colocado em
ambos atributos cn esn.
Note que sobrenomes como Jos Maria deve ser manipulado como um
simples valor de sn. O uso de mltiplos valores pode ser apropriado onde
algumas pessoas tiveram seus nomes alterados recentemente, mas isso
um risco pois muitas aplicaes assumem que apenas um nico
atributo sn exista no diretrio, tornando intil a presena de mltiplos
valores. Alteraes nos nomes so tratadas de uma melhor forma apenas
acrescentando valores no atributo cn. Os valores armazenados no
atributo sn devem estar no formato "correto" e com todas acentuaes
normalmente utilizadas pelas prprias pessoas.
10.1.4 - givenName
O atributo givenName utilizado para armazenar a parte do nome
da pessoa que no esteja no sobrenome nem no meio do nome.
um atributo menos utilizado. Fornece uma melhor normalizao de
dados que cn e custa pouco acrescentar este atributo na maioria dos
casos. Assim como sn, deve ser incluro no formato "correto" e com todas
acentuaes.
10.1.5 - personalTitle
O tipo do atributo Ttulo Pessoal especifica um ttulo pessoal para
uma pessoa. Exemplos de Ttulos Pessoais so: "Sr", "Dr", "Prof" e
"Exmo".
De acordo com a RFC1274 ele tem o limite mximo de 256 caracteres. Ele
permite mltiplos valores, mas onde um indivduo tiver mltiplos ttulos
melhor colocar todos ttulos em uma nico atributo para preservar a ordem,
ex.: "Exmo Sr Dr".
10.1.6 - o (Organisation Name)
... uma string escolhida pela organizao (ex.: "Telecom Exemplo
Ldta"). Qualquer variao deve estar associada com o nome e ser
adicionado valores com atributos alternativos.
O uso de mltiplos valores permitido em entradas descrevendo
organizaes, mas pode no ser relevante quando utilizando esse atributo
numa entidade pessoa.
O limite era de 64 caracteres segundo X.520. A RFC2256 o redefine
abaixo da superclasse name, fazendo com que no LDAP tenha um novo
limite de 32768 caracteres.
11 of 25 21-08-2014 21:58
10.1.7 - ou (Organisational Unit Name)
O tipo do atributo 'Organisational Unit Name' especifica uma
unidade organizacional. Quando usado como um componente de
um nome de diretrio ele identifica uma unidade organizacional com
a qual o nome do objeto est associada.
Essa unidade organizacional designada entendida para ser parte
de uma organizao que por sua vez designada por um atributo
do tipo 'Organisational Unit'. Isso sugere que se um atributo
'Organisational Unit Name' utilizado em diretrio, ele deve estar
associado com um atributo 'Organisation Name'.
Um valor do atributo 'Organisational Unit Name' uma "string"
escolhida para a organizao da qual faz parte (ex.: "Diviso de
Tecnologia"). Note uma abreviatura normalmente utilizada "DT"
deve ser separada em um atributo alternativo.
O limite era de 64 caracteres segundo X.520. A RFC2256 o redefine
abaixo da superclasse name, fazendo com que no LDAP tenha um novo
limite de 32768 caracteres.
10.2 - Atributos Descritivos
10.2.1 - jpegPhoto
Usado para armazenar um ou mais imagens de uma pessoa
usando um Arquivo em Formato JPEG (.jpg) [JFIF].
O limite de 250000 bytes. Se este atributo utilizado, h uma tendncia
em aumentar o tamanho de uma entrada, podendo impactar na
performance do LDAP. Consequentemente deve-se utilizar uma imagem
menor possvel.
10.2.2 - description
Este atributo contm uma descrio mais detalhada do objeto.
O limite de 1024 caracteres. mais utilizado em entradas relacionadas
aplicaes ou grupos do que nas relacionadas com pessoas.
10.3 - Atributos Postais
X.500 herdou muitos destes atributos antes dos padres ISO e CCITT.
Infelizmente eles no desenvolveram um conjunto completo e no
ambguo. Eu sugiro ignorar a maioria deles
(locality, streetAddress, stateOrProvinceName, etc) em detrimento de
outros (country, postcode, e endereos postais completos).
10.3.1 - postalAddress
12 of 25 21-08-2014 21:58
(De X.520(1988)) ... informao de endereos necessria para uma
entrega fisica de mensagens postais. ...
... limitado a at 6 linhas de 30 caracteres cada, incluindo um
'Postal Country Name'. Normalmente a informao contida nestes
endereos devem incluir nome, endereo da rua, cidade, estado,
cep e possivelmente uma caixa postal dependendo das
necessidades do objeto.
A implicao aqui que este atributo deve caber em etiquetas de
endereos ou serem utilizadas diretamente em cartas que sero impressas
(tipo mala-direta).
10.3.2 - postalCode
Os atributos especficos do 'postalCode' o prrio codigo postal do
objeto. Se este valor do atributo estiver presente, ele deve ser parte
do objeto 'postalAddress'.
Limitado a at 40 caracteres. (Maior que uma simples linha no
'postalAddress'!) Note que o atributo 'postalAddress' tambm deve conter o
'postalCode', mas se ele utilizado para manter uma cpia separada
para facilitar o endereamento de cartas (Isso menos utilizado fora da
UK, e na maioria dos pases o cdigo postal somente identifica uma rea
especfica. J no endereamento da UK este cdigo postal muito mais
especfico).
10.3.3 - c (Country Name)
Este atributo contm apenas duas letras correspondente ao pas de
acordo com a ISO 3166.
Este atributo pode apenas ter um ncio valor. Note que h tambm um
atributo 'friendlyCountryName' que pode ser utilizaedo para armazenar um
ou mais cdigo de paises. Na maioria dos casos melhor utilizar o c com
duas letras e deixar a apresentao do 'friendlyCountryName' para a
interface do usurio.
10.4 - Atributos de Telecomunicaes
Este um grande grupo, muitos aparecem em ambos formulrios
"residencial" e "trabalho". Este subconjunto mostrado aqui fornecido pela
maioria das aplicaes de "listas telefnicas".
10.4.1 - mail (RFC 822 mail address)
A RFC 1274 utiliza o antigo nome 'rfc822Mailbox' e sintaxe OID de
'0.9.2342.19200300.100.3.5'. Todos documentos recentes do LDAP
e a maioria dos desenvolvimentos do LDAP referem-se ao atributo
como 'mail' e define uma sintaxe 'IA5 String' utilizando o OID
13 of 25 21-08-2014 21:58
'1.3.6.1.4.1.1466.115.121.1.26'.
Este o endereo eletrnico de email, que deve ser preenchido totalmente
no formato RFC822 (ex.: andrew.findlay@skills-1st.co.uk). Note que o
atributo pode ter mltiplos valores e nenhuma ordem de preferncia
implicita: eu sugiro um nico valor, pois no h maneira de expressar uma
ordem de preferncia desses mltiplos valores. Note tambm que
seguindo a RFC822 o atributo somente permite um conjunto de caracteres
de 7-bit (sem acentos).
Seu tamanho mximo limitado 256 caracteres.
10.4.2 - telephoneNumber
Nmeros de telefone so recomendados no X.520 para utilizarem
um formato internacional, conforme descrito no E.123 [15].
Exemplo: +55 67 3389 3961
Nmero de telefone seguem a sintaxe printableString que permite um
conjunto grande de caracteres sejam aceitos. Isso permite coisas do
tipo: +55 21 123456 x9876
Uma conveno local necessria se uma extenso desses nmeros for
includa. Note que tambm existem
atributoshomeTelephoneNumber, facsimileTelephoneNumber, e
atributos mobile (celulares) com caractersticas similares.
Seu tamanho mximo limitado 32 caracteres.
10.5 - Atributos de Autenticao
Padres LDAP definem um grande conjunto de atributos para descrever
contas de computadores e para armazenar os certificados X.509. Somente
alguns mais simples so mencionados aqui.
10.5.1 - uid (User Identifier)
O atributo do tipo 'User Identifier' especifica um nome de login num
sistema de computadores.
Tem comprimento limitado a 256 caracteres. Note que este atributo no o
UID do Unix: ele um nome de usurio. Se dados de contas Unix esto
armazenadas num formato LDAP, ento o atributo uidNumber deve ser
usado para representar os UID numricos. Note tambm que este um
atributo 'case-insensitive'. Ento os usurios root e ROOT referem-se ao
mesmo objeto que tratado de forma diferente no Unix tradicional.
10.5.2 - userPassword
14 of 25 21-08-2014 21:58
Senhas so armazenadas utilizando a sintaxe 'Octet String' e no
so criptografadas. Tranferir senhas em modo claro so fortemente
desencorajadas onde o servio de transporte no possa garantir
confidencialidade e pode resultar numa captura dessas senhas por
pessoas no autorizadas.
A defnio apresentada vem da RCF2256. Entretanto, a RFC2307
expande a definio para permitir que um hash da senha seja
armazenada. Note que essas senhas em hash no podem ser utilizadas
com todos mecanismos de autenticao e sua escolha no
recomendada.
Este atributo pode ter mltiplos valores, cada qual limitado a at 128
caracteres.
As 'listas de controle de acesso' normalmente utilizam-se desse atributo
para evitar que qualquer um possa ter acesso a esssa informao
(excetuando-se os "administradores do LDAP" e o prprio dono da
entrada).
10.5.3 - Atributos de conta Unix
Existem um conjunto de atributos conhecidos como "Schema NIS", que
diretamente mapeiam campos para os arquivos/etc/passwd e /etc/group do
Unix. Eles devem ser includos onde o diretrio LDAP est atuando como
um NIS (Network Information Service). Veja a referncia 1 abaixo para
mais informaes.
Atributos
incluem uidNumber, gidNumber, gecos, homeDirectory, loginShell, e um
conjunto completo que descreve as regras de expirao de senhas. Veja a
referncia 2 [RFC2307].
10.5.4 - Atributos Samba e Windows
Verses recentes do samba pode utilizar o diretrio LDAP para armazenar
informaes de Domnio Windows. Isso permite contas Windows serem
utilizadas jutamente com contas Unix. Novamente veja referncia 1 para
mais detalhes.
10.5.5 - Atributos X.509
Diretrios so uma parte importante para qualquer Infraestrutura de
Chaves Pblicas (PKI - Public Key Infrastructure). Atributos so fornecidos
para armazenar certificados, listas de certificados revogados, etc.
10.6 - Atributos de Gerenciamento
15 of 25 21-08-2014 21:58
10.6.1 - title
O atributo 'title' serve para armazenar a posio ou funo de um
objeto dentro de uma organizao.
Exemplo: title=Gerente, Aplicaes Distribudas
Tem um limite mximo de 64 caracteres no X.520. A RFC2256
redefine title abaixo da superclasse name, ento no LDAP tem um novo
limite mximo de 32768 caracteres.
10.6.2 - owner
O atributo owner especifica o nome de alguns objetos que tem
algumas reponsabilidades sobre o objeto associado. O valor um
"Distinguished Name" e deve estar no formato X.520.
Este atributo muito utilizado em conjunto com Lista de Controle de
Acesso para delegar controles de entradas no diretrio para uma pessoa
em particular.
10.6.3 - member
_O atributo 'member' usado em entradas que definam grupos.
Utilizando a sintaxe do 'Distinguished Name', ento cada valor
efetivamente um ponteiro para outra entrada no diretrio. um
atributo multi-valorado. Note que a classe padro 'groupOfNames'
tem esse atributo como obrigatrio. Como os atributos no podem
ser vazios, isso requer que todos os grupos tenham pelo menos um
membro, ou seja, no possvel ter um grupo vazio. Para evitar
problemas dessa natureza, eu sugiro criar uma nova classe de
objetos que tenha o atributo membro como opcional ao invs de
obrigatrio.
Entradas de grupos so frequentemente importantes na definio das
regras de controle de acesso. Elas tambm so muito utilizadas por
aplicaes que expressem polticas de autorizao.
10.6.4 - Lista de Controle de Acesso
Na maioria dos sistemas de diretrios h uma necessidade de controlar
quem pode realizar atualizaes, e frequentemente h tambm a
necessidade de controlar quem pode ler determinadas informaes (o
atributo userPassword um exemplo clssico). Isto normalmente feito
utilizando as ACLs (Access Control Lists), mas infelizmente essa estrutura
no padronizada e varia de um servidor LDAP para outro.
ACLs so frequentemente armazenadas como atributos numa DIT,
afetando sub-rvores inteiras (_IBM Tivoli Directory Server_ , Oracle
Internet Directory, Red Hat Directory Server, Fedora Directory Server). Em
16 of 25 21-08-2014 21:58
alguns casos so armazenados fora da DIT com regras que afetam todas
entradas (OpenLDAP).
10.7 - Classes de Objetos
Nossa Organizao Exemplo ir necessitar definir algumas classes de
objetos novas. Isto requer um nico Identicador de Objeto (Object Identifier
- OID) para toda a base. OIDs podem ser obtidos diretamente na IANA
no http://www.iana.org/cgi-bin/enterprise.pl ou por muitas entidades
nacionais para este fim.
Assumindo que a Organizao Exemplo tem o OID '1.3.6.1.4.1.98546'
atribudo a ela, podemos ter algo como:
OID Propsito
1.3.6.1.4.1.98546.1 Directory Service
1.3.6.1.4.1.98546.1.1 Attribute Types
1.3.6.1.4.1.98546.1.2 Object Classes
1.3.6.1.4.1.98546.1.2.1 exampleObject
1.3.6.1.4.1.98546.1.2.2 examplePerson
1.3.6.1.4.1.98546.1.2.3 exampleGroup
10.7.1 - exampleObject
A classe exampleObject ir ser alicada na maioria de todas entradas no
diretrio. Sua finalidade requerida quando odisplayName adicionado, e
para permitir uniqueIdentifier pois ns o utilizaremos nos RDNs:
objectclass ( 1.3.6.1.4.1.98546.1.2.1 NAME 'exampleObject'
DESC 'Objetos da organizacao exemplo.org'
SUP top AUXILIARY
MUST displayName
MAY uniqueIdentifier )
Se precisarmos alterar depois, deve ser possvel adicionar mais atributos
permitidos nesta classe de objetos e ela ir automaticamente estar
disponvel em todas entradas que a utilizarem. A adio de atributos extras
obrigatrios no desejada, pois as entradas j existentes no os teriam,
e assim os dados j no diretrio no combinariam o schema.
10.7.2 - examplePerson
Esta classe existe para permitir atributos dentro das entradas das
"pessoas" que no sejam permitidas pelo inetOrgPerson. Inicialmente
muito simples, e apenas adiciona atributos personalTitle e ou:
17 of 25 21-08-2014 21:58
objectclass ( 1.3.6.1.4.1.98546.1.2.2 NAME 'examplePerson'
DESC 'Pessoas da organizacao exemplo.org'
SUP exampleObject AUXILIARY
MAY ( personalTitle $ ou ))
Note que o nome examplePerson uma super-classe do exampleObject.
Isso significa que todas entradas doexamplePerson devem tambm estar
de acordo com as requisies do exampleObject - alm de incluir o
atributodisplayName.
10.7.3 - exampleGroup
uma alterao na classe padro groupOfNames. Note que esta uma
classe "estrutural" ao invs de uma classe "auxiliar", e normalmente deve
ser utilizada sozinha.
objectclass ( 1.3.6.1.4.1.98546.1.2.3 NAME 'exampleGroup'
DESC 'Grupo da organizacao exemplo.org'
SUP top STRUCTURAL
MUST displayName
MAY ( member $ description $ owner ))
Alterando o atributo member para opcional iremos permitir grupos vazios.
10.8 - Entries
Agora ns temos um conjunto de atributos para escolher de algumas
classes de objetos que iremos utilizar. Nesta seo ns veremos como
estas so combinadas para criar entradas comuns.
10.8.1 - People
Entradas que descrevem pessoas sero baseadas na classe de
objetos inetOrgPerson. Ns iremos tambm adicionar uma
classe examplePerson, e utilizaremos exampleObject com ela. Pessoas
tero entradas com RDNs no formatouniqueIdentifier=37284 para que
tambm aparecem em cada entrada.
O conjunto inicial de atributos para entrada do tipo "person" :
Atributo Observaes Obrigatoriedade
objectClass inetOrgPerson examplePerson Y
uniqueIdentifier Valores nicos, usados como
RDN
Y
cn Pode ser multi-valorado,
exemplo: Mr Brian Stanley
Y
18 of 25 21-08-2014 21:58
Walker Paddy Walker
sn Sobrenome Y
gn Nome Conhecido(s) N
personalTitle Exmo, Dr, Sr, Prof, etc N
displayName A forma tradicional do nome
como escrito, ex: Sr Harry
Potter III O valor armazenado
aqui deve sempre ser composto
de outros atributos.
Y
title Profisso ou Titulo, ex: "Analista
de TI
N
jpegPhoto Pode ser utilizado para
verificao. Recomenda-se ser a
menor possvel.
N
mail Endereo de E-mail. N
telephoneNumber Deve ser o nmero do
"escritrio". Todos nmeros de
telefone devem estar no formato
internacional, ex: +44 1763
273475
N
mobile Tefefone celular N
postalAddress Endereo pre-formatado para
uso diretamente em "etiquetas",
etc.
N
postalCode Cdigo Postal N
ou Nome da Unidade
Organizacional
(departmento/diviso etc)
utilizado onde uma procura
retorna diversas entradas.
Verificar o departamento poder
ajudar.
N
Com isso ns adicionamos atributos de NIS e de autenticao para
permitir contas Unix ou Windows.
10.9 - Regras
Regras aparecem em ramos de Departamentos na DIT, e so baseadas
em classes de objetos organizationalRole. RDNs seguem a conveno
19 of 25 21-08-2014 21:58
estabelecida para entradas "pessoas": uniqueIdentifier=783263 (note que
os padres apenas requerem que esses IDs sejam nicos na entrada que
ele pertence, mas melhor faz-lo nico dentro do diretrio inteiro).
objectClass organizationalRole
exampleObject
Y
uniqueIdentifier Valor nico, usado como RDN Y
cn Pode ser multi-valorado, ex: cn:
Escritorio Financeiro cn:
Contador Principal
Y
displayName A forma tradicional do nome
como escrito, ex: Escritrio
Financeiro.
Y
mail Endereo de E-mail. Onde for
possvel deve ser o mais
"funcional"
comofinanceiro@exemplo.org ao
invs do endereo da pessoa
responsvel.
N
telephoneNumber Todos nmeros de telefone
devem estar no formato
internacional, ex: +44 1628
782565
N
postalAddress Endereo pr-formatado para
uso diretamente em "etiquetas",
etc.
N
postalCode Cdigo Postal N
roleOccupant DN da entrada da pessoa onde a
pessoa que preenche o papel
conhecida na base de dados de
LDAP.
N
ou Nome da Unidade
Organizacional
(departmento/diviso etc)
Embora esta informao possa
tambm aparecer no DN
completo, isso torna a pesquisa
mais simples se estiver repetida
nas entradas.
N
20 of 25 21-08-2014 21:58
10.10 - Unidades Organizacionais
Departamentos, divises, e entidade similares so representadas na parte
da estrutura da DIT.
ou Nome da Unidade
Organizacional. (pode ser multi-
valorado)
Y
o Nome da Organizao (pode ser
multi-valorado). Este uso permite
que mltiplcas organizaes
possam ser representadas numa
rvore, tornando a pesquisa
mais fcil e com mais detalhes.
N
displayName Necessrio se 'ou' for multi-
valorado.
Y
mail Endereo de E-mail principal. N
telephoneNumber Tronco de Telefone principal. N
postalCode Cdigo postal N
uniqueIdentifier Utilizado como RDN de entradas
obrigatrias. Somente precisa
ser nico entre entradas
vizinhas.
N
10.11 - Dados compartilhados entre aplicaes
Organizaes frequentemente tem conjunto de dados que so usados por
vrias aplicaes. Um exemplo pode ser uma lista de paises com seus
cdigos (ISO 3166), e imagens de suas bandeiras e outros dados. Este
conjunto de dados na maioria apenas para leitura um bom candidato a
ser includo num diretrio corporativo.
Os dados dos paises pode ser includos definindo um ramo da DIT do
tipodc=paises,dc=aplicacoes,dc=ds,dc=example,dc=org e uma classe
de objetos para estas entradas. Cada entrada deve conter tais atributos:
c Cdigo de duas letras para
pas (ISO 3166 )
Y
displayName Nome completo do pas Y
21 of 25 21-08-2014 21:58
exampleThreeLetterCC Cdigo de trs letras para
pas (ISO 3166)
Y
friendlyCountryName Nome completo do pas,
possivelmente incluindo os
nomes em diversas
lnguas.
Y
jpegPhoto Bandeira nacional em
formato JPEG. Se imagens
no formato PNG
necessitarem serem
armazenadas, um novo
atributo precisa ser
definido.
Y
Servidores LDAP so capazes de fazer pesquisas em quase todos
atributos, ento uma variedade de pesquisas so possveis em cada
conjunto de dados.
10.12 - Autenticao e autorizao
Aplicaes de rede frequentemente utilizam LDAP como suporte para
autenticao. Na forma mais simples, apresentado um usurio e senha
para que o usurio faa uma operao de Bind no LDAP: se o Bind
executado com sucesso, ento a senha est correta. Schemas mais
seguros envolvem Kerberos ou certificados X.509 so tambm suportados.
Autorizao pode ser mais complexa: esse trabalho envolve dar permisso
a um usurio que comprove sua identidade. A maioria das aplicaes
definem um conjunto de regras, cada uma com permisses para certas
coisas, e atribuem usurios estas regras. Isso pode ser representado
utilizando-se atributos multi-valorados no diretrio LDAP. Nossa
Organizao Exemplo tem um portal web com um gerenciador de
contedo (CMS). Assim suportamos vrios nveis de acesso:
leitura nos dados pblicos
leitura em certas categorias de dados
autor que permite criar novas entradas
editor para modificar dados criados por outros
gerente para definir permisses de outros
O primeiro nvel o default para todos usurios. Todo o restante necessita
ser representado nos diretrios. Existem basicamente duas maneiras que
podem ser utilizados aqui:
Coloque atributos de permisses na entrada do usurio, e d um
valor para cada permisso que o usurio tiver.
1.
Crie um entrada em algum lugar para cada permisso, e use o
atributo member para listar os usurios que tenham esta permisso.
2.
22 of 25 21-08-2014 21:58
A primeira maneira tem a vantagem que um simples diretrio fornece
leitura para todas autenticaes e dados de autorizaes para um
determinado usurio. Tambm fcil delegar "poderes" para usurios
muito facilmente. Entretanto, isso significa que o "gerente" do portal web
dever dar acesso para cada entidade de usurio, e cria o risco que um
usurio ou gerente possa ser capaz de alterar seus prprios nveis de
acesso no portal web.
A segunda coleciona todas od dados das permisses para uma aplicao
numa parte dedicada da DIT. Isso torna mais simples gerenciar e tambm
mais seguro, mas requer alguns efeitos extras quando usurios so
deletados. Tambm permite armazenar os dados relativos a permisses
num servidor LDAP separado, caso seja necessrio. Pessoalmente eu
recomendo essa segunda forma.
Dados de autorizao devem estar numa parte da DIT especfica para
aplicao. No exemplo do portal web, ns devemos provavelmente criar
uma entrada:
dc=autorizacao,dc=portal,dc=aplicacao,dc=ds,dc=exemplo,dc=org
Deve haver uma entrada para cada permisso que ns precisamos
representar.
Uma aplicao que precise verificar se um usurio tem alguma permisso
em particular deve fazer:
Encontrar o DN do usurio: isso normalmente feito durante a fase
de autenticao.
1.
Compor o DN relativo a permisso desejada. Isso normalmente
feito atravs de uma simples contatenao.
2.
Executar uma busca no "objeto base" pelo atributo member cujo
contedo seja o DN do usurio. Se a busca for bem sucedida, ento
o usurio tem a permisso na aplicao.
3.
10.13 - Gerenciamento de Dados
A carga inicial e o gerenciamento completo do diretrio um assunto muito
grande para ser tratado aqui. Entretanto, importante notar que os
schemas de diretrios podem ser extentidos para armazenar "chaves
extrangeiras" para as entradas que so correlacionadas com outros
bancos de dados.
Outra considerao importante definir quem ir ter permisso para
atualizar os dados no diretrio. Pode ser uma ttica permitir que os
usurios atualizem seus prprios dados, mas se isso for adotado
importante ter certeza que eles no possam modificar quaisquer atributos
que lhes dem poderes extras (tais como alterar seu numberUid para
23 of 25 21-08-2014 21:58
zero!). Onde esse gerenciamento delegado para os administradores de
departamentos, alguns atributos sero necessrios para cada entrada
mostrar qual administrador responsvel por ele.
O atributo owner muito utilizado aqui, e em alguns casos temos tambm
criado um atributo como manager que armazena o DN para uma entrada
do tipo grupo. Ento, qualquer um listado naquele grupo ir ter o
gerenciamento pelo DN dessa entrada. Ambos owner e manager podem
ser multi-valorados, que adiciona flexibilidade. claro, esses recursos
dependem do suporte do servidor LDAP em tratar mecanismos de ACL, e
nem todos podem fazer isso.
Outra dica utilizada evitar deletar entradas quando as pessoas saem da
organizao: apenas defina um atributo para informar que est inativo.
Isso possibilita uma melhor auditoria posterior, mas introduz mais
complexidade nas ACLs.
10.14 - Performance
O layout de uma DIT e os contedos das entradas podem afetar a
performance do servidor LDAP. importante considerar como os dados
devero ser utilizados, e um projeto eficiente de pesquisas. Por exemplo,
se um programa cliente necessita encontrar um atributo Unix de uma
pessoa que utiliza tem surname "Jones" melhor basear a pesquisa no
ramodc=pessoas e incluir classes de objetos na pesquisa:
(&(sn=Jones)(objectClass=person)(numericUid=*))
Similarmente, uma pesquisa de uma aplicao especfica deve evitar o
ramo "pessoas" (provavelmente com muitas entradas), e limitar a pesquisa
numa sub-rvore dedicada prpria aplicao.
Servidores LDAP podem ser otimizados de formas diferentes de consultas
ajustando parmetros de ndices e caches, e numa grande instalao ele
critico para fazer isso da maneira correta. Infelizmente, alguns clientes
LDAP insistem em pesquisar por diversos atributos. Verses anteriores do
'Evolution' eram ruins neste aspecto, e ainda (em pelo menos at 2005)
no fazem uma busca eficiente:
(&(mail=*)(|(mail=andrew*)(|(cn=andrew*)(sn=andrew*))
(displayName=andrew*)(sn=andrew*)))
Onde a performance de uma aplicao seja crtica, pode ser necessrio
replicar algumas parte ou toda a DIT para servidores dedicados com
ndices otimizados. O layoute da DIT proposta aqui permite diversas
variaes desta idia.
24 of 25 21-08-2014 21:58
10.15 - Resumo
Quando estiver construindo o diretrio LDAP importante considere todas
necessidade e planeje cuidadosamente desde o incio, pois uma
reorganizao posterior da DIT muito difcil. Organizaes sofrem
alteraes constantemente, e estas alteraes devem ser possveis de
serem realizadas sem requerer grandes alteraes no diretrio.
Este documento apresenta uma sugesto de layout da DIT e conjunto de
objetos que representam pessoas, regras, e outras entradas comuns no
diretrio. Este layout foi projetado para lidar com necessidades de
expanso futuras.
O maior benefcio em compartilhar dados entre aplicaes coloc-os
num diretrio, mas um estudo cuidadoso necessrio e algumas
ferramentas de gerenciamento provavelmente iro ser necessrias.
Fazer login | Atividade recente no site | Denunciar abuso | Imprimir pgina | Tecnologia Google Sites
25 of 25 21-08-2014 21:58

Design de Uma Dit

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Design de Uma Dit

Enviado por

Direitos autorais:

Formatos disponíveis

Robson

Você também pode gostar