2006, Edgard Jamhour
Gerência de Redes (SNMP)
Serviços de Diretório (LDAP)
Policy Based Networking (PBNM)
Edgard JamhourMauro FonsecaCarlos Maziero
2006, Edgard Jamhour
Definições básicas
• Gerência de redes:– conjunto 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
Áreas funcionais de gerência
• Configuração
• Falha
• Desempenho
• Segurança
• Contabilidade
2006, Edgard Jamhour
Gerência de configuração• Inventory: conjunto de dispositivos na rede, do
software e hardware presente nesses dispositivose sua informação estática.
• Configuration: mapa indicando as conexões entre componentes do inventário.
• Provisioning: parâmetros operacionais modificáveisque especificam o comportamento de cada dispositivo.
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 uma capacidade de tráfego mínima na rede.
• Assegurar que os dispositivos podemtratar 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
• Controle de acesso ao sistema
• Monitorar uso dos recursos
• Criar, manter e examinar “log-files”
• Muito importante em sistemas abertos
• Essencial em hosts conectados à Internet
2006, Edgard Jamhour
Gerência de contabilização
• Ter uma idéia clara do uso dos recursos– cobrar pelos serviços utilizados– planejar crescimento da rede– detectar abusos no uso dos recursos
• Informação de contabilização deve ter acesso restrito.
2006, Edgard Jamhour
Modelo de gerência
• Baseado em uma estrutura cliente/servidor
– agente: age como servidor de informações de gerência
– gerente: consulta os agentespara obter informações
2006, Edgard Jamhour
Servidor: Agente
• Agente: Network Management Entity
– executa um processo agente– interage com os dispositivos físicos– coleta, mantém e oferece informações
de gerência– responde a pedidos de informação
e comandos
2006, Edgard Jamhour
Cliente: Gerente
• Gerente: Network Management Application
– consultas e ações sobre os agentes– executa um software de gerência– interage com o operador do sistema
2006, Edgard Jamhour
O ciclo de gerência
• As atividades de gerência compõe um ciclo:
• Coleta de dados: monitoração (automática)dos recursos gerenciados.
• Diagnóstico: tratamento e análise dos dadoscoletados para delinear o problema.
• Ação: controle sobre os recursos gerenciadospara corrigir o problema.
2006, Edgard Jamhour
Transferência da informação
• Dados fluem dos agentes ao gerentes
• Pooling:• interações tipo “pedido/resposta”• iniciadas pelo gerente, solicitando dados• podem ser específicas ou genéricas
• Event reporting:• indicações de ocorrência de eventos importantes• iniciadas pelo agente• podem ser periódicas ou ocasionais
2006, Edgard Jamhour
Uma arquitetura de gerência
Management protocol Managementagent
Managed objects
Management entity
eventsoperations
MIB
Managementdatabase
requests
responses
notifications
Managementapplication
2006, Edgard Jamhour
Ferramentas de gerência
• Arquitetura de gerência OSI
• Gerência usando SNMP
• Gerência via Web
• Gerência com objetos CORBA
2006, Edgard Jamhour
Protocolos de gerência
• SNMP• Simple Network Management Protocol• Criado pela IETF em 1988• Projetado para monitorar redes simples• Dominante em redes TCP/IP
• CMIP• Common Management Information Protocol• Proposto pela ISO no início dos anos 90• Controle (complexo) de redes complexas• Muito presente em redes de telefonia
2006, Edgard Jamhour
Informações de gerência
• MIB• Management Information Base• Dados mantidos pelos elementos gerenciados• Informação com estrutura hierárquica
• SMI• Structure of Management Information• Define notações, formatos, tipos, nomes, ...• Usa como base a notação formal ASN.1
2006, Edgard Jamhour
MIB-II - Estrutura geral
iso(1)
org(3)
dod(6)
internet(1)
directory(1)
mgmt(2)
mib-2(1)
system(1)
interfaces(1)
tcp(6)
udp(7)
Object ID is 1.3.6.1.2.1.7
udpInDatagramsudpNoPortsudpInErrorsudpOutDatagrams
2006, Edgard Jamhour
SNMP
• Voltado à monitoração de redes simples• Pode ser embutido em hardware simples• Muito usado em redes TCP/IP
• Comandos e tipos de dados fixos• Poucos tipos de mensagens• estrutura bastante simples
• Usa UDP/IP• baixo nível de tráfego de gerência• protocolo de transporte sem conexão• não confiável (perda de pacotes)
• Comandos e respostas assíncronas
2006, Edgard Jamhour
Extensões de SNMP
• RMON - Remote Network Monitoring• extensão da MIB-II para gerência• Facilidades para monitoração e coleta• “Remendo” sobre SNMP e MIB
• RMON-2• Coleta de informações mais abrangente
• SNMP-V2• estrutura de segurança melhorada• comunicação entre gerentes (método inform)• MIB e SMI aumentadas: novos tipos de dados
2006, Edgard Jamhour
Estrutura de gerência OSIArquitetura em camadas de serviços:
• SMFA• System Management Functional Areas: faltas, contabilidade,
configuração, desempenho, segurança• SMF
• System Management Functions• CMISE
• CMIS: Common Management Information Services• CMIP: Common Management Information Protocol
2006, Edgard Jamhour
Arquitetura OSI
security configurationfault performanceaccounting
Specific Management Functional Areas
relationship Event-reportstate alarmobject
System Management Functions
log
security
access accountingworkload test summarization
action event-reportset createget
CMISE Services
delete
Managed node
CMIP
2006, Edgard Jamhour
O que é SNMP ?
• Padrão para gerência na Internet– simples de implementar– amplamente difundido
• Composto de:– protocolo para trocas de mensagens– padrões para estruturar a informação
• Evolutivo: SNMPv2, SNMPv3, RMON, ...
2006, Edgard Jamhour
Estrutura geral do sistema
Request
Response
Protocol
Managementinformation
SNMP agent
MIB
SNMP manager
MIB
2006, Edgard Jamhour
Informações de gerência
• Definidas através da SMI– Structure of Management Information– Define como criar a MIB
• Endereçada através de MIBs– Management Information Bases– Uma MIB é uma coleção de objetos– Cada objeto representa uma parâmetro de gerência
• Transportadas através do SNMP– Single Network Management Protocol
2006, Edgard Jamhour
Árvore MIB
• Object IDentifier (OID)
- Exemple .1.3.6.1.2.1.1
- iso(1) org(3) dod(6) internet(1) mgmt(2)
mib-2(1) system(1)
Notas:- .1.3.6.1 ~100% present.- 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)
2006, Edgard Jamhour
A MIB versão 2
1.3.6.1. iso.org.dod.internet
1. directory2. mgmt3. experimental4. private5. security6. snmpV27. mail
1. enterprises
1. system2. interfaces3. address translation4. ip5. icmp6. tcp7. udp8. egp9. oim10. transmission11. snmp
1. mib-2
objeto1.3.6.1.2.1.1
2006, Edgard Jamhour
Objeto MIB
• Definido em ANS.1
- OBJECT-TYPE- Descreve o objeto MIB.- Object IDentifier (OID).
- SYNTAX- Define o tipo de informação
representada pelo objeto MIB.- ACCESS
- READ-ONLY, READ-WRITE.- STATUS
- Estado do objeto em relação a comunidade SNMP.
- DESCRIPTION- Significado da informação representada
pelo objeto MIB.
Standard MIB Object:
sysUpTime OBJECT-TYPESYNTAX Time-Ticks
ACCESS read-onlySTATUS mandatoryDESCRIPTION
“Time since the network management portion of the system was last re-initialised.
::= {system 3}
2006, Edgard Jamhour
ASN.1
Abstract Syntax Notation One
• Linguagem de descrição de dados da ISO• Definição em formato texto não ambíguo• Permite definir modelos de dados• Formato independente de máquina• Implementação dos dados não é considerada
2006, Edgard Jamhour
Campo SYNTAX
• Define o conteúdo do objeto– INTEGER: inteiros de 32 bits– INTEGER (1..100): sub-tipo inteiro– OCTET STRING: string de bytes– 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
Sub-tipagem
INTEGERINTEGER (-127..128)INTEGER (1..10)INTEGER (0 | 2 | 4 | 6 | 8)INTEGER (0..2 | 20)INTEGER (-127..-1 | 1..128)INTEGER (1)
2006, Edgard Jamhour
Enumeração usando inteirosBoolean ::= INTEGER { true (1), false (2)}
Alarm-level ::= INTEGER { critical (1), major (2), minor (3), warning (4), informational (10) }
2006, Edgard Jamhour
Campo ACCESS
• Define a acessibilidade do objeto
• Valores possíveis em SNMPv1:
– read-only– read-write– write-only– not-accessible
2006, Edgard Jamhour
Campo STATUS
• Situação do objeto na MIB– Mandatory
• Devem ser implementados por todos os agentes• Valores contidos devem ser válidos
– Optional• Pode ou não ser implementado
– Deprecated• Foi substituido por novo objeto, mas ainda é valido• Se tornará obsoleto mais tarde
– Obsolete• Não deve ser considerado
2006, Edgard Jamhour
Valores escalares e vetoriais
• Valores escalares:• uma só instância por variável• OID deve ser completado por “.0”• Exemplo: ....mib-2.ip.ipForwarding: 1.3.6.1.2.1.4.1.0
• Valores vetoriais:• para construir listas e tabelas• usam os construtores SEQUENCE e SEQUENCE OF• Convenção de tabela: xxxTable• Convenção de linha na tabela: xxxEntry
2006, Edgard Jamhour
Tabela de conexões TCPtcpConnTable OBJECT-TYPE SYNTAX SEQUENCE OF TcpConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION “A table containing TCP connection-specific information.” ::= {tcp 13}
2006, Edgard Jamhour
Uma conexão TCP na tabelatcpConnEntry OBJECT-TYPE SYNTAX TcpConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION “Information about a particular
current TCP connection. ...” INDEX {
tcpConnLocalAddress, tcpConnLocalPort, tcpConnRemAddress, tcpConnRemPort
} ::= {tcpConnTable 1}
2006, Edgard Jamhour
Uma conexão TCP na tabela (2)TcpConnEntry ::= SEQUENCE { tcpConnState INTEGER, tcpConnLocalAddress IpAddress, tcpConnLocalPort INTEGER (0..65535), tcpConnRemAddress IpAddress, tcpConnRemPort INTEGER (0..65535), }
2006, Edgard Jamhour
BER
• Basic Encoding Rules
• Codificação dos dados para transferência
• Usa formato TLV: Type-Length-Value• Type: tipo ASN.1 e infos complementares• Length: tamanho da representação dos dados• Value: string de octetos contendo o valor do dado
• A estrutura de codificação é recursiva
2006, Edgard Jamhour
A arquitetura SNMP
management application
SNMP managerUDP
IPlink
SNMP agentUDP
IPlink
MIB objects
SNMP messages
management actions
resourcesManagement
system
Managed system
2006, Edgard Jamhour
O protocolo SNMP
• Veicula informações de gerência• transporte de valores das MIBs
• Interações sem conexão• Mensagens em UDP/IP• portas 161 e 162• pacotes de tamanho variável
• Mensagens auto-contidas• formato Type - Length - Value
2006, Edgard Jamhour
Histórico do SNMP
• 1989: SNMP v1
• 1992: Remote Monitoring - RMON
• 1993: SNMP v2
• 1996: SNMP v2c (Community Security)
• 1996: MIB RMON v2
• 1998: SNMP v3 (User Security Model)
2006, Edgard Jamhour
Operações básicas SNMP
• GET• GET-NEXT
• gerente busca informações dos agentes• acessos em leitura às MIBs
• SET• gerente modifica informações dos agentes• acessos em escrita às MIBs
• TRAP• agentes enviam informações não solicitadas aos gerentes,
informado eventos importantes
2006, Edgard Jamhour
Exemplo de uso
man
ager
Response (‘João’)SNMP Agent MIB
pessoa.nome = Joãopessoa.idade = 35pessoa.sexo = masc
Get (Nome)
Response (35)
GetNext (Nome)
Response (Erro)
Set (sexo, fem)
2006, Edgard Jamhour
Restrições das operações
• Permitem somente inspeçãoe/ou alteração de variáveis
• A estrutura da MIB não podeser alterada pelas operações
• Somente podem ser acessadosvalores escalares em cada operação
2006, Edgard Jamhour
Limitações de SNMP• Falta de segurança
– esquema de autenticação trivial– limitações no uso do método SET
• Ineficiência– esquema de eventos limitado e fixo– operação baseada em pooling– comandos transportam poucos dados
• Falta de funções específicas– MIB com estrutura fixa– Falta de comandos de controle– Falta de comunicação entre gerenciadores
• Não confiável– baseado em UDP/IP– traps sem reconhecimento
2006, Edgard Jamhour
Modelo de segurança SNMP• Modelo mais comum: SNMP V2c• Baseado no conceito de comunidade• Uma comunidade define:
• método para autenticar acesso (senha)• visibilidade da MIB• privilégios de acesso à MIB
• Cada dispositivo implementauma ou mais comunidades
• Comunidade default: “public”
2006, Edgard Jamhour
Exemplo de comunidades
public
ensino
admin
network
2006, Edgard Jamhour
Uma mensagem SNMP
• Conteúdo codificado via BER• Geralmente limitada a < 484 bytes
msg length
protocol version
community string
PDU header
PDUbody
2 bytes
1 byte
até 128 bytes
preâmbulo
PDU SNMP
2006, Edgard Jamhour
Estrutura das PDUs SNMP
preamble
msg length
protocol version
community string
PDU type
PDU length
Request ID
Error Status
Error Index
Variable bindings
Variable bindings
msg length
protocol version
community string
PDU type
PDU length
Enterprises OID
Agent IP address
Standard trap type
Variable bindings
Specific trap type
Time stamp
Variable bindings
Get & Set Trap
SNMPheader
SNMPbody
2006, Edgard Jamhour
Preâmbulo e cabeçalho
• Versão0: SNMPv1, 1: SNMPv2, ...
• Tipo de PDU0: getRequest1: getNextRequest2: getResponse3: setRequest4: trap
• Request ID• valor numérico usado para casar pedidos e respostas
2006, Edgard Jamhour
Códigos de erro
• Error Status:0: noError: sucesso na operação1: tooBig: resposta muito grande para enviar2: noSuchName: OID não suportado pelo agente3: badValue: valor incorreto para operação set4: readOnly: tentativa de escrita inválida5: genErr: erro não relacionado ao protocolo
• Error index:• indica qual variável listada na PDU causou o erro.
2006, Edgard Jamhour
Conteúdo das mensagens
varbind lengthvariable OIDvariable typevariable value
varbind lengthvariable OIDvariable typevariable value
...
var list size 41
231.3.6.1.2.1.1.2.021.3.6.1.4.1.311.1.1.3.2
141.3.6.1.2.1.7.4.065250
2006, Edgard Jamhour
A operação GetNext
• Busca próximo elemento na MIB– Usa ordem lexicográfica
• 1.3.6.1.2.1.1.4• 1.3.6.1.2.1.1.4.0• 1.3.6.1.2.1.1.5.0• ...
• Serve para:• passear na MIB (descoberta da estrutura)• buscar dados em tabelas
2006, Edgard Jamhour
Exemplo de passeio na MIB• 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• snmpgetnext -v1 localhost -c public -O n .1.3.6.1.2.1.1.2.0
– .1.3.6.1.2.1.1.3.0 = Timeticks: (523160) 1:27:11.60• snmpget -v1 localhost -c public .1.3.6.1.2.1.1.3.0
– SNMPv2-MIB::sysUpTime.0 = Timeticks: (527855) 1:27:58.55
2006, Edgard Jamhour
Percurso seqüencial
myVar1.1
myVar1.2
myVar1.3
myVar1.4
myVar2.1
myVar2.2
myVar2.3
myVar2.4
myVar3.1
myVar3.2
myVar3.3
myVar3.4
coluna 1 coluna 2 coluna 3
linha 1
linha 2
linha 3
linha 4
1
2
3
4
6
5
7
8
9
10
11
12
13
2006, Edgard Jamhour
Traps em SNMP
• Mensagens enviadas pelo agente
• Não são respostas a pedidos
• Representam eventos anormais
• Classificam-se em:• genéricos: presentes na MIB padrão• específicos: definidos na MIB “enterprises”
2006, Edgard Jamhour
Traps genéricos
• coldStart:• o dispositivo foi ligado• configuração local pode ter sido alterada• informa ao gerente sobre sua existência
• warmStart:• o dispositivo foi reinicializado• configuração local não foi alterada
• linkDown:• link ou porta de comunicação ligada ao nó falhou
2006, Edgard Jamhour
Traps genéricos (2)
• linkUp:• link ou porta local foi (re)ativada.
• authenticationFailure:• o dispositivo recebeu msg SNMP não autorizada• comunidade não reconhecida• número IP de gerente inválido
• egpNeighborLoss:• Exterior Gateway Protocol falhou no nó• 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– Especificação DNS (Nomes de Domínio)
• Serviços de diretório são utilizados para oferecer um repositório "logicamente" centralizado com as informações de gerenciamento.
2006, Edgard Jamhour
Modelos de Serviço de Diretório• 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
• Sistema de Banco de Dados Distribuído– Mecanismos de Procura Flexíveis
• Linguagem de consulta orientada a objetos– Espaço de Nomes Homogêneo
• Mesma notação para qualquer objeto.– Serviço padronizado e aberto.
• Definido por normas CCITT
2006, Edgard Jamhour
Modelo Funcional X500(Banco de Dados Distribuído)
DUA
DUA
DSA
DSA
DSA
DAP
DAPDSP
DSP DSP
DiretórioX500
DUA(Directory User Agent)
DSA(Directory System Agent)
DAP(Directory Access Protocol)
DSP(Directory ServiceProtocol).
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
Serviço de Diretório X500
SERVIÇO DE DIRETÓRIO
prenome=edgard?email?
Login+senha
Login
senha
OK
Políticas IPsec para o IP de destino
200.10.0.1?
Bypass.
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: Edgardsobrenome: Jamhouremail: [email protected]
Atributos
Entrada
ObjetoAtributo 1 (tipo, valores)Atributo 2 (tipo, valores)....Atributo n (tipo,valores)
2006, Edgard Jamhour
Objetos do X500
atributo 1: tipoatributo 2: tipoatributo 3: tipo…atributo N: tipo
estrutura genéricade uma classe
nome: stringsobrenome: stringnc: stringpassord: stringemail: stringnascimento: datauid: string
objectclass: Pessoanome: Albertsobrenome: Einsteinnc: aeinsteinpassord: 1B5A324AB3email: [email protected]: 01/08/1908
objectclass: Pessoanome: Issacsobrenome: Newtonnc: inewtonpassord: 2A2A324ZC3email: [email protected]: 03/09/1803
classe Pessoa
objetos
RDN: Relative Distiguished Name
2006, Edgard Jamhour
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• atributos opcionais: description, seeAlso,
telephoneNumber, userPassword– objectclass: organizationalperson (derivada de person)
• atributos opcionais: facsimileTelephoneNumber, postOfficeBox, postalAddress , postalCode, preferredDeliveryMethod , etc.
– objectclass: inetOrgPerson• atributos opcionais: businessCategory, departmentNumber,
employeeType, employeeNumber, homePhone, homePostalAddress, initials, manager, mobile, pager, preferredLanguage, mail, o, roomNumber, secretary, uid
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
Esquema de Nomes X500RDN=DN =
Raiz()
País(P)
Organização(O)
Unidade Organizacional(UO)
Pessoa(NC)
RDN: P=br
Classe(RDN)
RDN: P=fr
RDN: O=pucprRDN: O=cefetpr
RDN: UO=ppgia
RDN: UO=ccet
RDN: NC=inewton RDN: NC=aeinstein
DN: P=br
DN: O=pucpr, P=br
RDN: UO=ppgia, O=pucpr, P=br
DN: Distiguished NameDN: Distiguished Name
DN: NC=aeinstein, UO=ppgia, O=pucpr, P=brDN: NC=aeinstein, UO=ppgia, O=pucpr, 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): – Nome Característico Relativo– identifica o objeto através de um atributo
• cn=ejamhour
• Distinguished Name (DN): – 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
LDAP(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 1779 - Modelo de Nomes– RFC 1823 - API– RFC 1959 - formato URL– RFC 2044 - conjunto de caracteres internacionais UTF-8
2006, Edgard Jamhour
LDAP
• 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
Servidor LDAP:
• A arquitetura LDAP segue o padrão cliente-servidor.
• 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.
2006, Edgard Jamhour
Servidor LDAP como Ponte para X500
clienteLDAP
servidorLDAP
servidorX500
servidorX500
LDAPDAP
DAP
2006, Edgard Jamhour
Stand-alone LDAP
clienteLDAP
servidorLDAP
LDAP
servidorLDAP
LDAP
2006, Edgard Jamhour
Sintaxe de uma Consulta LDAP• ldap[s]://<host>:<porta>/<base_dn>?<atributos>?<escopo>?<filtro>
• ldap://ppgia.pucpr.br/o=pucpr,c=br?email?sub?(sn=Joa*)
o=ufpr
o=pucpr
c=br c=brc=br
escopo sub escopo one escopo base
o=ufpr
o=pucpro=ufpr
o=pucpr
2006, Edgard Jamhour
Directory Enable Networks
• Criação:– Criado pelo DMTF(Distribute Engineering Task Force)
• 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
CIM: Common Information Model
Core model
Application System Network Physical Device
Network Foundation
QoS model
IPsec model
BGP model
Bridge model
VLAN model
2006, Edgard Jamhour
CIM: Common Information Model X500_Top
ManagedSystemElement (CIM)
Configuration (CIM)
Application (CIM)
Protocol (CIM)
Service (CIM)
Group (X500)
Person (X500)
Organization (X500)
Profile (DEN)
Policy (DEN)
2006, Edgard Jamhour
Directory Enable Networks
DIRETÓRIODIRETÓRIO
DIRECTORY ENABLE
NETWORKS
ESQUEMAe
INTERFACES
Futuras Aplicações
que usam Diretório
Futuras Aplicações
de Gerenciamento
Aplicações de Gerenciamento
Existentes
Protocolos de Gerenciamento Existentes
hubs switches roteadores computadores
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
PCIM• 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– Policy Framework QoS Information Model– Information Model for Describing Network Device QoS Datapath
Mechanisms– Policy Core Information Model Extensions
2006, Edgard Jamhour
O que é o PCIM?
• PCIM é um modelo genérico:– 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íticaRegra 1
Regra 2
Regra N…
Condição 1 Condição N…
Ação Açaõ N…
2006, Edgard Jamhour
Principais Classes do PCIM
2006, Edgard Jamhour
PCIMe
2006, Edgard Jamhour
Condições
2006, Edgard Jamhour
Mapeamento de Políticas no Dispositivo
2006, Edgard Jamhour
QPIM: Policy Quality of Service Information Model
2006, Edgard Jamhour
Policy Based Networking
• PDP: Policy Decision Point• PEP: Policy Enforcement Point
aplicativo
dispositivo
PEPPEP
PEPPEP
PDPPDP
request
decision
LDAPrequest
decision
COPS
COPS
PolicyRepository
Base de Estados
Policy ManagementTool
2006, Edgard Jamhour
COPS
• Common Open Policy Services Protocol– RFC 2748:
• The COPS (Common Open Policy Service) Protocol (Janeiro 2000)
– RFC 2749:• COPS usage for RSVP (Janeiro 2000)
– RFC 2753: • A Framework for Policy-based Admission Control
(Janeiro 2000)– RFC 3084:
• COPS Usage for Policy Provisioning (COPS-PR) (Março 2001)
2006, Edgard Jamhour
COPS• Protocolo simples, extensível, baseado em TCP.
– 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
Open Client TypeConnection
Client Connection Accept
2006, Edgard Jamhour
Princípio
• 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
Modelo Básico• LPDP: Local Policy Decision Point
– 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
PEP
LPDP
PDPCOPS
2006, Edgard Jamhour
Funcionamento
• 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:
• atualmente 1– Flags:
• Apenas o flag “Solicited Message Flag” está definido– Op Code:
• Mensagem COPS– Client Type:
• Identifica o tipo de cliente (para receber a política)– Message Length
• Tamanha da mensagem em bytes (inclui o cabeçalho)
version flags op code Client Type
1 byte 1 byte 2 bytes
Message Length
2006, Edgard Jamhour
Op Code
• 1 = Request (REQ) • 2 = Decision (DEC) • 3 = Report State (RPT) • 4 = Delete Request State (DRQ) • 5 = Synchronize State Req (SSQ) • 6 = Client-Open (OPN) • 7 = Client-Accept (CAT) • 8 = Client-Close (CC) • 9 = Keep-Alive (KA) • 10= Synchronize Complete (SSC)
2006, Edgard Jamhour
Objetos COPS• C-Num
– 1 = Handle– 2 = Context– 3 = In Interface– 4 = Out Interface– 5 = Reason code– 6 = Decision– 7 = LPDP Decision– 8 = Error– 9 = Client Specific Info– 10 = Keep-Alive Timer– 11 = PEP Identification– 12 = Report Type– 13 = PDP Redirect Address– 14 = Last PDP Address– 15 = Accounting Timer– 16 = Message Integrity
Length C-Num C-Type
2 byte 1 byte
Object Contents
1 byte
• C-Type– Depende de C-Num– Indica o subtipo ou versão da
informação transportada pelo objeto.
2006, Edgard Jamhour
Escalabilidade
Repositório de Políticas
PDP
PEP
PDP
PEP
PEPPEP PEP
PEP
COPS COPSPEP
2006, Edgard Jamhour
Modelos de PDP/PEP
• O COPs pode ser utilizado em duas estratégias diferentes:– 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
Modelo Outsourcing
• Cada evento no PEP dispara uma consulta ao PDP.
2006, Edgard Jamhour
Modelo Provisioning
• O PEP tem autonomia para tomar decisões localmente.
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 ClassesPRI - 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
B
B
1
2006, Edgard Jamhour
Representação OID
2006, Edgard Jamhour
Exemplo: CIM X QPIM X PIB
2006, Edgard Jamhour
Princípios do Modelo Provisioning
2006, Edgard Jamhour
Feedback do uso de políticas
• 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
ANEXOS A
RMON
2006, Edgard Jamhour
Monitoração de redes
• SNMP e MIBs em agentes só permitem analisar valores isolados (nos agentes)
• Como medir o tráfego na rede ?
tráfego = 137 kbpstráfego = 55 kbps
tráfego = ?
2006, Edgard Jamhour
Monitores de rede
• Ouvem a rede continuamente• Podem ouvir várias redes• Não interferem nas redes monitoradas
monitor
2006, Edgard Jamhour
Informações monitoradas
• Todos os pacotes são ouvidos• Podem ser aplicadas filtragens
• tipo de pacote, protocolo, origem, destino, ...
• Produção de dados estatísticos• distribuição por tipo de pacote• percentual de colisões• taxas de transferência
• Armazenagem de pacotes para análise
2006, Edgard Jamhour
Monitorando múltiplas redes
• Um monitor para cada sub-rede• Monitores devem ser acessíveis pelo gerente
gerente
monitores
router
2006, Edgard Jamhour
Definindo um monitor
• Definir a informação a armazenar• significado dos dados• tipos dos dados• estrutura geral da informação
• Definir formas de acesso• leitura/escrita• configuração• relatar eventos
• Implementar• como um dispositivo dedicado• serviço adicionado a um elemento da rede
2006, Edgard Jamhour
RMON
• RMON: Remote Monitoring
• Norma para monitores de redes• Define uma (imensa) MIB• Dados são acessados via SNMP• Efetua a monitoração contínua de redes• Versões:
• RMON v1: monitoração MAC (ethernet, token ring, ...)• RMON v2: monitora camadas mais elevadas
• Monitor: agente RMON ou sonda RMON
2006, Edgard Jamhour
Objetivos de RMON
• Operação off-line
• autônoma (independe do gerente)• diminui o tráfego de rede
• Monitoração pró-ativa
• diagnósticos contínuos• monitoração de desempenho• pode gerar alarmes enviados ao gerente
2006, Edgard Jamhour
Objetivos de RMON (2)
• Informações de valor agregado• dados estatísticos• informações históricas
• Acesso por múltiplos gerentes• diferentes objetivos de gerência• tolerância a falhas
• Compatibilidade com padrões• informação na forma de MIBs• acesso via protocolo SNMP
2006, Edgard Jamhour
Controle da sonda RMON
• Monitor é acessado remotamente para:• configuração geral• invocação de ações
• Configuração:• indicar tipo e forma dos dados a coletar• manipulação de tabelas de controle
• Ações:• leitura e escrita de valores• invocação de “value triggered commands”
2006, Edgard Jamhour
Organização da MIB RMON
• Cada grupo consiste de:• uma ou mais tabelas de dados (read-only)• uma ou mais tabelas de controle (read-write)
• Tabelas de dados:• valores coletados da rede e processados
• Tabelas de controle• indicam que dados devem ser coletados• cada linha representa uma função de coleta
• Podem ser fundidas em uma só tabela
2006, Edgard Jamhour
Múltiplos gerentes
• Vários gerentes podem acessar uma sonda• acessos concorrentes podem saturar a sonda• um gerente pode monopolizar a sonda
• Para o controle de múltiplos gerentes:• 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
• Complexo e pouco claro (Stallings 96 !)• 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:
– valid– create request– under creation– invalid
• Demais informações
2006, Edgard Jamhour
Indexação de tabelas
xyzControlIndex xyzControlParameter xyzControlOwner xyzControlStatus
1 5 Monitor Valid(1)
2 26 Manager alpha Valid(1)
3 19 Manager gamma Valid(1)
XyzDataControlIndex XyzDataIndex xyzDataValue1 1 462 1 962 2 852 3 772 4 272 5 923 1 863 2 26
xyzControlTable
xyzDataTable
2006, Edgard Jamhour
Inserção de linhas
• Através do método SNMP set:
set [index, (tipo, valor), (tipo, valor), ...]
• erro badValue em caso de dado inválidoou impossibilidade de criação
• tratamento de conflitos em acessos simultâneos torna-se necessário
2006, Edgard Jamhour
Passos para a criação de linhas
• Seqüência de passos para criar linhas: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
rmon (16)
host (4)
statistics (1)
history (2)
alarm (3)
hostTopN (5)
matrix (6)
filter (7)
capture (8)
event (9)
tokenRing (10)
mib-2
2006, Edgard Jamhour
Grupo statistics
• Uma tabela para cada sub-rede monitorada• sub-rede referenciada por sua interface
• Informações mais importantes:• carga da sub-rede• saúde da sub-rede (erros, colisões)• pacotes fora de tamanho (undersize, oversize)
• Mais detalhado que mib-2.interfaces
2006, Edgard Jamhour
Grupo history
• Amostragens do tráfego nas interfacesao longo do tempo de operação
• Cada linha da tabela de controledefine um conjunto de amostras
• Cada linha da tabela de dadoscorresponde a uma amostra
• Defaults:• cada amostra dura 1800 segundos• as 50 últimas amostras são mantidas
2006, Edgard Jamhour
Outros grupos
• hosts• estatísticas sobre hosts na sub-rede
• hostTopN• estatísticas sobre hosts segundo algum critério• armazena dados sobre os N primeiros hosts
em termos de tráfego, erros, tipos de pacotes, etc.
• matrix• armazenar dados sobre tráfego entre pares de hosts
• tokenRing• suporte a informações de redes token-ring
2006, Edgard Jamhour
Alarmes
• Alarmes são registrados na MIB• gerados pelo grupo alarm• tratados pelo grupo event• podem ser enviados ao gerente via traps
• Cada entrada da tabela contém:• OID da variável a ser monitorada• intervalo de amostragem• parâmetros de limiar (threshold)
• Um exemplo:• + de 500 erros CRC nos últimos 5 minutos
2006, Edgard Jamhour
O ciclo de histerese
• Pequenas flutuações no valor monitorado poderiam gerar alarmes
• 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 ultrapassar o limite superior• valor descer abaixo do limite inferior• de forma alternada !
2006, Edgard Jamhour
O ciclo de histerese
estado doalarme
alarmesuperior
alarmeinferior
valor monitorado
disparo doalarme superior
disparo doalarme inferior
2006, Edgard Jamhour
Geração de alarmes
• Alarme é gerado quando:• valor maior que o limiar superior
(risingThreshold)• valor menor que o limiar inferior
(fallingThreshold)
valor
lim sup
lim inf
tempo
disparos
2006, Edgard Jamhour
O grupo filter
• Permite regras de filtragem dos pacotes– dois tipos de filtros:
• data filter: padrões de bits nos pacotes• status filter: status dos pacotes (válido, erro de CRC, ...)
– filtros podem ser combinados• operações lógicas AND, OR, seqüências
• Os pacotes filtrados:• constituem um fluxo chamado canal (channel)• podem disparar eventos• podem ser armazenados no grupo capture
2006, Edgard Jamhour
Considerações práticas
• Uso correto da sonda e do gerente• evitar uso abusivo de alarmes e eventos• uso inteligente de filtros e captura• risco de saturar a sonda e a rede• poder de processamento da sonda é limitada
• Problemas de interoperabilidade• discrepância entre MIBs de fabricantes distintos• muitas funções são parcialmente implementadas
2006, Edgard Jamhour
RMON v2• RMON v1:
• limitado à camada MAC• ethernet e token-ring• poucos recursos de configuração
• RMON v2:• suporte às demais camadas (3 a 7)• monitoração de protocolos de aplicação• visibilidade de tráfego vindo de fora (IP)• tabelas replicadas para cada protocolo
• Outras inovações• grupo MIB de configuração da sonda
2006, Edgard Jamhour
ANEXOS B
SNMPv2
2006, Edgard Jamhour
SNMPv2
• Definido em 1993 (RFC)• Suporte flexível:
– gerência centralizada– gerência distribuída
• Modificações mais significativas:– estrutura de informação (SMI)– interações “gerente a gerente”– operações do protocolo
2006, Edgard Jamhour
SMI em SNMPv2
• Super-conjunto da SMI em SNMPv1• Especificação e documentação mais elaboradas
dos objetos da MIB• Novos conceitos:
– definições de novos objetos– tabelas conceituais– novas definições de notificações– módulos de informação
2006, Edgard Jamhour
Definições de objetos
• Melhor definição de OBJECT-TYPE• Novos tipos de dados:
– Counter32– Unsigned64
• Remoção de ambigüidades de SNMPv1• Novas interpretações de alguns tipos:
– 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:– not accessible– accessible for notify– read only– read-write– read-create (tabelas conceituais)
2006, Edgard Jamhour
Cláusula STATUS
• Novos status:– current– deprecated– obsolete
• Desaparecem:– mandatory– optional
2006, Edgard Jamhour
Tabelas
• Duas categorias de tabelas:– estrutura fixa– estrutura alterável
• Criação/deleção de linhas– operações pelo gerente, via SNMP– extremamente complexo e controverso– segue o modelo adotado em RMON
2006, Edgard Jamhour
O protocolo SNMPv2
• Três formas de interação– manager to agent, request/response– agent to manager, unconfirmed– manager to manager, request/response
• o último é definido em SNMPv2
2006, Edgard Jamhour
PDUs SNMPv2
• GetRequest, GetNextRequest– similar à de SNMPv1– resposta não é mais atômica
• SetRequest– idem
• GetBulkRequest– busca de grandes blocos de dados– equivale a um GetNextRequest múltiplo
2006, Edgard Jamhour
PDUs SNMPv2
• InformRequest– comunicação entre gerentes– enviado pelo gerente que deseja enviar a informação– resposta ResponsePDU sem conteúdo.
• ReportPDU– não utilizada (abandonada nas RFCs)
2006, Edgard Jamhour
ANEXOS C
LDAP
2006, Edgard Jamhour
Raizes de Árvore no Servidor
o=ppgia.pucpr.br
ServidorServidor LDAPLDAP
389389
ou=Groups
ou=People
o=NetscapeRoot
Raiz do diretório
2006, Edgard Jamhour
Exemplo
o=ppgia.pucpr.br
ou=Funcionarios
cn=acalsavara
ou=Grupos
cn=ejamhour ou=analistas
Objectclass = organization
Objectclass=organizationalUnit
Objectclass =organizationalUnit
Objectclass =groupOfNames
ou=Exemplo
Objectclass =inetOrgPerson
2006, Edgard Jamhour
Parâmetros do LDAP• <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>
– dn do ponto de início da procura. • <atributos>
– indica quais atributos do objeto serão retornados.• <escopo>
– define como efetuar a procura.• <filtro>
– define os critérios da procura.
2006, Edgard Jamhour
Exemplos de Consulta LDAP em URL
• ldap://servidorLDAP/ou=RSD,o=ppgia.pucpr.br• Solicita o todos os campos do objeto RSD
• ldap://servidorLDAP /ou=RSD,o=ppgia.pucpr.br?endereço
• Solicita apenas o campo endereço do objeto PUCPR.
• 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
Comandos para localizar o usuário• Procura todas as pessoas em ppgia.pucpr.br:
– Servidor: ldap://icaro.ppgia.pucpr.br/– Search Root: o=ppgia.pucpr.br– Escopo: sub– Filtro: (objectclass=Person)
• Procura as pessoas em sua_Unidade– Servidor: ldap://icaro.ppgia.pucpr.br/– Search Root: ou=sua_Unidade,o=ppgia.pucpr.br– Escopo: sub– Filtro: (objectclass=Person)
• Procura as pessoas em Curitiba– Servidor: ldap://icaro.ppgia.pucpr.br/– Search Root: ou=Curitiba,ou=sua_Unidade,o=ppgia.pucpr.br– Escopo: sub– Filtro: (objectclass=Person)
2006, Edgard Jamhour
Procura por Atributos
• Atributos disponíveis para Person:– telephoneNumber, seeAlso, userPassword,
description• Atributos para organizationalperson:
– title, street, ou, postalAddress, postalCode• Exemplo de Consulta:
– Filtro: title=Professor)– Filtro: (title=Prof*)
2006, Edgard Jamhour
Filtros LDAP
• a) Especifica objetos do tipo carro
– (objectClass=carro)• b) especifica carros da marca Golf ou Vectra
– ( &(objectClass=carro) ( |(marca=Golf)(marca=Audi)))
• c) especifica carros da marca Golf ou Vectra mas não importados.– ( &(objectClass=carro)
(|(marca=Golf)(marca=Audi)) (!(origem=importado)))
2006, Edgard Jamhour
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
LDAP
LDAP
Servidor LDAP
Servidor LDAP
LDAP
Servidor LDAP
2006, Edgard Jamhour
Diretório Distribuído: Smart Referral
o=ppgia.pucpr.br
ou=Exemplo
ou=Curitiba
cn=George Bush
ou=São Paulo
cn=Bill Gates
ou=Persons
ou=Persons
icaro.ppgia.pucpr.br
hal2002.ppgia.pucpr.br
ou=Curitiba
ref=xxxx
o=ppgia.pucpr.br
ou=Exemplo
Objectclass = referral
2006, Edgard Jamhour
Sintaxe
• O objeto referral deve ter um link para o servidor para o qual se deseja redirecionar as consultas:
• No exemplo anterior:– No servidor icaro deve ser criado
• A) Um objeto vazio do tipo unidade organizacional:– ou=Curitiba– Este objeto deve ser derivado de:
» organizatinalunit» refferal
• B) O atributo refferal permite redirecionar as consultas:
– ref = ldap://hal2002.pucpr.br/ou=Curitiba,ou=Exemplo,o=ppgia.pucpr.br
2006, Edgard Jamhour
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– cn: Alcides Calsavara– sn: Calsavara– uid: ACalsavara– ref: ldap://10.32.1.253/cn=Alcides%20Calsavara,ou=people,
l=europe,dc=pucpr,dc=br
2006, Edgard Jamhour
Diretório Distribuído: Smart Referral
o=ppgia.pucpr.br
ou=Exemplo
ou=Curitiba
cn=George Bushou=São Paulo
cn=Bill Gates
ou=Persons
ou=Persons
icaro.ppgia.pucpr.br
hal2002.ppgia.pucpr.br
ou=São Paulo
ref=xxxx
o=ppgia.pucpr.br
ou=Exemplo
Objectclass = referral
ou=Curitiba
ref=yyyy
Recommended
