of 165/165
2006, Edgard Jamho Gerência de Redes (SNMP) Serviços de Diretório (LDAP) Policy Based Networking (PBNM) Edgard Jamhour Mauro Fonseca Carlos Maziero

2006, Edgard Jamhour Gerência de Redes (SNMP) Serviços de Diretório (LDAP) Policy Based Networking (PBNM) Edgard Jamhour Mauro Fonseca Carlos Maziero

  • View
    243

  • Download
    2

Embed Size (px)

Text of 2006, Edgard Jamhour Gerência de Redes (SNMP) Serviços de Diretório (LDAP) Policy Based...

IPsec e Novas Tecnologias para Firewallsconjunto de ferramentas, procedimentos e políticas
usadas para manter o funcionamento e eficiência de uma rede, independente de seu tamanho ou finalidade.
Gerência integrada:
ferramentas e procedimentos que podem cooperar
entre si, possibilitando a definição de políticas homogêneas em um ambiente heterogêneo.
2006, Edgard Jamhour
software e hardware presente nesses dispositivos
e sua informação estática.
Provisioning: parâmetros operacionais modificáveis
2006, Edgard Jamhour
Gerência de falha
Detectar e resolver rapidamente situações que degradam o funcionamento da rede:
Determinar a origem da falha
Isolar a falha do restante da rede
reconfigurar a rede para diminuir impacto da falha
reparar ou trocar componentes com falha
2006, Edgard Jamhour
Gerência de desempenho
Assegurar que os dispositivos podem
tratar o tráfego presente na rede.
Baseia-se em dados colhidos da rede:
erros de CRC, time-outs, retransmissões
Dados históricos podem ser importantes
2006, Edgard Jamhour
Gerência de segurança
Proteção das informações
Monitorar uso dos recursos
Essencial em hosts conectados à Internet
2006, Edgard Jamhour
Gerência de contabilização
cobrar pelos serviços utilizados
planejar crescimento da rede
Informação de contabilização deve ter acesso restrito.
2006, Edgard Jamhour
Modelo de gerência
agente: age como servidor de informações de gerência
gerente: consulta os agentes
de gerência
e comandos
executa um software de gerência
interage com o operador do sistema
2006, Edgard Jamhour
Coleta de dados: monitoração (automática)
dos recursos gerenciados.
coletados para delinear o problema.
Ação: controle sobre os recursos gerenciados
para corrigir o problema.
Pooling:
Event reporting:
iniciadas pelo agente
2006, Edgard Jamhour
Dominante em redes TCP/IP
Controle (complexo) de redes complexas
Muito presente em redes de telefonia
2006, Edgard Jamhour
Informações de gerência
Informação com estrutura hierárquica
Usa como base a notação formal ASN.1
2006, Edgard Jamhour
MIB-II - Estrutura geral
Muito usado em redes TCP/IP
Comandos e tipos de dados fixos
Poucos tipos de mensagens
protocolo de transporte sem conexão
não confiável (perda de pacotes)
Comandos e respostas assíncronas
RMON-2
SNMP-V2
MIB e SMI aumentadas: novos tipos de dados
2006, Edgard Jamhour
SMFA
SMF
2006, Edgard Jamhour
simples de implementar
Evolutivo: SNMPv2, SNMPv3, RMON, ...
Endereçada através de MIBs
Transportadas através do SNMP
Single Network Management Protocol
- os ramos mgmt e private são os mais usados.
- MIB-2 é uma estrutura padrão que deve ser suportada por nós TCP/IP.
1
3
6
1
1
2
3
4
1
1
2
4
6
iso(1)
org(3)
dod(6)
internet(1)
directory(1)
mgmt(2)
experimental(3)
private(4)
mib-2(1)
system(1)
interfaces(2)
ip(4)
tcp(6)
ACCESS
DESCRIPTION
Standard MIB Object:
DESCRIPTION
“Time since the network management portion of the system was last re-initialised.
::= {system 3}
Definição em formato texto não ambíguo
Permite definir modelos de dados
Formato independente de máquina
2006, Edgard Jamhour
INTEGER (1..100): sub-tipo inteiro
OBJECT IDENTIFIER: localização de outro objeto na MIB
Aceita alguns tipos específicos de aplicação:
IpAddress: OCTET STRING com 4 bytes
Counter: inteiro 32 bits monotônico crescente
Gauge: inteiro 32 bits limitado no mínimo e no máximo
TimeTicks: inteiro 32 bits (1/100 de segundo)
2006, Edgard Jamhour
INTEGER (0..2 | 20)
INTEGER (-127..-1 | 1..128)
Valores possíveis em SNMPv1:
Mandatory
Valores contidos devem ser válidos
Optional
Deprecated
Se tornará obsoleto mais tarde
Obsolete
OID deve ser completado por “.0”
Exemplo: ....mib-2.ip.ipForwarding: 1.3.6.1.2.1.4.1.0
usam os construtores SEQUENCE e SEQUENCE OF
Convenção de tabela: xxxTable
2006, Edgard Jamhour
tcpConnEntry OBJECT-TYPE
SYNTAX TcpConnEntry
ACCESS not-accessible
STATUS mandatory
TcpConnEntry ::=
SEQUENCE {
Usa formato TLV: Type-Length-Value
Value: string de octetos contendo o valor do dado
A estrutura de codificação é recursiva
2006, Edgard Jamhour
A arquitetura SNMP
Interações sem conexão
Mensagens em UDP/IP
1996: MIB RMON v2
2006, Edgard Jamhour
Operações básicas SNMP
SET
TRAP
2006, Edgard Jamhour
Exemplo de uso
ser alterada pelas operações
Somente podem ser acessados
2006, Edgard Jamhour
Limitações de SNMP
Falta de segurança
Ineficiência
operação baseada em pooling
comandos transportam poucos dados
Falta de funções específicas
MIB com estrutura fixa
Não confiável
Uma comunidade define:
visibilidade da MIB
Cada dispositivo implementa
msg length
protocol version
community string
PDU header
2006, Edgard Jamhour
Códigos de erro
1: tooBig: resposta muito grande para enviar
2: noSuchName: OID não suportado pelo agente
3: badValue: valor incorreto para operação set
4: readOnly: tentativa de escrita inválida
5: genErr: erro não relacionado ao protocolo
Error index:
2006, Edgard Jamhour
Conteúdo das mensagens
Usa ordem lexicográfica
buscar dados em tabelas
snmpgetnext -v1 localhost -c public system
SNMPv2-MIB::sysDescr.0 = STRING: Linux espec.ppgia.pucpr.br 2.6.17-1.2142_FC4smp #1 SMP Tue Jul 11 22:59:20 EDT 2006 x86_64
snmpget -v1 localhost -c public -O n system.sysDescr.0
.1.3.6.1.2.1.1.1.0 = STRING: Linux espec.ppgia.pucpr.br 2.6.17-1.2142_FC4smp #1 SMP Tue Jul 11 22:59:20 EDT 2006 x86_64
snmpgetnext -v1 localhost -c public -O n .1.3.6.1.2.1.1.1.0
.1.3.6.1.2.1.1.2.0 = OID: .1.3.6.1.4.1.8072.3.2.10
.1.3.6.1.2.1.1.3.0 = Timeticks: (523160) 1:27:11.60
SNMPv2-MIB::sysUpTime.0 = Timeticks: (527855) 1:27:58.55
Representam eventos anormais
2006, Edgard Jamhour
warmStart:
linkDown:
2006, Edgard Jamhour
Traps genéricos (2)
authenticationFailure:
comunidade não reconhecida
egpNeighborLoss:
normalmente usado em roteadores
2006, Edgard Jamhour
Serviço de Diretório
Defini-se um serviço de diretório como sendo um "banco de dados" especializado para informações de gerenciamento.
Exemplos bem conhecidos de serviços de diretório são:
Especificação LDAP
Especificação X500
Serviços de diretório são utilizados para oferecer um repositório "logicamente" centralizado com as informações de gerenciamento.
2006, Edgard Jamhour
Um serviço de diretório deve ser capaz de:
Armazenar qualquer tipo de objeto
DNS, por exemplo, só armazena registros que relacionam nomes com endereços.
Oferecer mecanismos flexíveis de consulta
por exemplo, localizar o email de uma pessoa pela departamento onde trabalha e cargo que ocupa.
Armazenar as informações numa arquitetura decentralizada
Serviço de Diretório = Banco de Dados Distribuído.
Utilizar um mecanismo para nomear os objetos independente do seu tipo.
2006, Edgard Jamhour
Serviço de Diretório X500
X500 é um protocolo CCITT projetado para construir um serviço de diretório distribuído de alcance global.
Ele oferece as seguintes características:
Escalabilidade
Mecanismos de Procura Flexíveis
Espaço de Nomes Homogêneo
Serviço padronizado e aberto.
Definido por normas CCITT
2006, Edgard Jamhour
Modelo Funcional X500
DSP (Directory Service Protocol). Protocolo que padroniza a comunicação entre servidores. Essa comunicação ocorre quando uma consulta não pode ser satisfeita pelo servidor local.
DAP (Directory Access Protocol). Protocolo de acesso, que padroniza a comunicação entre o cliente e o servidor de diretório.
DUA (Directory User Agent) é o nome dado a parte do software do cliente que interage diretamente com o servidor de diretório.
O desenvolvimento de aplicações que interagem com o diretório é feita através de um conjunto de API's padronizadas pelo protocolo de acesso.
DSA (Directory System Agent) é a denominação dada a porção do software do servidor responsável por atender as requisições dos clientes.
2006, Edgard Jamhour
[email protected]
2006, Edgard Jamhour
Estrutura do X500
As informações de diretório do X500 estão armazenadas no DIB - Directory Information Base
cada entrada do diretório aponta para um objeto
Objeto: Usuário
nome: Edgard
sobrenome: Jamhour
email: [email protected]
nome: string
sobrenome: string
nc: string
passord: string
email: string
nascimento: data
uid: string
objectclass: Pessoa
nome: Albert
sobrenome: Einstein
nc: aeinstein
passord: 1B5A324AB3
email: [email protected]
nascimento: 01/08/1908
objectclass: Pessoa
nome: Issac
sobrenome: Newton
nc: inewton
passord: 2A2A324ZC3
email: [email protected]
nascimento: 03/09/1803
classe Pessoa
X500: Esquema de Classes
Algumas classes LDAP são derivados do X500 e definidas na RFC 2256.
objectclass: person (derivada de top)
atributos obrigatórios: sn, cn
objectclass: organizationalperson (derivada de person)
atributos opcionais: facsimileTelephoneNumber, postOfficeBox, postalAddress , postalCode, preferredDeliveryMethod , etc.
objectclass: inetOrgPerson
2006, Edgard Jamhour
Estrutura em Árvore
Os objetos podem conter outros objetos constituindo uma estrutura hierárquica em forma de árvore.
Objetos que contém outros objetos são ditos containers.
Objetos que não contém outros objetos são ditos leaf.
Uma rede de computadores ou domínio pode ser representado como uma sub-árvore no diretório.
2006, Edgard Jamhour
RDN: O=pucpr
DN: P=br
2006, Edgard Jamhour
Nomes
Um nome é utilizado para identificar cada objeto no diretório. Existem dois tipos de nomes:
Relative Distinguished Name (RDN):
cn=ejamhour
Nome Característico
identifica o objeto pelo seu caminho completo a partir da raiz.
cn=ejamhour,ou=Funcionarios,ou=ppgia,o=pucpr.br
2006, Edgard Jamhour
(Lightweight Directory Access Protocol)
Criado como uma alternativa mais simples ao protocolo padrão do X500.
DAP: Directory Access Protocol
Desenvolvido pela Universidade de Michigan em conjunto com o Internet Engineerig Task Force (ETF)
O LDAP está atualmente na versão 3: LDAP v3
Diversas normas descrevem o funcionamento do LDAP:
RFC 1777 - Protocolo
RFC 1823 - API
2006, Edgard Jamhour
Trabalha numa arquitetura cliente-servidor:
clientes LDAP se conectam a um ou mais servidores LDAP para atualizarem e obterem informações sobre o diretório.
Define um conjunto de primitivas para manipular objetos de diretório:
Bind, search, modify, delete, etc.
LDAP inclui suporte para autenticação
Simples (clear text), Kerberos e SSL são utilizados.
2006, Edgard Jamhour
O servidor LDAP pode ser de dois tipos:
Fazer uma ponte com outro servidor de diretório (e.g. X500)
Ser um servidor stand-alone.
DAP
DAP
servidor
X500
servidor
X500
servidor
LDAP
ldap[s]://<host>:<porta>/<base_dn>?<atributos>?<escopo>?<filtro>
ldap://ppgia.pucpr.br/o=pucpr,c=br?email?sub?(sn=Joa*)
www.dmtf.org
DMTF: Reuni os principais fabricantes de produtos de hardware e software pare rede: Cisco, 3Com, Microsoft, Sun, Novel, IBM, etc.
Objetivo:
Criar um formato padrão para armazenar informações de rede em um diretório LDAP, de maneira que este possa ser compartilhado por várias aplicações.
2006, Edgard Jamhour
CIM - Common Information Model
Os esquemas de diretório propostos pelo DMTF já estão implementados nas versões atuais de Solaris e Windows 2000 sob a denominação CIM:
Common Information Model
Recentemente, o DMTF juntou esforços com o IETF e criou o PCIM:
PCIM: Police Core Information Model (RFC3060)
2006, Edgard Jamhour
Gerência de Redes Baseada em Políticas
A configuração e gerência de redes possui características que podem ser melhor descritas através de políticas.
Exemplo:
Políticas de operação normal, grande volume ou emergenciais.
Para atender essas políticas a rede precisa ser configurada, e não cada equipamento individualmente.
Políticas devem permitir mapear processos de negócio para as aplicações que utilizam a rede.
2006, Edgard Jamhour
Policy Core Information Model
Resultado entre um trabalho conjunto entre o DMTP e o IETF.
As seguintes RFC´s são atualmente publicadas pelo IETF:
Policy Core Information Model - Version 1 Specification (RFC 3060)
Terminology for Policy-Based Management (RFC 3198)
Os seguintes trabalhos estão no formato de Draft:
Policy Core LDAP Schema
Information Model for Describing Network Device QoS Datapath Mechanisms
Policy Core Information Model Extensions
2006, Edgard Jamhour
Define um conjunto de classes e relacionamentos de maneira extensível.
Políticas para o controle de objetos gerenciáveis são definidas pela extensão desse modelo.
Princípios:
PCIM representa a estrutura e não o conteúdo de uma política.
O conteúdo deve ser definido para herança das classes genéricas do PCIM de maneira a criar estrutura de políticas especializadas para áreas de aplicação e produtos específicos.
2006, Edgard Jamhour
Máquina de Estados
O gerenciamento baseado em políticas presume que a rede é modelada como uma máquina de estados.
As classes e relacionamentos do PCIM são usadas para modelar:
O estado de uma entidade
As ações para manter a entidade num dado estado ou movê-la para outro estado.
A configuração a ser aplicada numa entidade para mantê-la ou movê-la para outro estado.
2006, Edgard Jamhour
Políticas = Conjunto de Regras
Uma política PCIM é formada por um conjunto de regras. Cada regra é definida por um conjunto de condições e um conjunto de ações.
As regras podem ser priorizadas e agrupadas para modelar uma hierarquia administrativa.
Política
2006, Edgard Jamhour
2006, Edgard Jamhour
Policy Based Networking
RFC 2748:
RFC 2749:
RFC 2753:
RFC 3084:
2006, Edgard Jamhour
A conexão TCP é permanente
As mensagens COPS são transmitidas como objetos independentes e flexíveis
novos objetos podem ser criados
A segurança pode ser implementada por IPsec ou TLS.
PEP
PDP
Request
Decision
Report
PEP
PDP
O PDP é stateful.
As requisições feitas pelos PEPs são “lembradas” pelo PDP até que sejam explicitamente apagadas pelo PEP.
As mensagens COPS são enviadas através de conexões TCP iniciadas sempre pelo PEP.
Na inicialização o PEP solicita a carga de uma configuração inicial.
Mas o PDP pode enviar mensagens não solicitadas ao PEP através dessas conexões.
As decisões tomadas pelo PDP são assíncronas.
O PDP pode carregar novas configurações no PEP.
O PDP pode remover certas configurações no PEP quando elas não forem mais necessárias.
2006, Edgard Jamhour
Permite ao PEP tomar decisões na ausência do PDP.
O LDPD não é um substituto do PDP.
O PDP central é autoritário sobre o LPDP.
Todas as decisões importantes devem ser enviadas ao PDP central.
Nó de Rede
1) O PEP faz uma conexão TCP no PDP.
2) O PEP envia uma mensagem de “Request” identificando o tipo de política desejada .
3) O PDP envia para o PEP as configurações através de mensagens “Decision”.
4) O PEP instala as configurações e quando estiver pronto envia a mensagem “Report”.
5) O PDP pode enviar uma mensagem “Decision” não solicitada para o PEP para anular uma requisição já concedida.
6) O PEP deve responder a essa mensagem com “Report”.
2006, Edgard Jamhour
Mensagens COPS
As mensagens COPS são formadas por um cabeçalho fixo, seguido por um número variável de objetos.
Version:
Op Code:
Mensagem COPS
Client Type:
Message Length
version
flags
6 = Client-Open (OPN)
7 = Client-Accept (CAT)
8 = Client-Close (CC)
9 = Keep-Alive (KA)
Indica o subtipo ou versão da informação transportada pelo objeto.
2006, Edgard Jamhour
Quick background,
COPS does Policy Control of IP. Today, one of the most pressing issues with the traffic convergence at the IP layer is providing adequate QoS. IP is best effort delivery, but certain applications such as VoIP require QoS to solve the voice clipping that occurs in a congested IP best effort environment.
The IETF Policy Framework is a client service model, where the Policy Decision Point, PDP controls the policy and the Policy Enforcement Point PEP, which is generally a router or switching element enforces the policy.
Our sister organization, vBNS did early research in the area of providing QoS for IP traffic. They have a Reserved Bandwidth Service which uses COPS - for controlling RSVP signals.
vBNS decided that the ENSD MSCP and our work with policy control of ATM SVC’s was a good fit for their Reserved Bandwidth Service and they had us develop a COPS-RSVP PDP which is called the RBS.
2006, Edgard Jamhour
Modelos de PDP/PEP
Outsourcing:
Poucas informações são armazenadas no dispositivo gerenciado (PEP).
O PEP consulta ao PDP para tomar decisões relativas aos eventos do dispotivo.
Provisioning:
A maioria das informações de configuração é armazenada no PEP na inicialização do dispositivo.
O PEP toma a maioria das decisões localmente.
2006, Edgard Jamhour
2006, Edgard Jamhour
2006, Edgard Jamhour
PIB - Policy Information Base
Similar a MIB, utilizada pelo SNMP, uma PIB é uma árvore lógica que permite representar políticas na forma de variáveis unicamente identificadas.
PRC - Provisioning Classes
PRI - Provisioning Instances
2006, Edgard Jamhour
Tipos de Classes PIB
1) Notify: PEP PDP
os valores dos atributos destas classes são definidos pelo próprio dispositivo (PEP).
2) Install: PDP PEP
os valores dos atributos destas classes são preenchidos de acordo com a decisão do PDP.
3) Notify / Install : PDP PEP
as classes deste tipo combinam as características dos dois ítens acima,
2006, Edgard Jamhour
Exemplo: Diffserv PIB
O IETF definiu algumas PIBs padronizadas, como para os casos do IPsec e do Diffserv.
2006, Edgard Jamhour
Exemplo: Diffserv PIB
2006, Edgard Jamhour
O feedback do uso de políticas pode ser:
Periódico ou solicitado
As políticas solicitadas definem as características a serem monitoradas e o intervalo para envio de relatórios.
O feedback é enviado pelo PEP pela mensagem de Report
O feedback pode ser utilizado para implementar políticas dinâmicas e mecanismos de contabilização.
2006, Edgard Jamhour
Failover
Se a conexão TCP com o PDP cair o PEP usa as políticas guardadas em cache.
No restabelecimento da conexão, o PDP envia uma mensagem de re-sincronização para as políticas guardadas em cache.
2006, Edgard Jamhour
Conclusão
Policy Based Networking é uma nova abordagem amplamente adotada pelo DMTF e o IETF.
A arquitetura de Policy Based Networking é baseada no framework:
PDP, PEP e COPS.
Sua aplicabilidade inicial é para gerenciar políticas de QoS e Segurança em dispositivos de rede.
Todavia, o modelo PCIM pode ser adaptado para qualquer outra área de configuração e contabilização de dados.
2006, Edgard Jamhour
analisar valores isolados (nos agentes)
Como medir o tráfego na rede ?
tráfego = 137 kbps
tráfego = 55 kbps
monitor
Podem ser aplicadas filtragens
Produção de dados estatísticos
percentual de colisões
taxas de transferência
2006, Edgard Jamhour
Monitorando múltiplas redes
Monitores devem ser acessíveis pelo gerente
gerente
monitores
router
significado dos dados
tipos dos dados
2006, Edgard Jamhour
Define uma (imensa) MIB
Efetua a monitoração contínua de redes
Versões:
RMON v2: monitora camadas mais elevadas
Monitor: agente RMON ou sonda RMON
2006, Edgard Jamhour
Objetivos de RMON
Monitoração pró-ativa
diagnósticos contínuos
2006, Edgard Jamhour
acesso via protocolo SNMP
configuração geral
manipulação de tabelas de controle
Ações:
2006, Edgard Jamhour
Tabelas de dados:
Tabelas de controle
cada linha representa uma função de coleta
Podem ser fundidas em uma só tabela
2006, Edgard Jamhour
cada linha da tabela de controle possui um owner
propriedade: IP do gerente, localização, telefone, ...
informação de propriedade não limita o acesso
o monitor pode ser proprietário de algumas linhas
2006, Edgard Jamhour
Gerência de tabelas
Inserção e remoção de linhas nas tabelas de controle
Cada linha de tabela de controle possui:
OwnerString: o proprietário da linha de controle
EntryStatus: situação daquela linha:
set [index, (tipo, valor), (tipo, valor), ...]
erro badValue em caso de dado inválido
ou impossibilidade de criação
2006, Edgard Jamhour
1. se a linha solicitada não existe (índice inexistente),
ela é criada e seu status recebe o valor “createRequest”;
2. imediatamente após a criação o monitor muda o status da linha para “underCreation”;
3. as novas linhas permanecem nesse estado até o gerente terminar de criar todas a linhas desejadas;
4. ao final o gerente seta o campo de status das linhas criadas por ele para o valor “valid”;
5. tentativas de criar linhas cujos índices já existem
resultam em erro.
2006, Edgard Jamhour
A MIB RMON
sub-rede referenciada por sua interface
Informações mais importantes:
carga da sub-rede
pacotes fora de tamanho (undersize, oversize)
Mais detalhado que mib-2.interfaces
ao longo do tempo de operação
Cada linha da tabela de controle
define um conjunto de amostras
Cada linha da tabela de dados
corresponde a uma amostra
as 50 últimas amostras são mantidas
2006, Edgard Jamhour
hostTopN
armazena dados sobre os N primeiros hosts
em termos de tráfego, erros, tipos de pacotes, etc.
matrix
tokenRing
2006, Edgard Jamhour
gerados pelo grupo alarm
tratados pelo grupo event
Cada entrada da tabela contém:
OID da variável a ser monitorada
intervalo de amostragem
2006, Edgard Jamhour
excesso de alarmes sem utilidade
Usa dois limiares de disparo do alarme:
inferior: valor mínimo em condições normais
superior: valor máximo em condições normais
Gerar alarmes somente quando:
valor descer abaixo do limite inferior
de forma alternada !
2006, Edgard Jamhour
valor
dois tipos de filtros:
status filter: status dos pacotes (válido, erro de CRC, ...)
filtros podem ser combinados
Os pacotes filtrados:
podem disparar eventos
2006, Edgard Jamhour
uso inteligente de filtros e captura
risco de saturar a sonda e a rede
poder de processamento da sonda é limitada
Problemas de interoperabilidade
muitas funções são parcialmente implementadas
2006, Edgard Jamhour
monitoração de protocolos de aplicação
visibilidade de tráfego vindo de fora (IP)
tabelas replicadas para cada protocolo
Outras inovações
2006, Edgard Jamhour
Especificação e documentação mais elaboradas dos objetos da MIB
Novos conceitos:
Gauge32
Counter64
2006, Edgard Jamhour
Cláusula MAX ACCESS
Similar a ACCESS, enfatizando que o acesso não pode ser modificado por configuração do agente
Níveis de acesso:
extremamente complexo e controverso
2006, Edgard Jamhour
O protocolo SNMPv2
2006, Edgard Jamhour
SetRequest
idem
GetBulkRequest
equivale a um GetNextRequest múltiplo
2006, Edgard Jamhour
resposta ResponsePDU sem conteúdo.
2006, Edgard Jamhour
o=ppgia.pucpr.br
<host>
Nome (ou endereço IP) do servidor LDAP (por exemplo, ldap.ppgia.pucpr.br ou 200.17.98.174).
<porta>
Porta do servidor LDAP. Se nenhuma porta for especificada, assume-se a porta padrão 389.
<base_dn>
<atributos>
<escopo>
<filtro>
2006, Edgard Jamhour
ldap://servidorLDAP/ou=RSD,o=ppgia.pucpr.br
ldap://servidorLDAP /ou=RSD,o=ppgia.pucpr.br?
ldap://servidorLDAP / ou=RSD,o=ppgia.pucpr.br?
email?sub?(cn=Alc*)
Solicita todos os emails da PUCPR pertencentes a usuários que tem o nome começando por Alc.
2006, Edgard Jamhour
Procura todas as pessoas em ppgia.pucpr.br:
Servidor: ldap://icaro.ppgia.pucpr.br/
Servidor: ldap://icaro.ppgia.pucpr.br/
Escopo: sub
Servidor: ldap://icaro.ppgia.pucpr.br/
Escopo: sub
Exemplo de Consulta:
Filtro: title=Professor)
Filtro: (title=Prof*)
2006, Edgard Jamhour
(objectClass=carro)
( &(objectClass=carro)
( |(marca=Golf)(marca=Audi)))
c) especifica carros da marca Golf ou Vectra mas não importados.
( &(objectClass=carro)
Servidores LDAP Stand Alone e Referral
Quando um servidor LDAP não conhece a resposta a uma pergunta do cliente, e pelo indicar um outro servidor LDAP (chamado referral) ou uma lista de servidores LDAP para o cliente consultar.
CLIENTE LDAP
Sintaxe
O objeto referral deve ter um link para o servidor para o qual se deseja redirecionar as consultas:
No exemplo anterior:
A) Um objeto vazio do tipo unidade organizacional:
ou=Curitiba
organizatinalunit
refferal
ref = ldap://hal2002.pucpr.br/ou=Curitiba,ou=Exemplo,
Exemplo
O arquivo LDIF que cria um entrada de referral é ilustrado abaixo:
dn: uid=ACalsavara, ou=people, dc=pucpr,dc=br
objectclass: top
objectclass: person
objectclass: organizationalperson
objectclass: inetOrgPerson
objectclass: referral
2006, Edgard Jamhour