Guia de configuração de segurança no EMC Celerra · 1 de 92 Índice Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 de 92

ÍndiceIntrodução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Requisitos do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3Avisos e alertas de cuidado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3Opções da interface do usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3Terminologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4Informações relacionadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7Considerações de planejamento para a identificação de usuários administrativos e autenticação . . . . . . . . . . . . . . . . . . .16Considerações de planejamento para o uso de um servidor externo de diretórios na identificação e autenticação de usuários administrativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19Considerações de planejamento para acesso administrativo baseado em funções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21Considerações de planejamento para segurança de senha. . . . . . .25Considerações de planejamento para PKI (Public Key Infrastructure, infra-estrutura de chave pública). . . . . . . . . . . . . . . .26

Configurando o uso de um servidor externo de diretórios na identificação e autenticação de usuários administrativos . . . . . . . . . . .29Configurando a política de senhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

Definição interativa da política de senhas . . . . . . . . . . . . . . . . . . . . .32Definição das configurações específicas da política de senhas . . .33Configuração do período de validade de senhas . . . . . . . . . . . . . . .33

Configurando o tempo limite de sessão . . . . . . . . . . . . . . . . . . . . . . . . . .34Pré-requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34Alteração do valor do tempo limite de sessão. . . . . . . . . . . . . . . . . .34

Personalizando um banner de log-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36Criando uma MOTD (Message Of The Day, mensagem do dia) . . . . . . .37Protegendo tokens de sessão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38Configurando a criptografia e autenticação de rede usando o protocolo SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

Usando HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39Usando SSL com LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39Alteração do protocolo SSL padrão . . . . . . . . . . . . . . . . . . . . . . . . . .40Alteração do conjunto de codificações padrão do SSL . . . . . . . . . .40Pós-requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

Configurando a PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42

Guia de configuração de segurança no EMC Celerra

Nº da peça 300-008-085Rev A02

Versão 5.6Outubro de 2008

Guia de configuração de segurança no EMC CelerraVersão 5.6 2 de 92 Guia de configuração de segurança no EMC CelerraVersão 5.6 2 de 92

Criando o certificado fornecido pela persona. . . . . . . . . . . . . . . . . . 42Obtendo certificados de CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Usando a Control Station como CA . . . . . . . . . . . . . . . . . . . . . . . . . . 42Geração de uma solicitação por conjunto e certificado de chaves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Envio da solicitação de certificado à CA . . . . . . . . . . . . . . . . . . . . . . 46Importação de um certificado assinado pela CA . . . . . . . . . . . . . . . 47Listagem dos certificados de CA disponíveis. . . . . . . . . . . . . . . . . . 50Aquisição de um certificado de CA . . . . . . . . . . . . . . . . . . . . . . . . . . 50Importação de um certificado de CA . . . . . . . . . . . . . . . . . . . . . . . . . 53Geração de um novo certificado de CA da Control Station . . . . . . . 53Exibição do certificado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Distribuição do certificado de CA da Control Station . . . . . . . . . . . 56

Gerenciando a PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Exibição das propriedades de um conjunto e certificado de chaves. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Verificação de conjuntos de chaves vencidos . . . . . . . . . . . . . . . . . 58Eliminação de conjuntos de chaves. . . . . . . . . . . . . . . . . . . . . . . . . . 59Exibição de propriedades do certificado de CA . . . . . . . . . . . . . . . . 60Verificação de certificados de CA vencidos . . . . . . . . . . . . . . . . . . . 60Exclusão de certificados de CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Solução de problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Onde obter ajuda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62EMC E-Lab Interoperability Navigator . . . . . . . . . . . . . . . . . . . . . . . . 62Solução de problemas de conexão da Control Station com um servidor de diretórios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Solução de problemas em contas locais de usuários administrativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Solução de problemas em contas de usuários administrativos mapeadas em domínio . . . . . . . . . . . . . . . . . . . . . . . 65Solução de problemas na importação de certificados . . . . . . . . . . . 65Mensagens de erro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Programas de treinamento para o cliente . . . . . . . . . . . . . . . . . . . . . 67

Apêndice A: Conjuntos de codificações do SSL aceitos . . . . . . . . . . . . 68Apêndice B: Noções básicas da configuração do servidor de diretórios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Usuários e computadores do Active Directory . . . . . . . . . . . . . . . . . 70Ldap Admin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Índice remissivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

3 de 92Versão 5.6Guia de configuração de segurança no EMC Celerra

IntroduçãoO EMC® Celerra® Network Server implementa uma variedade de recursos de segurança para controlar o acesso de usuários e redes, monitorar o acesso e uso do sistema e comportar a transmissão de dados criptografados. Esses recursos de segurança são implementados na Control Station e em Data Movers. Esse documento explica por que, quando e como usar esses recursos de segurança. Noções básicas desses recursos são importantes para entender a segurança do Celerra. A seção "Conceitos" na página 7 oferece mais detalhes.

Este documento faz parte da documentação do Celerra Network Server e é dirigido a administradores responsáveis pela configuração e operação geral do Celerra.

Requisitos do sistemaA Tabela 1 na página 3 descreve as configurações de software, hardware, rede e armazenamento do Celerra Network Server exigidas para o uso dos recursos de segurança conforme descrito neste documento.

Avisos e alertas de cuidado Se alguma dessas informações não estiver clara, entre em contato com o Representante de Atendimento ao Cliente EMC para obter ajuda.

Se as senhas padrão não forem alteradas durante a instalação, é preciso fazê-lo o quanto antes.

Opções da interface do usuárioO Celerra Network Server oferece flexibilidade no gerenciamento de armazenamento em rede com base em suas preferências de ambiente e interface de suporte. Este documento descreve como configurar e gerenciar os recursos de segurança usando a CLI (Command Line Interface, interface de linha de comando). Também é possível realizar muitas destas tarefas usando o Celerra Manager.

Para obter mais informações sobre o gerenciamento do Celerra:

◆ Learning about EMC Celerra no CD EMC Celerra Network Server Documentation

◆ Ajuda on-line do Celerra Manager

Installing Celerra Management Applications inclui instruções sobre a execução do Celerra Manager.

Tabela 1 Requisitos de segurança do sistema

Software Celerra Network Server versão 5.6

Hardware Não há requisitos específicos de hardware

Rede Não há requisitos específicos de rede

Armazenamento Não há requisitos específicos de armazenamento

../../mergedprojects/Concepts/Celerra_Product_Line.htm

../../../wwhelp/wwhimpl/java/html/wwhelp.htm

../../../wwhelp/wwhimpl/java/html/wwhelp.htm

../InstallationManagement/index.htm

Guia de configuração de segurança no EMC Celerra4 de 92 Versão 5.6

TerminologiaO EMC Celerra Glossary fornece a lista completa da terminologia do Celerra.

ACE (Access Control Entry, entrada de controle de acesso): Em um ambiente Microsoft Windows, um elemento de uma ACL (Access Control List, lista de controle de acesso). Esse elemento define os direitos de acesso a um arquivo por um usuário ou grupo.

ACL (Access Control List, lista de controle de acesso): Lista de ACEs que traz informações sobre o acesso a um objeto, concedido a usuários e grupos.

API XML: Interface de gerenciamento e monitoração remota de um Celerra Network Server. A interface usa mensagens formatadas em XML. Além disso, é indiferente quanto à linguagem de programação. autenticação: Processo para verificar a identidade de um usuário que tenta acessar um recurso ou objeto, como um arquivo ou um diretório.

CA (Certificate Authority, autoridade de certificação): Entidade terceirizada confiável que assina digitalmente certificados de chaves públicas.

Certificado de autoridade de certificação: Associação assinada digitalmente entre uma identidade (uma autoridade de certificação) e uma chave pública a ser usada pelo host para verificar assinaturas digitais em certificados de chave pública.

certificado digital: ID eletrônico emitido por uma autoridade de certificação que estabelece as credenciais de um usuário. Ele contém a identidade (um nome de host) do usuário, um número de série, datas de validade, uma cópia da chave pública do detentor do certificado (usada em mensagens criptografadas e assinaturas digitais) e a assinatura digital de uma autoridade emissora de certificados, de forma que um destinatário possa verificar que o certificado é válido.

CLI (Command Line Interface, interface de linha de comando): Interface para a inserção de comandos via Control Station para realizar tarefas que incluem gerenciar e configurar bancos de dados e os Data Movers e monitorar estatísticas de componentes do gabinete do Celerra.

CIFS (Common Internet File System, sistema comum de arquivos da Internet): Um protocolo de compartilhamento de arquivos baseado no Microsoft SMB (Server Message Block, bloco de mensagens de servidor). Permite que os usuários compartilhem sistemas de arquivos pela Internet e por intranets.

Control Station: Componente de hardware e software do Celerra Network Server que gerencia o sistema e fornece uma interface de usuário administrativo para todos os componentes do Celerra.

Data Mover: Um componente de gabinete do Celerra Network Server que executa seu próprio sistema operacional e que recupera arquivos de um dispositivo de armazenamento, disponibilizando-os a um cliente de rede.

diretório baseado em LDAP: Um servidor de diretório que oferece acesso por LDAP. Exemplos de servidores de diretórios baseados em LDAP incluem o OpenLDAP ou iPlanet (também conhecido como Sun Java System e Sun ONE).

HTTP (Hypertext Transfer Protocol, protocolo de transferência de hipertexto): Protocolo de comunicação usado na conexão com servidores na World Wide Web.

HTTPS (Hypertext Transfer Protocol Secure, protocolo seguro de transferência de hipertexto): HTTP sobre SSL. Todo o tráfego de rede entre o cliente e o sistema do servidor é criptografado. Além disso, há a opção de verificar identidades de

../../mergedprojects/Glossary/index.htm


servidor e cliente. As identidades dos servidores são normalmente verificadas, já as dos clientes, não.

Kerberos: Mecanismo criptográfico de autenticação, integridade de dados e privacidade de dados que é usado para codificar informações de autenticação. O Kerberos coexiste com NTLM (serviços Netlogon) e, usando criptografia com chave secreta, fornece autenticação para aplicativos de cliente/servidor.

Lightweight Directory Access Protocol (LDAP): Protocolo de acesso a informações padrão do setor, executado diretamente em TCP/IP. É o principal protocolo de acesso para o Active Directory e para servidores de diretórios baseados em LDAP. O LDAP versão 3 é definido por um conjunto de documentos de padrões propostos na IETF (Internet Engineering Task Force, força-tarefa de engenharia na Internet) RFC 2251.

NFS (Network File System, sistema de arquivos de rede): Sistema de arquivos distribuído que fornece acesso transparente a sistemas de arquivos remotos. O NFS permite que todos os sistemas da rede compartilhem uma cópia individual de um diretório.

OpenLDAP: Implementação em código aberto de um serviço de diretório com base em LDAP.

persona: Meio de fornecer uma identidade para um Data Mover, seja como servidor ou como cliente, por meio de uma chave privada e um certificado associado de chave pública. Cada persona pode manter até dois conjuntos de chaves (atual e próxima) para permitir a geração de novas chaves e certificados antes da expiração do certificado atual.

PKI (Public Key Infrastructure, infra-estrutura de chave pública): Meio de gerenciar chaves privadas e os certificados de chaves públicas associados para uso em criptografia de chaves públicas.

política de acesso: Política que define quais métodos de controle de acesso (permissões NFS e/ou ACLs do Windows) são aplicados quando um usuário acessa um arquivo em um sistema Celerra dentro de um ambiente configurado para fornecer acesso multiprotocolo para determinados sistemas de arquivos. A política de acesso é configurada com o comando server_mount; também determina quais ações um usuário pode realizar em um arquivo ou diretório.

servidor de diretórios: Servidor que armazena e organiza informações sobre os usuários e recursos de uma rede de computadores, além de permitir que os administradores gerenciem o acesso dos usuários aos recursos. X.500 é o serviço de diretório aberto mais conhecido. Serviços patenteados de diretório incluem o Active Directory da Microsoft.

SNMP (Simple Network Management Protocol, protocolo simples de gerenciamento de rede): Método usado para comunicar informações de gerenciamento entre as estações de gerenciamento da rede e os agentes nos elementos da rede.

SSL (Secure Socket Layer, camada de soquete seguro): Protocolo de segurança que fornece criptografia e autenticação. Ele criptografa dados e fornece autenticação de mensagens e servidores. Também aceita autenticação de clientes, se necessário, pelo servidor.

TLS (Transport Layer Security, segurança de camada de transporte): Protocolo sucessor do SSL para a autenticação e criptografia da comunicação geral sobre redes TCP/IP. TLS versão 1 equivale aproximadamente à SSL versão 3.

X.509: Padrão usado amplamente para a definição de certificados digitais.


Informações relacionadas Para obter informações específicas com relação aos recursos e às funcionalidades descritas nesse documento:

◆ Manual de referência de comandos do EMC Celerra Network Server

◆ Páginas de manual do Celerra on-line

◆ EMC Celerra Network Server Parameters Guide

◆ Installing EMC Celerra Management Applications

◆ Configurando o CIFS no EMC Celerra

◆ Configuring NFS on EMC Celerra

◆ Gerenciando o EMC Celerra em ambiente multiprotocolo

◆ Configuring EMC Celerra Naming Services

◆ Usando o EMC Celerra FileMover

◆

◆ Nota técnica Auditing in the Celerra Control Station

◆ Nota técnica Celerra Network Server on the Enterprise Network

O CD EMC Celerra Network Server Documentation fornecido com o Celerra e também disponível no Powerlink®, oferece o conjunto completo de publicações para clientes do EMC Celerra. Depois de efetuar log-in no Powerlink, vá para Suporte > Documentação técnica e conselhos > Documentação de hardware/ plataformas > Celerra Network Server. Nessa página, clique em Adicionar a Bookmarks. A seção de favoritos no site do Powerlink apresenta um link que leva diretamente a essa página.

Para informações gerais sobre o LDAP, consulte:

◆ RFC 2307, An Approach for Using LDAP as a Network Information Service

Para informações específicas sobre a configuração do LDAP e SSL do Active Directory, consulte:

◆ Artigo da Base de conhecimentos da Microsoft Como habilitar LDAP sobre SSL com uma autoridade de certificação de terceiros (ID 321051)

Para informações específicas sobre configuração do OpenLDAP e SSL, consulte o site da OpenLDAP (www.openldap.org). Se você está usando um servidor de diretórios baseado em LDAP diferente, que não seja do Active Directory, consulte a documentação do fornecedor para obter informações sobre a configuração do LDAP e SSL.

Configurando eventos e notificações do EMC Celerra

../CommandReference/index.htm

../Parameters/index.htm

../InstallationManagement/index.htm

../ConfWindows/index.htm

../CgNFS/index.htm

../ConfWinMulti/index.htm

../FileMover/index.htm

../EventsandNotifications/index.htm

http://powerlink.emc.com


Conceitos Sólidos recursos de segurança do sistema são cada vez mais necessários para manter a conformidade com as novas normas e assegurar maior proteção contra ataques ao sistema. O Celerra implementa uma série de recursos, tanto na Control Station quanto no Data Mover para proteger sua infra-estrutura, controle de acesso e dados.

Na Control Station:

◆ Para dar segurança a sua infra-estrutura, o Celerra proporciona uma série de recursos que podem ser usados para restringir a operação da Control Station. A Tabela 2 na página 8 descreve esses recursos.

◆ Para proteger os recursos do sistema contra acesso não autorizado, o Celerra utiliza uma rígida identificação e autenticação de usuários administrativos, acesso administrativo baseado em funções e políticas de senhas definidas pelo cliente. A Tabela 3 na página 10 descreve esses recursos.

◆ Para dar suporte à transmissão de dados criptografados, o Celerra aceita o protocolo de segurança SSL. A Tabela 4 na página 12 descreve esse recurso.

Sobre Data Movers:

◆ Para dar segurança a sua infra-estrutura, o Celerra proporciona uma série de recursos que podem ser usados para restringir a operação dos Data Movers. A Tabela 5 na página 13 descreve esses recursos.

◆ Para proteger a transmissão de dados criptografados, o Celerra aceita o protocolo de segurança SSL e o gerenciamento de certificados de chave pública para determinados protocolos. A Tabela 6 na página 15 descreve esses recursos.

Embora muitos destes recursos requeiram configuração e gerenciamento diretos, outros têm sido apresentados como alterações básicas na operação do software. Por exemplo, começando com o Celerra versão 5.6, as seguintes alterações foram implementadas:

◆ A segurança entre um usuário e o Celerra Manager, e entre duas Control Stations, foi aumentada com a alteração da checksum ¯ de MD5 para SHA1 ¯ usada para assinar o token da sessão (cookie). O SHA1 produz um valor de hash de 160 bits, diferente do MD5, que produz apenas um valor de hash de 128 bits.

◆ Serviços e portas dinâmicas sem necessidade foram removidos do sistema operacional Linux da Control Station.

Observação: Muitos dos recursos de segurança do Celerra são descritos em outras partes da biblioteca de documentação, conforme visto nas tabelas gerais. Por isso, este documento só inclui detalhes de configuração para um subconjunto dos recursos de segurança disponíveis.


Tabela 2 Visão geral dos recursos da Control Station para proteger a infra-estrutura (página 1 de 2)

Recurso O que faz Restrições Mais informações

Tempo limite de sessão O Celerra aplica um tempo limite para sessões administrativas acessadas tanto pelos shells da Control Station quanto pelo Celerra Manager. As seções expiram depois de um período específico de inatividade.

O tempo limite de sessão vem habilitado por padrão.

Você deve ser usuário root para alterar as propriedades da Control Station.

Para gerenciar o tempo limite de sessão de shell, use o comando /nas/sbin/ nas_config -sessiontimeout. A seção "Configurando o tempo limite de sessão" na página 34 descreve como configurar esse recurso.

Para gerenciar o tempo limite de sessão do Celerra Manager, selecione Celerras > [Celerra_name] > Security > Celerra Manager. Você encontrará a descrição desse recurso na ajuda on-line do Celerra Manager.

Banner de log-in e MOTD (Message Of The Day, mensagem do dia)

Um banner de log-in e uma MOTD proporcionam ao administrador uma maneira de se comunicar com os usuários administrativos do Celerra.

O mesmo banner de log-in e MOTD são vistos na interface de linha de comando e no Celerra Manager.


Para configurar o banner e a MOTD via Celerra Manager, selecione Celerras > [Celerra_name] > Control Station Properties. Você encontrará a descrição desse recurso na ajuda on-line do Celerra Manager.

Para configurar o banner e a MOTD via CLI, use um editor de texto para editar os arquivos /etc/issue ou /etc/motd. As seções "Personalizando um banner de log-in" na página 36 e "Criando uma MOTD (Message Of The Day, mensagem do dia)" na página 37 descrevem como configurar esses recursos.

Serviços de rede gerenciamento

No Celerra Manager, é possível listar o estado atual de alguns serviços de rede (e protocolos e portas de comunicação associados) na Control Station. Você pode habilitar, desabilitar e monitorar esses serviços. Para melhorar a segurança do Celerra, é necessário restringir o acesso a esse sistema, desabilitando os serviços de rede que não são usados em seu ambiente.


Para gerenciar os serviços de rede por meio do Celerra Manager, selecione Celerras > [Celerra_name] > Security > Network Services. Você encontrará a descrição desse recurso na ajuda on-line do Celerra Manager.


Tokens de sessão (cookies)

O Celerra usa o SHA1 para gerar checksums com o objetivo de proteger os tokens de sessão (cookies) usados na identificação dos usuários depois do log-in. Para aumentar a segurança, é possível alterar o valor secreto SHA1 padrão usado para gerar os checksums.

Ao alterar esse valor, os tokens de sessão (cookies) existentes se tornam inválidos e os usuários atuais do Celerra Manager precisam refazer o log-in.


Para gerenciar tokens de sessão (cookies), edite o arquivo /nas/http/conf/secret.txt. A seção "Protegendo tokens de sessão" na página 38 descreve como configurar esse recurso.

Auditoria O Celerra oferece arquivos de configuração e comandos para capturar atividades de gerenciamento iniciadas na Control Station, especificamente relacionadas ao acesso a arquivos de sistema principais e dados do usuário final.


A nota técnica Fazendo auditoria na Control Station do Celerra, disponível no EMC Powerlink, traz informações específicas sobre como implementar auditorias.

Tabela 2 Visão geral dos recursos da Control Station para proteger a infra-estrutura (página 2 de 2)



Tabela 3 Visão geral dos recursos da Control Station para controle de acesso (página 1 de 2)


Identificação e autenticação de usuários administrativos

Contas exclusivas de usuários administrativos permitem um gerenciamento mais seguro do Celerra. As contas de usuários administrativos podem ser tanto uma conta de usuário local quanto uma conta de usuário local mapeada em uma conta de domínio.

Contas de usuários administrativos mapeadas por domínio exigem que o Celerra tenha acesso a um servidor de diretórios baseado em LDAP. Isso pode significar a configuração do acesso a um servidor de diretórios do Active Directory ou de outro como o OpenLDAP ou iPlanet.

Usuários administrativos só podem ser gerenciados por meio do Celerra Manager.

Os comandos do Linux disponíveis na CLI (useradd, userdel, usermod, groupadd, groupmod e groupdel) não aceitam o acesso administrativo baseado em funções e não devem mais ser usados para gerenciar contas de usuários e grupos.

Você deve ser usuário root, ou administrativo com privilégios de root ou de operador de segurança, para criar uma nova conta de usuário administrativo.

"Considerações de planejamento para a identificação de usuários administrativos e autenticação" na página 16 apresenta os conceitos por trás desse recurso.

Para criar e gerenciar usuários administrativos com o Celerra Manager, selecione Celerras > [Celerra_name] > Security > Administrators. Você encontrará a descrição desse recurso na ajuda on-line do Celerra Manager.

"Considerações de planejamento para o uso de um servidor externo de diretórios na identificação e autenticação de usuários administrativos" na página 19 descreve como o Celerra interage com um servidor de diretórios baseado em LDAP e "Configurando o uso de um servidor externo de diretórios na identificação e autenticação de usuários administrativos" na página 29 descreve como configurar esse recurso.

Acesso administrativo baseado em funções

Esse recurso permite atribuir privilégios de usuário administrativo que sejam apropriados a suas responsabilidades. Conseqüentemente, ele simplifica a interface para usuários administrativos do Celerra Manager, limitando as operações que eles podem realizar ao mesmo tempo que protege o sistema e os dados do cliente contra operações realizadas por pessoas sem autorização para tanto.

Uma função define os privilégios (leitura, modificação ou controle total) que podem ser empregados em determinado objeto do Celerra. O Celerra oferece funções predefinidas e personalizadas.

No Celerra 5.6, as funções não são aceitas para usuários administrativos usando a CLI.

Você deve ser usuário root, ou administrativo com privilégios de root ou de operador de segurança, para atribuir funções.

"Considerações de planejamento para acesso administrativo baseado em funções" na página 21 apresenta os conceitos por trás desse recurso.

Para criar e gerenciar o acesso administrativo baseado em funções com o Celerra Manager, selecione Celerras > [Celerra_name] > Security > Administrators. Você encontrará a descrição desse recurso na ajuda on-line do Celerra Manager.


Política de qualidade de senha

Senhas fortes são um elemento importante de uma estratégia de segurança. O Celerra impõe várias exigências para garantir uma política de qualidade de senha.

Esse recurso define as exigências de complexidade de senha para todos os usuários administrativos locais. Esse recurso não diz respeito a usuários mapeados por domínio, cujas senhas são governadas por políticas internas do domínio.

É preciso ser usuário root para definir a política de qualidade de senha.

A página "Considerações de planejamento para segurança de senha" na página 25 descreve os elementos de uma política de qualidade de senhas.

Para definir a política de qualidade de senhas, use o comando /nas/sbin/ nas_config -password. A seção "Configurando a política de senhas" na página 32 descreve como configurar esse recurso.

Tabela 3 Visão geral dos recursos da Control Station para controle de acesso (página 2 de 2)



Tabela 4 Visão geral dos recursos da Control Station para proteger dados


Certificados SSL (X.509) para o Celerra Manager

O Celerra Manager usa criptografia e autenticação SSL para proteger a conexão entre o navegador da Web do usuário e o servidor da Web do Celerra, Apache. Certificados digitais, cuja autenticidade é verificada por uma CA, são usados pelo SSL para identificar e autenticar o servidor.

A partir da versão 5.6, o Celerra gera automaticamente o certificado da CA e um novo certificado Apache assinado pelo primeiro durante a instalação do sistema ou um upgrade de software, caso esses certificados ainda não existam.

No caso do Celerra Manager, a Control Station serve como uma CA de função limitada, assinando o certificado fornecido pelo servidor da Web Apache.

Se você alterar o nome de host do Celerra, será preciso gerar novamente a CA da Control Station e os certificados do Apache. Ao gerar um novo certificado de CA, um certificado correspondente do Apache também será gerado.

Se você alterar apenas o nome de domínio ou o endereço IP do Celerra, basta gerar novamente o certificado de servidor da Web Apache.

Uma vez gerados os certificados, qualquer navegador ou sistema que use os certificados anteriores precisarão instalar os novos.


A seção Installing EMC Celerra Management Applications descreve como configurar esse recurso.

O white paper do Celerra Using Celerra Manager in Your Web Browsing Environment: Browser and Security Settings to Improve Your Experience, disponível no EMC Powerlink, proporciona informações sobre como e por que instalar os certificados.

Criptografia e autenticação de rede usando LDAP sobre SSL

O Celerra aceita criptografia e autenticação de SSL na conexão LDAP entre a Control Station e um servidor de diretórios baseado em LDAP.

"Considerações de planejamento para o uso de um servidor externo de diretórios na identificação e autenticação de usuários administrativos" na página 19 descreve como o Celerra interage com um servidor de diretórios baseado em LDAP e "Configurando o uso de um servidor externo de diretórios na identificação e autenticação de usuários administrativos" na página 29 descreve como configurar esse recurso.


Tabela 5 Visão geral dos recursos do Data Mover para proteger a infra-estrutura (página 1 de 2)


Serviços de rede gerenciamento

No Celerra Manager, é possível listar o estado atual de alguns serviços de rede (e protocolos e portas de comunicação associados) nos Data Movers. Você pode habilitar, desabilitar e monitorar esses serviços. Para melhorar a segurança do Celerra, é necessário restringir o acesso a esse sistema, desabilitando os serviços de rede que não são usados em seu ambiente como, por exemplo, o FTP.

Alguns serviços executados no Data Mover exigem reinicialização para que as alterações tenham efeito.

Para gerenciar os serviços de rede por meio do Celerra Manager, selecione Celerras > [Celerra_name] > Security > Network Services. Você encontrará a descrição desse recurso na ajuda on-line do Celerra Manager.

Autenticação CIFS de Kerberos

Já que o Kerberos é agora o método de autenticação recomendado em ambientes Windows, é possível desabilitar a autenticação NTLM. (Por padrão, o Celerra permite tanto a autenticação Kerberos quanto NTLM.)

Para configurar o modo de autenticação CIFS do servidor, use apenas o comando server_cifs <movername> -add compname=<comp_name>, domain=<full_domain_name>, authentication=kerberos.

A página server_cifs descreve como ajustar esta configuração. A seção Configurando o CIFS no EMC Celerra descreve a autenticação.

Configurações de segurança NFS

Embora seja geralmente considerado um protocolo vulnerável de compartilhamento de arquivos, é possível tornar o NFS mais seguro usando as seguintes configurações:

• Definir acesso somente leitura para alguns (ou todos) hosts

• Limitar o acesso à raiz para sistemas e sub-redes específicos

Além disso, se uma autenticação sólida for exigida, é possível configurar o Secure NFS, que usa o Kerberos.

A seção Configuring NFS on EMC Celerra descreve como configurar essas configurações.


Políticas de acesso O conjunto de modos personalizados de acesso do Celerra permite escolher a melhor interação possível entre os acessos NFS e CIFS para seu ambiente.

É possível selecionar como os atributos de segurança serão mantidos e o tipo de interação entre usuários do NFS e CIFS, incluindo:

• Separado• CIFS dominante• NFS dominante• Igual • Misto (usado para

alcançar um alto nível de sincronização entre os dois protocolos)

A política de acesso misto é necessária quando se usa NFSv4.

A seção Gerenciando o EMC Celerra em ambiente multiprotocolo descreve como configurar esse recurso.

Credenciais estilo Windows (NT) para usuários UNIX

O Celerra permite criar uma credencial comum no estilo Windows (NT). Os usuários têm assim as mesmas credenciais, independente de seu protocolo de acesso aos arquivos, oferecendo um controle de acesso mais consistente.

A seção Gerenciando o EMC Celerra em ambiente multiprotocolo descreve como configurar esse recurso.

Gerenciamento de SNMP

A string da comunidade SNMP oferece a base para a segurança no SNMP. O nome padrão da comunidade é o famoso public. Esse nome deve ser alterado para impedir acesso indesejado ao Celerra.

Use o comando server_snmp -community para atribuir um novo valor para a comunidade de um agente SNMP do servidor em um Data Mover.

O SNMP é usado na comunicação entre a Control Station e o Data Mover; desabilitá-lo pode interferir em algumas funções. Por exemplo, o comando server_netstat não funcionará.

Tabela 5 Visão geral dos recursos do Data Mover para proteger a infra-estrutura (página 2 de 2)


A seção Configurando eventos e notificações do EMC Celerra descreve como configurar esse recurso.


Tabela 6 Visão geral dos recursos do Data Mover para proteger dados


Criptografia e autenticação de rede via SSL

O Celerra aceita criptografia e autenticação SSL para conexões LDAP e HTTP entre o Data Mover e vários serviços externos.

SSL em conexões do Data Mover só pode ser configurado e gerenciado via CLI.

A seção "Configurando a criptografia e autenticação de rede usando o protocolo SSL" na página 39 descreve como configurar os parâmetros associados a esse recurso.

As seções Configuring EMC Celerra Naming Services e Usando o EMC Celerra FileMover descrevem como configurar e gerenciar o SSL para esses recursos.

Certificados de chave pública

A estrutura PKI oferece sistemas de banco de dados e gerenciamento de software para servir de suporte ao uso de certificados digitais para as conexões LDAP e HTTP de Data Mover em que o SSL está habilitado.

A estrutura PKI do Celerra só aceita certificados de chave pública X.509.

"Considerações de planejamento para PKI (Public Key Infrastructure, infra-estrutura de chave pública)" na página 26 apresenta os conceitos por trás desse recurso.

As seções "Configurando a PKI" na página 42 e "Gerenciando a PKI" na página 57 descrevem como configurar e gerenciar esse recurso usando a CLI.

Para configurar e gerenciar o PKI com o Celerra Manager, selecione > [Celerra_name] > Security > Public Key Certificates. Você encontrará a descrição na ajuda on-line do Celerra Manager.


Considerações de planejamento para a identificação de usuários administrativos e autenticação A criação de usuários administrativos exclusivos, cada um com privilégios apropriados a suas responsabilidades, simplifica o gerenciamento do Celerra limitando as operações que eles podem realizar e protegendo o sistema e os dados dos clientes contra operações de usuários administrativos não autorizados.

O recurso de administradores permite definir:

◆ Usuários administrativos

◆ Grupos para organizar os usuários

◆ Funções para associar aos grupos

◆ Níveis de privilégio que definem funções para o acesso e o controle de todos os objetos do Celerra

O recurso para administradores também permite o uso de um servidor externo de diretórios como um repositório central de contas de usuários para um gerenciamento simplificado.

Observação: Usuários administrativos podem acessar o sistema do Celerra através da CLI, do Celerra Manager ou da API XML. No Celerra 5.6, a associação de privilégios específicos — também denominados funções — a esses usuários é permitida somente para usuários administrativos que acessam o Celerra através do Celerra Manager e da API XML, e para usuários administrativos que emitem comandos da CLI. Se um usuário administrativo específico precisar de um controle de acesso baseado em funções, não forneça a ele acesso ao Celerra por meio da CLI.

Observação: Esse recurso é diferente do suporte de controle de acesso da Control Station, gerenciado por meio do comando nas_acl.

Usuários administrativosO Celerra oferece duas contas padrão para usuários administrativos: root e nasadmin. É possível criar usuários administrativos adicionais, cada qual com privilégios apropriados a suas responsabilidades.

Usuários administrativos padrão

É possível utilizar as contas padrão de usuários administrativos (root e nasadmin) para fazer o log-in na CLI e no Celerra Manager. O usuário root pode acessar e controlar todos os objetos e ações do Celerra. O usuário nasadmin tem o mesmo acesso e controle que o root, com algumas exceções.

Na CLI, é necessário ser o usuário root para executar certos comandos ou opções de comando. Esses comandos geralmente exigem expertise, têm potencial


destrutivo ou são usados apenas em circunstâncias especiais. A Tabela 7 na página 17 relaciona esses comandos.

No Celerra Manager, é necessário ser usuário root para configurar e modificar certos recursos. A Tabela 8 na página 17 relaciona esses recursos.

A seção "Considerações de planejamento para acesso administrativo baseado em funções" na página 21 apresenta mais informações sobre como o root e o nasadmin são impactados pelo acesso baseado em funções.

Tabela 7 Comandos que só podem ser executados pelo root

Diretório Comandos

/nas/bin fs_ckpt fs_timefinder nas_acl nas_cel nas_devicegroup nas_fs nas_server nas_storage nas_volume

/nas/sbin cs_standby nas_ca_certificate nas_config nas_connecthome nas_halt nas_mview nas_rdf server_user

Tabela 8 Recursos do Celerra Manager que só podem ser gerenciados pelo root

Recurso Acessado de

Propriedades da Control Station Celerra Home > Control Station Properties

Tempo limite de sessão Security > Celerra Manager

Serviços de rede Security > Network Services

Connect Home Support > Connect Home

(alguns comandos Celerra e Linux) CLI Commands

Assistente de instalação do Celerra Wizards

Senha entre as estações de controle Replications > Celerra Network Servers


Criando novos usuários administrativos

É possível criar novas contas de usuários administrativos em Administrators > Users > página New User, no Celerra Manager. A ajuda on-line do Celerra Manager oferece uma explicação detalhada desse procedimento.

Observação: No Celerra 5.6, não é mais possível criar contas de usuários administrativos por meio da CLI. Os comandos Linux usados previamente na CLI para gerenciar contas de grupos e usuários (useradd, userdel, usermod, groupadd, groupmod e groupdel) não aceitam o acesso administrativo baseado em funções do Celerra e não poderão mais configurar entradas reconhecidas pelo Celerra.

Para criar uma nova conta de usuário administrativo, é preciso ser um usuário root ou administrativo com privilégios de root ou security_operator. A seção "Considerações de planejamento para acesso administrativo baseado em funções" na página 21 descreve como os privilégios são atribuídos e usados.

Contas de usuários locais versus contas de usuários mapeadas por domínios

As contas de usuários administrativos podem ser tanto uma conta de usuário local quanto uma conta de usuário local mapeada em uma conta de domínio. Uma conta de usuário mapeada por domínio usa o nome de usuário e a senha especificados no servidor de domínio. Esse tipo de conta de usuário é sempre autenticado no servidor de domínio. Se o servidor de domínio não estiver disponível, o usuário não poderá fazer log-in.

O mapeamento de usuários em contas de usuários locais fornece o mecanismo para verificar se um usuário autenticado por um servidor externo de diretórios tem acesso autorizado ao Celerra, e se esse usuário tem as credenciais locais necessárias, incluindo um UID (Unit ID, ID de unidade), para realizar tarefas.

Com o Celerra, é possível criar automaticamente contas de usuários locais para usuários do domínio. Quando habilitada, uma conta de usuário local é estabelecida para qualquer usuário mapeado por domínio capaz de ser autenticado com êxito no servidor de domínio e que pertença a pelo menos um grupo reconhecido pelo sistema Celerra. O nome da conta local do usuário do domínio será igual ao nome de usuário do domínio, acrescentando-se o nome do domínio (por exemplo, joe.corp). Caso esse nome já exista localmente, será acrescentado um número ao nome de usuário (por exemplo, joe1.corp). O número acrescentado é o próximo da seqüência que não esteja em uso.

Especificando o acesso de usuários administrativos ao Celerra

Os usuários administrativos podem ter acesso ao sistema Celerra por meio da CLI do shell da Control Station, do Celerra Manager ou da API XML.

Observação: A API XML permite que você crie sua própria GUI (Graphical User Interface, interface gráfica do usuário) ou outro tipo de interface de gerenciamento. Como o Celerra Manager e determinados comandos da CLI, a API XML utiliza a interface de software do Celerra entre a camada de apresentação da interface do usuário da Web e o código principal da Control Station, chamada de camada do dispositivo ou APL. Conseqüentemente, o acesso ao Celerra por meio da API XML deve ser especificamente habilitado.

Ao criar um usuário administrativo, é necessário especificar o tipo de acesso que ele terá ao Celerra. Por padrão, um novo usuário administrativo não tem acesso.


Quando uma conta de usuário local é criada automaticamente para um usuário mapeado por domínio, esse novo usuário recebe acesso ao Celerra Manager e a API XML, por padrão.

Considerações de planejamento para o uso de um servidor externo de diretórios na identificação e autenticação de usuários administrativosUma conta de usuário administrativo pode ser identificada e autenticada por um servidor externo de diretórios quando o usuário faz log-in na Control Station do Celerra. O servidor externo de diretórios oferece um repositório central de contas de usuário, simplificando o gerenciamento.

O servidor externo de diretórios pode ser um Active Directory baseado em LDAP ou um servidor que não seja Active Directory:

◆ o Active Directory é um serviço de diretórios baseado em LDAP usado no Windows 2000 e no Windows Server 2003 que proporciona gerenciamento para contas de grupos e usuários, segurança e recursos distribuídos.

◆ OpenLDAP e iPlanet (também conhecidos como Sun Java System e Sun ONE) são servidores de diretórios baseados em LDAP que oferecem um repositório central para armazenar e gerenciar perfis de identidade, privilégios de acesso e informações de recursos de rede e aplicativos.

Noções básicas do servidor de diretórios Um servidor de diretórios baseado em LDAP organiza as informações em uma estrutura de diretórios hierárquica exclusiva para atender às necessidades particulares de uma empresa. Cada objeto armazenado no diretório é representado por uma entrada de diretório. Uma entrada é formada por um ou mais atributos. Os atributos de uma entrada a definem exclusivamente. As entradas são armazenadas de forma hierárquica na árvore de diretórios. Usando o LDAP, é possível solicitar uma entrada bem como todas as entradas e respectivos atributos abaixo da entrada solicitada.

Um exemplo de estrutura de diretórios baseada em LDAP é o seguinte:

dc=minhaempresa,dc=com ou=people ou=group ou=hosts ou=netgroup

dc= indica os componentes de domínio e ou= indica as unidades organizacionais compostas de pessoas, grupos, hosts e grupos de rede. Geralmente, o atributo cn é usado para indicar o nome pelo qual uma entrada específica é normalmente conhecida.

A estrutura de diretórios pode ser alterada. Por exemplo, a informação do usuário pode ser armazenada em um recipiente chamado “users”, em vez de “people”, e os hosts em um recipiente chamado “computers”, em vez de “hosts”. É necessário trabalhar com o administrador do servidor de diretórios baseado em LDAP para entender a estrutura de diretórios de sua empresa e verificar se as entradas necessárias estão definidas.


Configurando o acesso Para configurar o cliente baseado em LDAP da Control Station, é necessário ter as seguintes informações:

◆ nome do domínio — indica a raiz da árvore de diretórios LDAP, ou seja, o lugar na árvore em que se deve iniciar a busca por informações. Também conhecido como o nome distinto de base.

Por exemplo, o nome distinto de base para a estrutura de diretórios baseada em LDAP do exemplo é dc=minhaempresa,dc=com. O Active Directory pressupõe que o tipo de atributo é dc, de forma que o nome distinto de base pode ser expresso simplesmente como minhaempresa.com.

Observação: O Celerra aceita somente um domínio LDAP. Ele não aceita árvores ou florestas. Conseqüentemente, as referências a outros domínios não são seguidas.

◆ nome distinto de vinculação — indica a identidade usada na vinculação com o serviço LDAP, ou seja, o usuário ou conta com permissão para pesquisar no diretório LDAP dentro da base de busca definida.

Geralmente o Active Directory assume o seguinte formato de nome distinto de vinculação: cn=<acctname>,cn=users,dc=<domain component>,dc=<domain component>.

Observação: O administrador do Active Directory pode criar usuários em outros locais dentro do Active Directory, caso em que o caminho do nome distinto de vinculação pode ser diferente.

Um servidor de diretórios OpenLDAP aceita diferentes formatos de nome distinto de vinculação, tais como: cn=<acctname>,uid=<name>,ou=people,dc=<domain component>,dc=<domain component> ou uid=<name>,dc=users,dc=<domain component>,dc=<domain component>.

◆ caminho de pesquisa de usuário e atributo de nome — indicam a ramificação de diretório que o Celerra vai pesquisar em busca de uma instância do atributo cujo valor é o nome da conta do usuário.

Geralmente, o Active Directory assume o seguinte caminho de pesquisa de usuário e atributo de nome: cn=<acctname>,cn=users,dc=<domain component>,dc=<domain component>.

Observação: O administrador do Active Directory pode criar usuários em outros locais dentro do Active Directory, caso em que o caminho de pesquisa de usuário pode ser diferente.

Um servidor de diretórios OpenLDAP aceita diferentes formatos de nome distinto de vinculação, tais como: uid=<name>,ou=people,dc=<domain component>,dc=<domain component> ou uid=<name>,dc=users,dc=<domain component>,dc=<domain component>.

◆ caminho de pesquisa de grupo, atributo de nome, classe de grupo membro — indicam a unidade de diretórios que o Celerra vai pesquisar em busca de uma


instância do atributo cujo valor é o nome do grupo do usuário. O grupo pode ser mais bem especificado com a identificação da classe (e respectivo atributo) em que está armazenado.

O Active Directory assume o seguinte caminho de pesquisa de grupo e atributo de nome: cn=<acctname>,cn=users,dc=<domain component>,dc=<domain component>. No Active Directory, grupos e usuários são armazenados na mesma hierarquia. A classe de grupo se chama “grupo”, já o valor do atributo padrão é um “membro”.

Observação: O administrador do Active Directory pode criar grupos em outros locais dentro do Active Directory, caso em que o caminho de pesquisa de grupos pode ser diferente.

Em outros servidores de diretório, a classe pode ser posixGroup, groupOfNames ou groupOfUniqueNames. Se o valor da classe do grupo for groupOfNames, o valor de atributo padrão será uniqueMember. Se o valor da classe do grupo for groupOfNames, o valor de atributo padrão será member. Se o valor da classe do grupo for posixGroup, o valor de atributo padrão será memberUid.

Conectando-se ao servidor de diretórios com SSLPara proteger o tráfego de LDAP e melhorar a segurança de aplicativos servidor e cliente, o servidor de diretórios baseado em LDAP pode aceitar e, em alguns casos, exigir, o uso de SSL. A SSL fornece recursos de criptografia e autenticação. Ela criptografa dados na rede e fornece autenticação de mensagens e servidores. Também aceita autenticação de clientes, se necessário, pelo servidor. A SSL usa certificados digitais, cuja autenticidade é verificada por uma CA.

O cliente LDAP, usando o cliente básico de SSL, autentica o certificado recebido do servidor de diretórios baseado em LDAP. O certificado da CA (para a autoridade que assinou o certificado do servidor de diretórios) deverá ter sido importado para a Control Station para que sua verificação seja bem-sucedida. Além disso, o assunto do certificado do servidor deve conter o nome de host e endereço IP do servidor, ou a verificação do certificado falhará.

Observação: A implementação do cliente baseado em LDAP da Control Station não aceita a autenticação de clientes baseada em SSL.

A seção "Configurando o uso de um servidor externo de diretórios na identificação e autenticação de usuários administrativos" na página 29 descreve como configurar esse recurso.

Considerações de planejamento para acesso administrativo baseado em funçõesUma conta de usuário administrativo está sempre associada a um grupo principal, e a cada grupo é atribuída uma função. Uma função define os privilégios (isto é, as operações) que o usuário administrativo pode executar em cada objeto específico do Celerra. A partir do Celerra 5.6, é necessário ter os privilégios apropriados para acessar e controlar os objetos do Celerra.


Grupos e funções Uma conta de usuário administrativo está sempre associada a um grupo principal. Ela pode estar associada a outros grupos, até um máximo de 17. Como as contas de usuários, os grupos podem ser tanto locais quanto locais mapeados em um grupo de domínios.

O Celerra oferece grupos predefinidos e grupos personalizados. Os grupos predefinidos não podem ser modificados nem excluídos. A cada grupo é atribuída uma função. Só é possível atribuir uma função por vez ao grupo. Porém, uma função pode ser associada a vários grupos. Se não for atribuída uma função a um grupo, ele receberá a função padrão de operador, que tem apenas privilégios de leitura. A Tabela 9 na página 22 apresenta os grupos predefinidos e as funções associadas.

Um usuário administrativo pode ter várias funções pertencendo a diversos grupos. Nesse caso, o conjunto dessas funções determina as operações que o usuário administrativo pode executar.

Funções e privilégiosUma função define os privilégios (operações) que um usuário administrativo pode realizar em um objeto específico do Celerra. Há três níveis de privilégios:

◆ Leitura — permite que um usuário administrativo visualize os objetos. Por padrão, todos os usuários administrativos têm privilégios de leitura sobre todos os objetos.

◆ Modificação — permite que um usuário administrativo faça alterações em um objeto.

◆ Controle total — permite que um usuário administrativo crie e exclua objetos, e faça alterações significativas. Por padrão, todos os usuários administrativos têm controle total sobre os objetos da tarefa.

O Celerra oferece funções predefinidas e personalizadas. As funções predefinidas (também chamadas de funções do sistema) não podem ser modificadas. As funções

Tabela 9 Grupos predefinidos e funções associadas

Nome do grupo Função associada

backup backup_operator

fullnas nasadmin

nasadmin operator

network network_admin

opadmin operator

root root

security security_operator

storage storage_admin


personalizadas (também identificadas como funções do usuário) são definidas pelos administradores.

As funções predefinidas (e os objetos do Celerra sobre os quais essas funções têm privilégios de modificação ou controle total) são:

Funções predefinidas Descrição

Objetos sobre os quais a função tem privilégios de modificação

Objetos sobre os quais a função tem controle total

root função raiz do sistema Licenses Log Collection & Transfer Network Services

Todos os objetos

Observação: Para ter controle total sobre as propriedades da Control Station e do ConnectHome, é necessário fazer log-in como usuário root. Um usuário com privilégios root não tem controle total sobre esses objetos.

nasadmin função padrão de administrador

Licenses Log Collection & Transfer Network Services Replication

Todos os objetos exceto:

Control Station ConnectHome Administrative Access (user management only)

security operator operador de segurança com acesso a gerenciamento de funções e gerenciamento de usuários/grupos

Licenses Acesso administrativo Certificados de chave pública

backup operator função de operador de backup com controle total a ckpt e VTLU

n/d Checkpoints VTLU

filemover_application função do aplicativo FileMover

n/d FileMover

network admin função de administrador de rede

n/d Devices Interfaces NIS DNS Routing

storage admin função de administrador de armazenamento

n/d Pools Volumes File Systems Quotas Migration FileMover Storage Systems

operator função padrão de operador n/d n/d


Privilégios padrão do usuárioA conta de usuário root pertence ao grupo root, que por sua vez está associado à função root.

A conta de usuário nasadmin pertence ao grupo nasadmin, que está associado à função de operador para acesso somente leitura, da lista de membros do grupo principal. Além disso, é um componente do grupo fullnas, que está associado à função nasadmin para acesso de modificação e controle total de quase todos os objetos do Celerra.

Por padrão, um novo usuário administrativo é atribuído ao grupo nasadmin, o que significa que o usuário tem privilégios somente para a leitura.

Observação: No recurso de acesso administrativo baseado em funções, o grupo nasadmin está associado à função de operador mais restritiva. Os privilégios mais amplos associados anteriormente à conta padrão do usuário nasadmin atualmente são acessados por meio da participação no grupo fullnas.

O que acontece uma vez que as funções são atribuídasUm usuário administrativo precisa de privilégios apropriados para acessar e controlar objetos do Celerra.

Usando o Celerra Manager

Se um usuário administrativo utilizar o Celerra Manager para ter acesso ao sistema Celerra e não estiver autorizado a desempenhar determinada função, essa função aparecerá esmaecida e estará indisponível. Isso pode ocorrer em menus, botões e campos.

Usando a CLI

Observação: No Celerra 5.6, a maior parte dos comandos da CLI não são compatíveis com privilégios e funções. Portanto, não é possível limitar os privilégios de um usuário administrativo que utiliza a CLI. Conseqüentemente, os usuários administrativos que usam a CLI continuam a ter, no mínimo, todos os privilégios associados à função nasadmin. Se você deseja criar usuários administrativos com funções mais limitadas que a função nasadmin, você deve permitir o acesso desses usuários ao Celerra somente através do Celerra Manager.

Na versão 5.6, os privilégios e funções são obrigatórios para apenas quarto comandos CLI:

◆ nas_ckpt_schedule

◆ nas_copy

◆ nas_replicate

◆ nas_task

Para executar algumas ou todas as opções desses comandos, o usuário administrativo deve receber uma função que proporcione privilégios de controle total sobre o objeto Replications. As descrições de cada comando oferecem informações detalhadas sobre que privilégios são necessários para executar diversas opções.


Considerações de planejamento para segurança de senhaSenhas fortes são um elemento importante de uma estratégia de segurança.

Política de qualidade de senhaPara garantir que senhas suficientemente fortes sejam escolhidas por todos os usuários administrativos locais, é possível definir uma política de qualidade de senha que imponha certa complexidade para as senhas definidas por usuários. Esse recurso não diz respeito a usuários mapeados por domínio, cujas senhas são governadas por políticas internas do domínio.

A política de senhas padrão do Celerra inclui as seguintes exigências:

◆ Uma senha com no mínimo 8 caracteres

◆ Um máximo de três tentativas para definir uma nova senha de valor aceitável antes que o comando falhe

◆ Um mínimo de três caracteres que não façam parte da senha anterior

◆ Pelo menos um algarismo na nova senha

Observação: Atualmente, não há a necessidade de usar caracteres especiais (como !, @, #, $, %, &, ^ e *) ou caracteres em maiúsculas e minúsculas nas senhas.

O Celerra também aceita um período de expiração de senha padrão de 120 dias.

A seção "Configurando a política de senhas" na página 32 descreve como configurar esse recurso.

Observação: As alterações feitas na política de qualidade de senha entrarão em vigor apenas para as senhas definidas depois que a política foi revisada.

Mudando senhas padrãoO Celerra oferece duas contas padrão para usuários administrativos: root e nasadmin. A senha nasadmin é atribuída às duas contas por padrão. O procedimento de instalação do Celerra permite que uma senha diferente seja especificada, mas uma senha nova não é necessária.

!CUIDADO!Se as senhas padrão não forem alteradas durante a instalação, é preciso fazê-lo o quanto antes.

As senhas são escolhidas e alteradas através da página User Properties no Celerra Manager. A ajuda on-line do Celerra Manager oferece uma explicação detalhada desse procedimento.

Observação: É possível acessar a página User Properties em Security > Administrators > guia Users ou a partir do campo User Name, na guia Control Station Properties.

Usuários root e administrativos com privilégios de operador de segurança não são obrigados a escolher senhas de acordo com a política. Além disso, ao criar uma


nova conta de usuário, usuários root e administrativos com privilégios de operador de segurança podem atribuir qualquer senha a esse usuário.

No entanto, se o usuário alterar a senha posteriormente, essa senha estará sujeita à política vigente. Uma vez que a política de senhas estiver estabelecida, um erro será retornado, indicando que a senha é inválida, mediante a tentativa de definir uma senha que não atenda às exigências especificadas.

Considerações de planejamento para PKI (Public Key Infrastructure, infra-estrutura de chave pública)A infra-estrutura PKI do Celerra oferece sistemas de banco de dados e gerenciamento de software para servir de suporte ao uso de certificados digitais para as conexões LDAP e HTTP de Data Mover em que o SSL está habilitado. Os certificados, cuja autenticidade é verificada por uma CA, são usados pelo SSL para identificar um ou ambos os extremos de uma conexão, proporcionando maior segurança entre clientes e servidores.

Observação: A estrutura PKI do Celerra aceita o padrão de certificado X.509. Os certificados são codificados com DER (Distinguished Encoding Rules, regras distintas de codificação) e podem ser depois codificados no formato PEM (Privacy Enhanced Mail, correio com alta privacidade) para facilitar a distribuição através de sistemas de e-mail.

PersonasAs personas são usadas para proporcionar uma identidade a um Data Mover quando este atua como servidor ou cliente. Ao negociar uma conexão segura com um cliente (tal como a política externa e o software de migração usados com o FileMover), a persona proporciona uma chave privada e um certificado para o Data Mover (que atua como um servidor). Esse certificado serve como o meio pelo qual o cliente pode identificar e autenticar o servidor. Ao negociar uma conexão segura com um servidor (tal como o servidor externo de diretórios baseado em LDAP) configurado para exigir autenticação por parte do cliente, a persona fornece uma chave privada e um certificado para o Data Mover (que atua como servidor). Esse certificado serve como o meio pelo qual o servidor pode identificar e autenticar o cliente.

Por padrão, cada Data Mover vem configurado com uma única persona padrão designada. Para criar o certificado que essa persona fornece ao Data Mover, primeiro é gerado o conjunto de chaves públicas/privadas dessa persona. Depois, é necessário solicitar um certificado assinado de uma CA. Solicitações de certificado são geradas apenas no formato PEM.

Observação: Atualmente, cada Data Mover só tem permissão para uma persona. O Celerra não dispõe de um mecanismo para criar mais personas.

Se você estiver usando a Control Station do Celerra como CA, ela receberá automaticamente a solicitação do certificado, que é gerado, assinado e devolvido ao Data Mover. A Control Station pode assinar certificados para todos os Data Movers do gabinete. Ela não pode ser usada para assinar certificados de nenhum host externo. A seção "Usando a Control Station como CA" na página 42 descreve as tarefas envolvidas no uso da CA de uma Control Station.

Caso uma CA externa esteja sendo usada, é necessário enviar a solicitação de certificado manualmente. A solicitação para assinar uma chave pública é gerada


com o conjunto de chaves públicas/privadas. Visualize as propriedades da persona para verificar seu conteúdo. Obtenha uma cópia da solicitação de certificado e depois envie a solicitação à CA pelo site da empresa ou por e-mail.

Quando a CA devolver o certificado assinado, é preciso importá-lo para o Data Mover. Para importar o certificado assinado, é necessário fornecer um caminho e importar o arquivo ou recortar e colar o texto associado. Um arquivo pode estar tanto no formato DER quanto no PEM. É possível recortar e colar texto apenas no formato PEM.

Cada persona pode ser associada a até dois conjuntos de chaves (o atual e o próximo) para permitir que novas chaves e certificados sejam gerados antes do vencimento do certificado atual. Quando o próximo certificado (que já é válido) é importado, ele e o conjunto de chaves associado imediatamente se tornam o conjunto e certificado de chaves atuais.

Como o certificado seguinte geralmente só é gerado quando necessário, não é comum vê-los associados a uma persona. No entanto, o próximo certificado pode estar em espera, caso exista uma diferença de tempo entre o Data Mover e a CA (ou a Control Station, se ela estiver servindo de CA). Por exemplo, uma CA pode preparar um certificado de antemão, atribuindo a ele uma data futura de início. Empresas em processo de fusão poderiam configurar um certificado para implantá-lo na data oficial de fusão.

O certificado seguinte se torna o atual (e a chave e o certificado atuais são eliminados) quando um certificado se torna válido (pelo tempo do Data Mover) e ocorre uma das seguintes situações:

◆ A persona é consultada (seja pela CLI ou pelo Celerra Manager).

◆ A chave e o certificado da persona são solicitados por uma função do Data Mover (tal como SSL).

Ao término da validade de um certificado, qualquer tentativa de usar o certificado resulta em falha, geralmente em perda de conexão ou falha ao reconectar. Quando um novo certificado está disponível, a PKI exclui o certificado antigo e fornece o novo quando solicitada. Entretanto, caso um novo certificado seja obtido antes que o atual expire, a solicitação de certificado não funcionará. A PKI não fornecerá um certificado vencido para uma persona.

Não há maneira automatizada de verificar a existência de certificados de chave pública vencidos. É preciso fazer isso manualmente, listando as personas e examinando as datas de expiração dos certificados associados. Depois, é possível agir de acordo com as práticas de negócio de sua empresa.

A seção "Criando o certificado fornecido pela persona" na página 42 esboça o procedimento para criar o conjunto e certificado de chaves fornecidos pela persona quando o Celerra é configurado como servidor ou cliente.

Certificados de CAQuando um aplicativo cliente baseado no Celerra requer uma conexão de rede com um servidor (como uma conexão do FileMover com seu armazenamento secundário), o servidor proporcionará um certificado como parte da negociação para uma conexão segura. O Celerra confirma a identidade do servidor validando o certificado. Ele faz isso através da verificação da assinatura do certificado do servidor com uma chave pública do certificado de CA.


A obtenção dos certificados de CA exigidos é uma tarefa manual. Geralmente, antes da operação real, é preciso identificar a CA apropriada. Depois, deve-se verificar a lista de certificados de CA disponível no Celerra. Se um novo certificado de CA for solicitado e uma CA externa estiver em uso, será possível obter o certificado de CA do site da empresa ou da pessoa responsável pela segurança. Se a CA for local (corporativa ou interna), obtenha o certificado de CA da pessoa que administra a autoridade.

Para fazer com que o Celerra identifique o certificado, é preciso importá-lo. É possível fornecer um caminho e importar um arquivo ou recortar e colar o texto. Um arquivo pode estar tanto no formato DER quanto no PEM. É possível recortar e colar texto apenas no formato PEM.

A seção "Obtendo certificados de CA" na página 42 resume o procedimento para obter o certificado usado para confirmar a identidade de um servidor.

Usando a Control Station como CAO Celerra gera automaticamente um conjunto e certificado de chaves para a Control Station quando o sistema é instalado ou atualizado. A Control Station usa esse conjunto e certificado de chaves para assinar solicitações de certificado do Data Mover. Contudo, antes que a Control Station possa operar com sucesso como CA e ser reconhecida como tal por um Data Mover, várias tarefas de configuração devem ser realizadas:

◆ Distribua o certificado de CA da Control Station para clientes de rede. Para que um cliente de rede possa validar um certificado enviado por um Data Mover e assinado por uma Control Station, ele precisa da chave pública do certificado de CA para verificar a assinatura do certificado do Data Mover.

◆ Importe o certificado de CA (com certificados de CAs externas).

Uma cópia do certificado da Control Station só pode ser obtida usando o comando da CLI nas_ca_certificate, conforme descrito em "Usando a Control Station como CA" na página 42.

Se o conjunto e certificado de chaves da Control Station estiverem comprometidos, é possível recriá-los. Essa tarefa só pode ser concluída por meio do comando da CLI nas_ca_certificate. Depois de recriar o conjunto e certificado de chaves da Control Station, é preciso refazer a solicitação de conjunto de chaves e de certificado, depois importando o certificado assinado para todas as personas cujos certificados forem assinados pela Control Station.

Observação: A Control Station continua a gerar um conjunto de chaves separado para a conexão baseada em SSL entre o servidor da Web Apache do Celerra (em nome do Celerra Manager) e o navegador da Web do usuário. Entretanto, agora a Control Station usa o conjunto de chaves de CA para assinar o certificado do servidor da Web Apache, o que significa que o certificado é mais assinado automaticamente. A seção Installing EMC Celerra Management Applications descreve como gerenciar certificados para o Celerra Manager.


Configurando o uso de um servidor externo de diretórios na identificação e autenticação de usuários administrativosO uso de um servidor externo de diretórios oferece um repositório central de contas de usuários administrativos, simplificando o gerenciamento. A seção "Considerações de planejamento para o uso de um servidor externo de diretórios na identificação e autenticação de usuários administrativos" na página 19 oferece uma descrição geral.

Antes do log-in do usuário administrativo, você deve realizar uma série de tarefas de configuração preliminares.

Etapa Ação

1. Determinar com que servidor de diretórios baseado em LDAP o Celerra vai se comunicar.

Observação: Geralmente, a empresa na qual o Celerra está sendo usado já emprega um servidor de diretórios baseado em LDAP para armazenar as credenciais dos usuários. Nesse caso, consulte o administrador do Active Directory ou de outro servidor de diretórios baseado em LDAP para obter informações de conexão. Caso contrário, será preciso estudar o Active Directory ou outro servidor de diretórios baseado em LDAP disponível para detectar as informações de conexão necessárias. Há várias ferramentas disponíveis para gerenciar serviços de diretórios baseados em LDAP. O "Apêndice B: Noções básicas da configuração do servidor de diretórios" na página 70 oferece informações sobre essas ferramentas.

2. Obtenha as seguintes informações:

a. O nome distinto de base indica a raiz da árvore de diretórios LDAP, ou seja, o lugar na árvore em que se deve iniciar a busca por informações. O DN (Domain Name, nome de domínio) base pode ser expresso como um nome de domínio completo ou no formato X.509 usando o atributo dc=. Por exemplo, se o nome de domínio completo for minhaempresa.com, o DN base é expresso como dc=minhaempresa,dc=com.

b. Endereço IP ou nome de host do servidor de diretórios baseado em LDAP.c. Endereço IP ou nome de host de um servidor baseado em LDAP de backup

de diretórios.


3. Solicite que o administrador do servidor de diretórios adicione um nome de usuário ou conta identificando o Celerra na estrutura de diretório do servidor baseado em LDAP. Ou, se você tiver permissão para criar contas de usuários e grupos no Active Directory ou em outro servidor de diretórios baseado em LDAP, adicione você mesmo este nome de conta ou usuário.

Essa conta deve ser restrita (tal como Domain Guest) com privilégios de leitura/pesquisa para o diretório.

Observação: Há várias ferramentas disponíveis para gerenciar serviços de diretórios baseados em LDAP. O "Apêndice B: Noções básicas da configuração do servidor de diretórios" na página 70 apresenta informações sobre essas ferramentas.

Essa entrada identifica o Celerra como o usuário ou conta que será vinculada ao serviço de diretório, ou seja, o usuário ou conta com permissão para pesquisar o diretório LDAP dentro da base de pesquisa definida. Essa entrada também é conhecida como nome distinto de vinculação.

Por exemplo, ao usar um Active Directory, o nome distinto de vinculação será definido como cn=<acctname>,cn=users,dc=<domain component>,dc=<domain component> e, ao usar um servidor de diretórios OpenLDAP, uid=<name>,dc=users,dc=<domain component>,dc=<domain component> ou cn=<acctname>,uid=<name>,ou=people,dc=<domain component>,dc=<domain component>.

4. Verifique se os usuários administrativos (e grupos associados) que farão log-in na Control Station estão definidos no servidor de diretórios baseado em LDAP e determine os caminhos que o Celerra pesquisará para uma instância do atributo de nome cujo valor é o nome do grupo ou usuário.

Se as contas de usuário e de grupo ainda não existirem, solicite que o administrador do servidor de diretórios as adicione. Ou, se você tiver permissão para criar contas de usuários e grupos no Active Directory ou em outro servidor de diretórios baseado em LDAP, adicione você mesmo.

Observação: Há várias ferramentas disponíveis para gerenciar serviços de diretórios baseados em LDAP. O "Apêndice B: Noções básicas da configuração do servidor de diretórios" na página 70 apresenta informações sobre essas ferramentas.

Por exemplo, se os usuários e grupos estiverem armazenados em uma unidade de organização com usuários de nome comum, o caminho de busca será cn=users,dc=<domain component>,dc=<domain component>.

5. Se a conexão do LDAP usar SSL, obtenha o certificado público da CA que assina o certificado de SSL do servidor de diretórios baseado em LDAP. O Celerra usa esse certificado da CA para verificar o certificado recebido do servidor LDAP. O certificado deve estar no formato codificado Base64.

Se o servidor de diretórios baseado em LDAP usar uma CA externa, obtenha o certificado de CA do site da empresa CA. Se o servidor de diretórios baseado em LDAP usar uma CA interna ou se os certificados forem assinados automaticamente, obtenha o certificado de CA do administrador do servidor de diretórios baseado em LDAP.

Se você não habilitar o SSL, não será necessário um certificado de CA.

Etapa Ação


6. Com a informação descoberta, faça log-in no Celerra Manager e use Administrators > guia Domain Settings para configurar a Control Station de forma que possa acessar o servidor de diretórios baseado em LDAP.

Observação: Se você selecionar o campo Enable automatic domain user mapping, na guia Domain Settings, o Celerra criará automaticamente uma conta de usuário local associada ao usuário de domínio. Outra opção é criar um usuário administrativo vinculado a um usuário de domínio e associá-lo a um grupo mapeado por domínio.

A ajuda on-line do Celerra Manager oferece uma descrição dessas tarefas.

Etapa Ação


Configurando a política de senhasEsse recurso permite que o administrador root do Celerra defina as exigências de complexidade de senha para todos os usuários administrativos locais. A seção "Considerações de planejamento para segurança de senha" na página 25 traz uma descrição geral.

Observação: Esse recurso não diz respeito a usuários administrativos mapeados por domínio, cujas senhas são governadas por políticas internas do domínio.

Observação: É preciso ser usuário root para executar o comando /nas/sbin/nas_config.

Definição interativa da política de senhas

Ação

Para iniciar um script que solicite as definições da política de senhas, use esta sintaxe de comando: # /nas/sbin/nas_config -password

Saída

Minimum length for a new password (Between 6 and 15): [8] Number of attempts to allow before failing: [3] Number of new characters (not in the old password): [3] Number of digits that must be in the new password: [1] Number of special characters that must be in a new password: [0] Number of lower case characters that must be in password: [0] Number of upper case characters that must be in password: [0]

Observações

O valor atual definido para cada campo é exibido entre colchetes. Os valores padrão originais para cada campo são:

• tamanho: mínimo 8 caracteres, escala 6-15• tentativas: máximo 3 tentativas• caracteres novos: mínimo 3 caracteres• dígitos: mínimo um dígito• caracteres especiais, em minúsculas e maiúsculas: 0

Para alterar o valor de cada campo, digite um novo valor quando solicitado.


Definição das configurações específicas da política de senhas

Configuração do período de validade de senhasO arquivo /etc/login.defs contém o parâmetro usado para definir a expiração da senha.

Ação

Para definir configurações específicas da política de senhas, use esta sintaxe de comando: # /nas/sbin/nas_config -password [-min <6..15>] [-retries <max_allowed>] [-newchars <min_num>] [-digits <min_num>] [-spechars <min_num>] [-lcase <min_num>] [-ucase <min_num>]

onde<6..15> = tamanho mínimo da nova senha. O tamanho padrão é de 8 caracteres. O tamanho precisa apresentar um valor entre 6 e 15 caracteres. <max_allowed> = número de tentativas de que um usuário dispõe para definir uma senha aceitável antes que o comando falhe. O valor padrão é 3 tentativas.<min_num> = número mínimo de caracteres que devem estar na nova senha e que não constavam na antiga. O valor padrão é 3 caracteres.<min_num> = número mínimo de dígitos que devem ser incluídos na nova senha. O valor padrão é 1.<min_num> = número mínimo de caracteres especiais (como !, @, #, $, %, &, ^ e *) que devem ser incluídos na nova senha. O valor padrão é 0.<min_num> = número mínimo de caracteres em minúsculas que devem ser incluídos na nova senha. O valor padrão é 0.<min_num> = número mínimo de caracteres em maiúsculas que devem ser incluídos na nova senha. O valor padrão é 0.

Exemplo:

Para definir como 10 o tamanho mínimo de uma nova senha, digite:# /nas/sbin/nas_config -password -min 10

Saída

#

Etapa Ação

1. Faça log-in na CLI com seu nome de usuário e senha. São necessários privilégios de root para acessar o arquivo /etc/login.def.

2. Altere o valor do parâmetro pass_max_days no arquivo /etc/login.def usando o vi ou outro editor de texto.

Observação: O período de validade padrão é 120 dias.


Configurando o tempo limite de sessãoO Celerra impõe um tempo limite tanto para as sessões do Celerra Manager quanto para as do shell da Control Station:

◆ Para gerenciar o tempo limite de sessão do Celerra Manager, selecione Celerras > [Celerra_name] > Security > Celerra Manager. Você encontrará informações mais detalhadas na ajuda on-line do Celerra Manager.

◆ É possível alterar o valor padrão do tempo limite de sessão da Control Station usando o comando /nas/sbin/nas_config -sessiontimeout.

Observação: É preciso ser usuário root para executar o comando /nas/sbin/nas_config.

Pré-requisitosA Control Station aceita três shells:

◆ bash

◆ ksh

◆ tcsh

Cada shell aceita um recurso de tempo limite de sessão. A opção Control Station session timeout define o valor do tempo limite de sessão do sistema, atualizando automaticamente os valores apropriados em /etc/environment para os shells bash e ksh, e a variável autologout em /etc/csh.cshrc para o shell tcsh.

Depois que o valor é definido, shells recém-criados são afetados (mas nenhum dos shells atualmente em execução).

Observação: É possível alterar o valor do tempo limite de sessão para usuários administrativos individuais, basta definir a variável em questão no arquivo de configuração de shell do usuário (por exemplo, ~/.bashrc). Os valores não sofrem restrição se você editar o arquivo de configuração diretamente.

Alteração do valor do tempo limite de sessãoO valor padrão do tempo limite para as sessões de shell da Control Station é 60 minutos. A ociosidade ou o tempo de inatividade é definido como o período desde a exibição de um aviso primário do shell sem que nenhuma entrada fosse recebida. Conseqüentemente, a espera dentro de uma solicitação em um comando por tempo indeterminado não é afetada pelo valor de tempo limite de sessão.


Desabilitação do tempo limite de sessão

Ação

Para alterar o valor do tempo limite de sessão, use esta sintaxe de comando:# /nas/sbin/nas_config -sessiontimeout <minutes>

onde:<minutes> = número de minutos para o tempo limite de sessão (em um intervalo de 5 a 240)

Exemplo:

Para alterar o valor do tempo limite de sessão para 200 minutos, digite:# /nas/sbin/nas_config -sessiontimeout 200

Saída

#

Ação

Para desabilitar o tempo limite de sessão, use esta sintaxe de comando: # /nas/sbin/nas_config -sessiontimeout 0

ou# /nas/sbin/nas_config -sessiontimeout off

Saída

#


Personalizando um banner de log-inO arquivo /etc/issue contém uma mensagem de banner de log-in ou uma identificação de sistema, que aparece antes do aviso de log-in. Um banner de log-in pode ser usado para fins informativos, mas é empregado com mais freqüência para avisar usuários sobre o uso não autorizado ou inadequado do sistema.

Observação: Também é possível personalizar o banner de log-in usando a guia Control Station Properties do Celerra Manager. São necessários privilégios de root para acessar o campo Login Banner.

Etapa Ação

1. Faça log-in na CLI com seu nome de usuário e senha. São necessários privilégios de root para acessar o arquivo /etc/issue.

2. Edite o arquivo /etc/issue usando o vi ou outro editor de texto.

A EMC sugere que um caractere carriage return extra seja adicionado no fim da mensagem do banner.

Use espaços, guias e caracteres carriage return para formatar a mensagem. Em geral, o tamanho da mensagem deve ser limitado a não mais que uma tela.

Observação: Como o banner de log-in aparece com a solicitação de log-in, não inclua informações confidenciais na mensagem.

3. Faça log-in na CLI ou no Celerra Manager para visualizar o banner de log-in e verificar suas alterações.


Criando uma MOTD (Message Of The Day, mensagem do dia) O arquivo de mensagem do dia, /etc/motd, é exibido depois que um usuário se conecta com sucesso. Ele pode ser usado para fins informativos, mas é particularmente útil para enviar mensagens que digam respeito a todos os usuários. A mensagem pode conter informações sobre um upgrade de servidor ou um alerta relacionado ao desligamento iminente do sistema. Por padrão, esse arquivo está vazio.

Observação: Também é possível personalizar a MOTD usando a guia Control Station Properties do Celerra Manager. São necessários privilégios de root para acessar o campo Message of the Day.

Etapa Ação

1. Faça log-in na CLI com seu nome de usuário e senha. São necessários privilégios de root para acessar o arquivo /etc/motd.

2. Edite o arquivo /etc/motd usando o vi ou outro editor de texto.

A EMC sugere que um caractere carriage return extra seja adicionado no fim da mensagem do banner.

Use espaços, guias e caracteres carriage return para formatar a mensagem. Em geral, o tamanho da mensagem deve ser limitado a não mais que uma tela.

3. Faça log-in na CLI ou no Celerra Manager para visualizar a MOTD e verificar suas alterações.


Protegendo tokens de sessãoA conexão entre um usuário e o Celerra Manager e entre dois Celerras usa SHA1 para gerar checksums com o objetivo de proteger os tokens de sessão (cookies) usados na identificação dos usuários depois do log-in. O valor secreto SHA1 usado para gerar os checksums é definido de maneira aleatória durante a instalação. Entretanto, para aumentar a segurança, é possível alterar o valor secreto padrão SHA1.

Etapa Ação

1. Faça log-in na CLI com seu nome de usuário e senha. São necessários privilégios de root para acessar o arquivo /nas/http/conf/secret.txt.

2. Edite o arquivo /nas/http/conf/secret.txt usando o vi ou outro editor de texto.

Substitua a frase padrão por outra e salve o arquivo.

Ao alterar esse valor, os tokens de sessão existentes se tornam inválidos e os usuários atuais do Celerra Manager precisam refazer o log-in.


Configurando a criptografia e autenticação de rede usando o protocolo SSLO SSL é um protocolo de nível de sessão usando para criptografar transmissões de rede na Internet. Ele criptografa dados e fornece autenticação de mensagens e servidores. Também aceita autenticação de clientes, se necessário, pelo servidor. O SSL é independente de protocolos de nível mais alto, de forma que pode encapsular qualquer protocolo em nível de aplicativo, como HTTP e LDAP:

◆ o HTTP é um protocolo rápido, sem estado e orientado a objetos usado na Web. Ele permite aos clientes e servidores negociar e interagir. Infelizmente, seus recursos de segurança são mínimos. O HTTPS (seguro) é uma variante do HTTP usada por um servidor com SSL habilitado.

◆ O Lightweight Directory Access Protocol (LDAP) é um protocolo de acesso padrão do setor que é executado diretamente sobre TCP/IP. É o principal protocolo de acesso para o Active Directory e outros servidores de diretórios tais como o Sun Java System Directory Server (iPlanet) e o OpenLDAP.

O Celerra aceita SSL é aceito em conexões HTTP e LDAP de Data Movers.

Usando HTTPSO SSL é habilitado em conexões HTTP do Data Mover por meio do comando server_http. Atualmente, o recurso FileMover do Celerra usa criptografia e autenticação HTTPS e SSL. A seção Usando o EMC Celerra FileMover descreve como configurar o SSL com HTTP para uso pelo FileMover. As chaves e certificados usados com SSL são gerenciados usando a PKI. A PKI está disponível através da CLI e do Celerra Manager. A seção "Considerações de planejamento para PKI (Public Key Infrastructure, infra-estrutura de chave pública)" na página 26 oferece uma visão geral do recurso PKI. "Configurando a PKI" na página 42 e "Gerenciando a PKI" na página 57 descrevem como configurar e gerenciar a PKI pela CLI.

Usando SSL com LDAPO SSL é habilitado em conexões LDAP do Data Mover por meio do comando server_ldap. Atualmente, o suporte ao serviço de nomes do Celerra para OpenLDAP, iPlanet e Active Directory usa os recursos de criptografia e autenticação LDAP e SSL. A seção Configuring EMC Celerra Naming Services descreve como configurar o SSL com LDAP para uso pelos servidores de diretórios baseados em LDAP OpenLDAP e iPlanet. As chaves e certificados usados com SSL são gerenciados via PKI. A PKI está disponível através da CLI e do Celerra Manager. A seção "Considerações de planejamento para PKI (Public Key Infrastructure, infra-estrutura de chave pública)" na página 26 oferece uma visão geral do recurso PKI. "Configurando a PKI" na página 42 e "Gerenciando a PKI" na página 57 descrevem como configurar e gerenciar a PKI pela CLI.


Alteração do protocolo SSL padrãoO Celerra aceita as seguintes versões do protocolo SSL:

◆ SSLv3

◆ TLSv1

Alteração do conjunto de codificações padrão do SSLUm conjunto de codificações padrão define um conjunto de tecnologias para proteger a comunicação via SSL.

◆ Algoritmo de intercâmbio de chaves (como a chave secreta usada para criptografar os dados é informada do cliente para o servidor). Exemplos: chave RSA ou DH (Diffie-Hellman)

◆ Método de autenticação (como os hosts podem autenticar a identidade de hosts remotos). Exemplos: certificado RSA, certificado DSS ou sem autenticação

◆ Codificação da criptografia (como criptografar dados). Exemplos: AES (256 ou 128 bits), RC4 (128 bits ou 56 bits), 3DES (168 bits), DES (56 ou 40 bits) ou sem criptografia

◆ Algoritmo de hash (assegurando os dados por oferecer uma maneira de determinar se eles foram modificados). Exemplos: SHA-1 ou MD5

Os conjuntos de codificações aceitos combinam todos estes itens. O "Apêndice A: Conjuntos de codificações do SSL aceitos" na página 68 lista os conjuntos de codificações SSL aceitos pelo Celerra.

Ação

Para alterar o valor padrão do protocolo SSL, use esta sintaxe de comando:$ server_param <movername> -facility ssl -modify protocol -value <new_value>

onde:<movername> = nome do Data Mover<new_value> = 0 (tanto SSLv3 quanto TLSv1), 1 (apenas SSLv3) ou 2 (apenas TLSv1)

Observação: O valor padrão é 0.

Nomes de parâmetros e recursos fazem distinção entre maiúsculas e minúsculas.

Exemplos:

Para alterar o protocolo SSL padrão para apenas SSLv3, digite:$ server_param server_2 -facility ssl -modify protocol -value 1

Para alterar o protocolo SSL padrão para apenas TLSv1, digite:$ server_param server_2 -facility ssl -modify protocol -value 2

Saída

server_2 : done


Pós-requisitosDepois de alterar os valores de parâmetro do SSL, é necessário reinicializar o Data Mover para que as alterações do conjunto de codificações e do protocolo SSL tenham efeito.

Ação

Para alterar o conjunto de codificações padrão do SSL, use esta sintaxe de comando:$ server_param <movername> -facility ssl -modify cipher -value <new_value>

onde:<movername> = nome do Data Mover especificado.<new_value> = string que especifica o novo valor da codificação. Se o valor incluir algum caractere especial (como ponto-e-vírgula, espaço ou ponto-de-exclamação), ele deve ser colocado entre aspas.

Observação: O valor padrão do conjunto de codificações é ALL:!ADH:!SSLv2:@STRENGTH, o que significa que o Celerra aceita todas as codificações exceto SSLv2, Anonymous Diffie-Hellman e NULL, organizadas de acordo com sua “força”, ou seja, o tamanho de sua chave de criptografia.

Nomes de parâmetros e recursos fazem distinção entre maiúsculas e minúsculas.

Exemplo:

Para alterar o conjunto de codificações padrão do SSL para uma codificação forte (principalmente AES128 e AES256) a ser usada por todas as novas conexões SSL, digite:$ server_param server_2 -facility ssl -modify cipher -value ‘HIGH:@STRENGTH’

Saída

server_2 : done


Configurando a PKIA seção "Considerações de planejamento para PKI (Public Key Infrastructure, infra-estrutura de chave pública)" na página 26 contém uma descrição geral desse recurso.

Criando o certificado fornecido pela personaO procedimento para criar o certificado fornecido pela persona ao Data Mover varia ligeiramente, dependendo se a CA que assina o certificado for externa ou a Control Station do Celerra:

1. "Geração de uma solicitação por conjunto e certificado de chaves" na página 43

2. "Envio da solicitação de certificado à CA" na página 46 (não é necessário se a Control Station estiver sendo usada)

3. "Importação de um certificado assinado pela CA" na página 47 (não é necessário se a Control Station estiver sendo usada)

Obtendo certificados de CA O procedimento para obter os certificados de CA usados para confirmar a identidade de um servidor inclui as seguintes tarefas:

1. "Listagem dos certificados de CA disponíveis" na página 50

2. "Aquisição de um certificado de CA" na página 50

3. "Importação de um certificado de CA" na página 53

Usando a Control Station como CA O procedimento para usar a Control Station como CA inclui as seguintes tarefas:

1. "Geração de um novo certificado de CA da Control Station" na página 53

2. "Exibição do certificado" na página 54

3. "Distribuição do certificado de CA da Control Station" na página 56

Observação: A Control Station continua a gerar um conjunto de chaves separado para a conexão baseada em SSL entre o servidor da Web Apache do Celerra (em nome do Celerra Manager) e o navegador da Web do usuário. Entretanto, agora a Control Station usa o conjunto de chaves de CA para assinar o certificado do servidor da Web Apache, o que significa que o certificado é mais assinado automaticamente. A seção Installing EMC Celerra Management Applications descreve como gerenciar certificados para o Celerra Manager.


Geração de uma solicitação por conjunto e certificado de chavesPara criar o certificado fornecido pela persona ao Data Mover, primeiro é gerado o conjunto de chaves públicas/privadas da persona, com uma solicitação para que a CA assine o certificado. A CA pode ser externa ou a Control Station.

Criação de um certificado assinado por uma CA externa

Ação

Para gerar um conjunto de chaves e solicitar que um certificado seja assinado por uma CA externa, use esta sintaxe de comando:$ server_certificate <movername> -persona -generate {<persona_name> | id=<persona_id>} -key_size <bits> {-cn | -common_name} <common_name>

onde:<movername> = nome do Data Mover físico com o qual a persona está associada.

<persona_name> = nome da persona.

<persona_id> = ID da persona. O ID é gerado na criação da persona. É possível determinar o ID por meio do comando -persona -list.

<bits> = tamanho da chave, 2.048 ou 4.096 bits.

<common_name> = nome comum usado, geralmente um nome de host que descreve o Data Mover com o qual a persona está associada. Se o nome incluir algum caractere especial (como ponto-e-vírgula, espaço ou ponto-de-exclamação), ele deve ser colocado entre aspas.

Observação: Solicitações de certificado são geradas apenas no formato PEM.

Exemplo:

Para gerar um conjunto de chaves e solicitar que um certificado seja assinado por uma CA externa, digite:

$ server_certificate server_2 -persona -generate default -key_size 4096 -cn ‘name;1.2.3.4’

Saída

server_2 : Starting key generation. This could take a long time ... done


Criação de um certificado assinado pela Control Station Se você estiver usando a Control Station do Celerra para assinar o certificado, é necessário especificar o número de meses de validade do certificado.

Criação de um certificado especificando informações detalhadas sobre a personaAo gerar uma solicitação por conjunto e certificado de chaves públicas/privadas, é possível especificar informações detalhadas sobre o Data Mover. Geralmente, essa informação inclui detalhes tais como a empresa que usa o Data Mover e onde

Ação

Para gerar um conjunto de chaves e solicitar que um certificado seja assinado pela Control Station, use esta sintaxe de comando:$ server_certificate <movername> -persona -generate {<persona_name> | id=<persona_id>} -key_size <bits> -cs_sign_duration <# of months> {-cn | -common_name} <common_name>





<# of months> = número de meses nos quais o certificado é válido.



Exemplo:

Para gerar um conjunto de chaves e solicitar que um certificado seja assinado pela Control Station, digite:

$ server_certificate server_2 -persona -generate default -key_size 4096 -cs_sign_duration 13 -cn ‘name;1.2.3.4’

Saída



ela está localizada. Além disso, existe a opção de salvar a solicitação de certificado em um arquivo específico.

Ação

Para gerar um conjunto de chaves e uma solicitação por um certificado assinado por uma CA externa, especificando informações detalhadas sobre o Data Mover e salvando a solicitação de certificado em um arquivo específico, use esta sintaxe de comando:$ server_certificate <movername> -persona -generate {<persona_name> | id=<persona_id>} -key_size <bits> {-cn | -common_name} <common_name> -ou <org_unit> -organization <organization> -location <location> -state <state> -country <country> -filename <output_path>






<org_unit> = nome da unidade organizacional. Se o nome incluir algum caractere especial (como ponto-e-vírgula, espaço ou ponto-de-exclamação), ele deve ser colocado entre aspas.

<organization> = nome da empresa.

<location> = localização física da empresa.

<state> = estado onde a empresa está localizada.

<country> = país onde a empresa está localizada.

<output_path> = nome e caminho no qual a solicitação gerada é gravada.

Observação: Os argumentos -ou, -organization, -location, -state e -country são opcionais.

Observação: O argumento -filename só é válido se o certificado for assinado por uma CA externa.


Exemplo:

Para gerar um conjunto de chaves e uma solicitação por um certificado assinado por uma CA externa, especificando informações detalhadas sobre o Data Mover e salvando a solicitação de certificado em um arquivo específico, digite:

$ server_certificate server_2 -persona -generate default -key_size 4096 -cn ‘name;1.2.3.4’ -ou ‘my.org;my dept’ -organization EMC -location Hopkinton -state MA -country US -filename /tmp/server_2.1.request.pem

Saída



Envio da solicitação de certificado à CA

Observação: Essa tarefa não é necessária se você estiver usando a Control Station para assinar o certificado. A Control Station recebe automaticamente a solicitação de certificado.

Se você estiver usando uma CA externa para assinar o certificado, uma solicitação para assinar a chave pública é automaticamente gerada juntamente com o conjunto de chaves públicas/privadas. Você deve então enviar a solicitação de certificado à CA.

Etapa Ação

1. Exiba as propriedades da persona para verificar o conteúdo da solicitação de certificado usando esta sintaxe de comando:$ server_certificate <movername> -persona -info {-all | <persona_name> | id=<persona_id>}



<persona_id> = ID da persona. O ID é gerado na criação da persona.

Exemplo:

Para exibir as propriedades para a persona padrão, incluindo a solicitação de certificado, digite:$ server_certificate server_2 -persona -info default

Saída:

server_2 : id=1 name=default next state=Request Pending next certificate: request subject = CN=name;CN=1.2.3.4 request: -----BEGIN CERTIFICATE REQUEST----- MIIB6TCCAVICAQYwDQYJKoZIhvcNAQEEBQAwWzELMAkGA1UEBhMCQVUxEzARBgNV BAgTClF1ZWVuc2xhbmQxGjAYBgNVBAoTEUNyeXB0U29mdCBQdHkgTHRkMRswGQYD VQQDExJUZXN0IENBICgxMDI0IGJpdCkwHhcNMDAxMDE2MjIzMTAzWhcNMDMwMTE0 MjIzMTAzWjBjMQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDEaMBgG A1UEChMRQ3J5cHRTb2Z0IFB0eSBMdGQxIzAhBgNVBAMTGlNlcnZlciB0ZXN0IGNl cnQgKDUxMiBiaXQpMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAJ+zw4Qnlf8SMVIP Fe9GEcStgOY2Ww/dgNdhjeD8ckUJNP5VZkVDTGiXav6ooKXfX3j/7tdkuD8Ey2// Kv7+ue0CAwEAATANBgkqhkiG9w0BAQQFAAOBgQCT0grFQeZaqYb5EYfk20XixZV4 GmyAbXMftG1Eo7qGiMhYzRwGNWxEYojf5PZkYZXvSqZ/ZXHXa4g59jK/rJNnaVGM k+xIX8mxQvlV0n5O9PIha5BX5teZnkHKgL8aKKLKW1BK7YTngsfSzzaeame5iKfz itAE+OjGF+PFKbwX8Q== -----END CERTIFICATE REQUEST-----

2. Salve a solicitação de certificado em um arquivo (por exemplo, server_2.1.request.pem), se ainda não o fez.

3. Envie o arquivo.pem para a CA usando o site da empresa ou e-mail.


Importação de um certificado assinado pela CA

Observação: Essa tarefa não é necessária se você estiver usando a Control Station para assinar o certificado. A Control Station devolve automaticamente o certificado assinado para o Data Mover.

Você pode importar um certificado assinado quando o próximo associado à persona estiver disponível para download. Assim que o certificado é importado, ele se torna o certificado atual (supondo que a data seja válida).

Etapa Ação

1. Obtenha o certificado assinado (por exemplo, cert.pem) da CA.

2. Consulte todos os Data Movers para determinar que personas estão esperando por um certificado assinado:$ server_certificate ALL -persona -list

Saída:

server_2 : id=1 name=default next state=Request Pending request subject = CN=name;CN=1.2.3.4 server_3 : id=1 name=default next state=Request Pending request subject = CN=test;CN=5.6.7.8

3. Para determinar para que persona o certificado deve ser importado, compare o assunto do certificado com o valor do campo Request Subject para as personas cujo Next State seja Request Pending.


4. Importe o certificado assinado para a persona em espera usando esta sintaxe de comando:$ server_certificate <movername> -persona -import {<persona_name> | id=<persona_id>}




Observação: O certificado assinado pode estar tanto no formato DER quanto no PEM. Você só pode colar textos no formado PEM no prompt de comando. Se você especificar -filename e fornecer um caminho, é possível importar um certificado assinado pela CA tanto no formato DER quando no PEM.

Exemplo:

Para importar um certificado assinado, digite:

$ server_certificate server_2 -persona -import default

Saída:

server_2 : Please paste certificate data. Enter a carriage return and on the new line type ‘end of file’ or ‘eof’ followed by another carriage return.

Observação: depois que o texto do certificado estiver colado corretamente, a solicitação do sistema é exibida.

Etapa Ação


5. Verifique o sucesso na importação do certificado usando esta sintaxe de comando:$ server_certificate <movername> -persona -info {-all | <persona_name> | id=<persona_id>}




Exemplo:

Para verificar o sucesso na importação do certificado para a persona padrão, digite:$ server_certificate server_2 -persona -info default

Saída:

server_2id=1 name=default next state=Not Available Current Certificate: id = 1 subject = CN=name;CN=1.2.3.4 issuer = O=Celerra Certificate Authority;CN=eng173100 start date = 20070606183824Z end date = 20070706183824Z serial number = 05 signature alg. = sha1WithRSAEncryption public key alg. = rsaEncryption public key size = 4096 version = 3

Observação: Geralmente, depois de que um certificado é importado, ele se torna imediatamente o conjunto e certificado de chaves, e o campo Next State é exibido como Not Available. Se o certificado importado não for válido (por exemplo, seu registro de data e hora está muitos minutos acima ou abaixo do Data Mover), o conjunto e certificado de chaves importados permanecem nessa condição, e o campo Next State é exibido como Available até que este tempo, assim como o conjunto de chaves e certificado, se torne válido.

Etapa Ação


Listagem dos certificados de CA disponíveis

Aquisição de um certificado de CASe um novo certificado de CA for solicitado e uma CA externa estiver em uso, será possível obter o certificado de CA do site da empresa ou possivelmente da pessoa responsável pela segurança em sua empresa. Se a CA for a Control Station (corporativa ou interna), é possível obter o certificado de CA da pessoa que administra a autoridade. Outra opção é exibir o texto do certificado de CA através do comando nas_ca_certificate -display.

Ação

Para exibir todos os certificados de CA disponíveis, digite:$ server_certificate ALL -ca_certificate -list

Saída

server_2 : id=1subject=C=ZA;ST=Western Cape;L=Cape Town;O=Thawte Consulting cc;OU=Certificissuer=C=ZA;ST=Western Cape;L=Cape Town;O=Thawte Consulting cc;OU=Certificaexpire=20201231235959Z

id=2subject=C=US;O=America Online Inc.;CN=America Online Root Certification Autissuer=C=US;O=America Online Inc.;CN=America Online Root Certification Authexpire=20371119204300Z

id=3subject=C=US;ST=Massachusetts;L=Westboro;O=EMC;OU=IS;OU=Terms of use at wwwissuer=O=VeriSign Trust Network;OU=VeriSign, Inc.;OU=VeriSign Internationalexpire=20080620235959Z

id=4subject=C=US;O=VeriSign,Inc.;OU=Class 3 Public Primary Certification Authorissuer=C=US;O=VeriSign, Inc.;OU=Class 3 Public Primary Certification Authorexpire=20280801235959Z

Ação

Para exibir o certificado de CA da Control Station, digite:$ /nas/sbin/nas_ca_certificate -display

Observação: O certificado é mostrado na tela do terminal. Outra opção é redirecioná-lo para um arquivo. O texto do certificado está contido entre BEGIN CERTIFICATE e END CERTIFICATE.


Saída

Certificate: Data: Version: 3 (0x2) Serial Number: 3 (0x3) Signature Algorithm: sha1WithRSAEncryption Issuer: O=Celerra Certificate Authority, CN=eng173100 Validity Not Before: Mar 23 21:07:40 2007 GMT Not After : Mar 21 21:07:40 2012 GMT Subject: O=Celerra Certificate Authority, CN=eng173100 Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:da:b2:37:86:05:a3:73:d5:9a:04:ba:db:05:97: d2:12:fe:1a:79:06:19:eb:c7:2c:c2:51:93:7f:7a: 93:59:37:63:1e:53:b3:8d:d2:7f:f0:e3:49:42:22: f4:26:9b:b4:e4:a6:40:6d:8d:e7:ea:07:8e:ca:b7: 7e:88:71:9d:11:27:5a:e3:57:16:03:a7:ee:19:25: 07:d9:42:17:b4:eb:e6:97:61:13:54:62:03:ec:93: b7:e6:f1:7f:21:f0:71:2d:c4:8a:8f:20:d1:ab:5a: 6a:6c:f1:f6:2f:26:8c:39:32:93:93:67:bb:03:a7: 22:29:00:11:e0:a1:12:4b:02:79:fb:0f:fc:54:90: 30:65:cd:ea:e6:84:cc:91:fe:21:9c:c1:91:f3:17: 1e:44:7b:6f:23:e9:17:63:88:92:ea:80:a5:ca:38: 9a:b3:f8:08:cb:32:16:56:8b:c4:f7:54:ef:75:db: 36:7e:cf:ef:75:44:11:69:bf:7c:06:97:d1:87:ff: 5f:22:b5:ad:c3:94:a5:f8:a7:69:21:60:5a:04:5e: 00:15:04:77:47:03:ec:c5:7a:a2:bf:32:0e:4d:d8: dc:44:fa:26:39:16:84:a7:1f:11:ef:a3:37:39:a6: 35:b1:e9:a8:aa:a8:4a:72:8a:b8:c4:bf:04:70:12: b3:31 Exponent: 65537 (0x10001)


Saída

X509v3 extensions: X509v3 Subject Key Identifier: 35:06:F2:FE:CC:21:4B:92:DA:74:C9:47:CE:BB:37:21:5E:04:E2:E6 X509v3 Authority Key Identifier: keyid:35:06:F2:FE:CC:21:4B:92:DA:74:C9:47:CE:BB:37:21:5E:04:E2:E6 DirName:/O=Celerra Certificate Authority/CN=eng173100 serial:00X509v3 Basic Constraints: CA:TRUE X509v3 Subject Alternative Name: DNS:eng173100 Signature Algorithm: sha1WithRSAEncryption 09:c3:13:26:16:be:44:56:82:5d:0e:63:07:19:28:f3:6a:c4: f3:bf:93:25:85:c3:55:48:4e:07:84:1d:ea:18:cf:8b:b8:2d: 54:13:25:2f:c9:75:c1:28:39:88:91:04:df:47:2c:c0:8f:a4: ba:a6:cd:aa:59:8a:33:7d:55:29:aa:23:59:ab:be:1d:57:f6: 20:e7:2b:68:98:f2:5d:ed:58:31:d5:62:85:5d:6a:3f:6d:2b: 2d:f3:41:be:97:3f:cf:05:8b:7e:f5:d7:e8:7c:66:b2:ea:ed: 58:d4:f0:1c:91:d8:80:af:3c:ff:14:b6:e7:51:73:bb:64:84: 26:95:67:c6:60:32:67:c1:f7:66:f4:79:b5:5d:32:33:3c:00: 8c:75:7d:02:06:d3:1a:4e:18:0b:86:78:24:37:18:20:31:61: 59:dd:78:1f:88:f8:38:a0:f4:25:2e:c8:85:4f:ce:8a:88:f4: 4f:12:7e:ee:84:52:b4:91:fe:ff:07:6c:32:ca:41:d0:a6:c0: 9d:8f:cc:e8:74:ee:ab:f3:a5:b9:ad:bb:d7:79:67:89:34:52: b4:6b:39:db:83:27:43:84:c3:c3:ca:cd:b2:0c:1d:f5:20:de: 7a:dc:f0:1f:fc:70:5b:71:bf:e3:14:31:4c:7e:eb:b5:11:9c: 96:bf:fe:6f-----BEGIN CERTIFICATE-----MIIDoDCCAoigAwIBAgIBAzANBgkqhkiG9w0BAQUFADA8MSYwJAYDVQQKEx1DZWxlcnJhIENlcnRpZmljYXRlIEF1dGhvcml0eTESMBAGA1UEAxMJZW5nMTczMTAwMB4XDTA3MDMyMzIxMDc0MFoXDTEyMDMyMTIxMDc0MFowPDEmMCQGA1UEChMdQ2VsZXJyYSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxEjAQBgNVBAMTCWVuZzE3MzEwMDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANqyN4YFo3PVmgS62wWX0hL+GnkGGevHLMJRk396k1k3Yx5Ts43Sf/DjSUIi9CabtOSmQG2N5+oHjsq3fohxnREnWuNXFgOn7hklB9lCF7Tr5pdhE1RiA+yTt+bxfyHwcS3Eio8g0ataamzx9i8mjDkyk5NnuwOnIikAEeChEksCefsP/FSQMGXN6uaEzJH+IZzBkfMXHkR7byPpF2OIkuqApco4mrP4CMsyFlaLxPdU73XbNn7P73VEEWm/fAaX0Yf/XyK1rcOUpfinaSFgWgReABUEd0cD7MV6or8yDk3Y3ET6JjkWhKcfEe+jNzmmNbHpqKqoSnKKuMS/BHASszECAwEAAaOBrDCBqTAdBgNVHQ4EFgQUNQby/swhS5LadMlHzrs3IV4E4uYwZAYDVR0jBF0wW4AUNQby/swhS5LadMlHzrs3IV4E4uahQKQ+MDwxJjAkBgNVBAoTHUNlbGVycmEgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRIwEAYDVQQDEwllbmcxNzMxMDCCAQAwDAYDVR0TBAUwAwEB/zAUBgNVHREEDTALggllbmcxNzMxMDAwDQYJKoZIhvcNAQEFBQADggEBAAnDEyYWvkRWgl0OYwcZKPNqxPO/kyWFw1VITgeEHeoYz4u4LVQTJS/JdcEoOYiRBN9HLMCPpLqmzapZijN9VSmqI1mrvh1X9iDnK2iY8l3tWDHVYoVdaj9tKy3zQb6XP88Fi3711+h8ZrLq7VjU8ByR2ICvPP8UtudRc7tkhCaVZ8ZgMmfB92b0ebVdMjM8AIx1fQIG0xpOGAuGeCQ3GCAxYVndeB+I+Dig9CUuyIVPzoqI9E8Sfu6EUrSR/v8HbDLKQdCmwJ2PzOh07qvzpbmtu9d5Z4k0UrRrOduDJ0OEw8PKzbIMHfUg3nrc8B/8cFtxv+MUMUx+67URnJa//m8=-----END CERTIFICATE-----


Importação de um certificado de CAPara fazer com que os Data Movers identifiquem o certificado, é preciso importá-lo. É possível fornecer um caminho e importar um arquivo ou recortar e colar o texto.

Geração de um novo certificado de CA da Control Station

Observação: Essa tarefa só é necessária se o conjunto de chaves da CA tiver sido comprometido ou se o certificado de CA expirar. O certificado de CA inicial da Control Station é gerado durante a instalação ou o upgrade do Celerra 5.6.

É necessário ser o usuário root para usar esse comando.

Ação

Para importar um certificado de CA, use esta sintaxe de comando:$ server_certificate <movername> -ca_certificate -import [-filename <path>]

onde:<movername> = nome do Data Mover físico com o qual o Data Mover físico está associado.

<path> = local do arquivo a ser importado

Observação: O certificado de CA pode estar tanto no formato DER quanto no PEM. Você só pode colar textos no formado PEM no prompt de comando. Se você especificar -filename e fornecer um caminho, é possível importar um certificado de CA tanto no formato DER quando no PEM.

Exemplo:

Para importar um certificado de CA, digite:$ server_certificate server_2 -ca_certificate -import

Saída

server_2 : Please paste certificate data. Enter a carriage return and on the new line type ‘end of file’ or ‘eof’ followed by another carriage return.

Observação

depois que o texto do certificado estiver colado corretamente, a solicitação do sistema é exibida.

Ação

Para gerar um novo conjunto e certificado de chaves para a Control Station, digite:# /nas/sbin/nas_ca_certificate -generate

Observação: Por padrão, esse certificado é válido por 5 anos a partir da data na qual é gerado, e o nome do certificado é o nome de host da Control Station.

Saída

New keys and certificate were successfully generated.


Exibição do certificadoExiba o texto do certificado de CA da Control Station, de modo que seja possível copiá-lo para distribuição entre clientes de rede.

Ação

Para exibir o certificado de CA da Control Station, digite:$ /nas/sbin/nas_ca_certificate -display

Observação: O certificado é mostrado na tela do terminal. Outra opção é redirecioná-lo para um arquivo.

Saída

Certificate: Data: Version: 3 (0x2) Serial Number: 3 (0x3) Signature Algorithm: sha1WithRSAEncryption Issuer: O=Celerra Certificate Authority, CN=eng173100 Validity Not Before: Mar 23 21:07:40 2007 GMT Not After : Mar 21 21:07:40 2012 GMT Subject: O=Celerra Certificate Authority, CN=eng173100 Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:da:b2:37:86:05:a3:73:d5:9a:04:ba:db:05:97: d2:12:fe:1a:79:06:19:eb:c7:2c:c2:51:93:7f:7a: 93:59:37:63:1e:53:b3:8d:d2:7f:f0:e3:49:42:22: f4:26:9b:b4:e4:a6:40:6d:8d:e7:ea:07:8e:ca:b7: 7e:88:71:9d:11:27:5a:e3:57:16:03:a7:ee:19:25: 07:d9:42:17:b4:eb:e6:97:61:13:54:62:03:ec:93: b7:e6:f1:7f:21:f0:71:2d:c4:8a:8f:20:d1:ab:5a: 6a:6c:f1:f6:2f:26:8c:39:32:93:93:67:bb:03:a7: 22:29:00:11:e0:a1:12:4b:02:79:fb:0f:fc:54:90: 30:65:cd:ea:e6:84:cc:91:fe:21:9c:c1:91:f3:17: 1e:44:7b:6f:23:e9:17:63:88:92:ea:80:a5:ca:38: 9a:b3:f8:08:cb:32:16:56:8b:c4:f7:54:ef:75:db: 36:7e:cf:ef:75:44:11:69:bf:7c:06:97:d1:87:ff: 5f:22:b5:ad:c3:94:a5:f8:a7:69:21:60:5a:04:5e: 00:15:04:77:47:03:ec:c5:7a:a2:bf:32:0e:4d:d8: dc:44:fa:26:39:16:84:a7:1f:11:ef:a3:37:39:a6: 35:b1:e9:a8:aa:a8:4a:72:8a:b8:c4:bf:04:70:12: b3:31 Exponent: 65537 (0x10001)


Saída

X509v3 extensions: X509v3 Subject Key Identifier: 35:06:F2:FE:CC:21:4B:92:DA:74:C9:47:CE:BB:37:21:5E:04:E2:E6 X509v3 Authority Key Identifier: keyid:35:06:F2:FE:CC:21:4B:92:DA:74:C9:47:CE:BB:37:21:5E:04:E2:E6 DirName:/O=Celerra Certificate Authority/CN=eng173100 serial:00X509v3 Basic Constraints: CA:TRUE X509v3 Subject Alternative Name: DNS:eng173100 Signature Algorithm: sha1WithRSAEncryption 09:c3:13:26:16:be:44:56:82:5d:0e:63:07:19:28:f3:6a:c4: f3:bf:93:25:85:c3:55:48:4e:07:84:1d:ea:18:cf:8b:b8:2d: 54:13:25:2f:c9:75:c1:28:39:88:91:04:df:47:2c:c0:8f:a4: ba:a6:cd:aa:59:8a:33:7d:55:29:aa:23:59:ab:be:1d:57:f6: 20:e7:2b:68:98:f2:5d:ed:58:31:d5:62:85:5d:6a:3f:6d:2b: 2d:f3:41:be:97:3f:cf:05:8b:7e:f5:d7:e8:7c:66:b2:ea:ed: 58:d4:f0:1c:91:d8:80:af:3c:ff:14:b6:e7:51:73:bb:64:84: 26:95:67:c6:60:32:67:c1:f7:66:f4:79:b5:5d:32:33:3c:00: 8c:75:7d:02:06:d3:1a:4e:18:0b:86:78:24:37:18:20:31:61: 59:dd:78:1f:88:f8:38:a0:f4:25:2e:c8:85:4f:ce:8a:88:f4: 4f:12:7e:ee:84:52:b4:91:fe:ff:07:6c:32:ca:41:d0:a6:c0: 9d:8f:cc:e8:74:ee:ab:f3:a5:b9:ad:bb:d7:79:67:89:34:52: b4:6b:39:db:83:27:43:84:c3:c3:ca:cd:b2:0c:1d:f5:20:de: 7a:dc:f0:1f:fc:70:5b:71:bf:e3:14:31:4c:7e:eb:b5:11:9c: 96:bf:fe:6f-----BEGIN CERTIFICATE-----MIIDoDCCAoigAwIBAgIBAzANBgkqhkiG9w0BAQUFADA8MSYwJAYDVQQKEx1DZWxlcnJhIENlcnRpZmljYXRlIEF1dGhvcml0eTESMBAGA1UEAxMJZW5nMTczMTAwMB4XDTA3MDMyMzIxMDc0MFoXDTEyMDMyMTIxMDc0MFowPDEmMCQGA1UEChMdQ2VsZXJyYSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxEjAQBgNVBAMTCWVuZzE3MzEwMDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANqyN4YFo3PVmgS62wWX0hL+GnkGGevHLMJRk396k1k3Yx5Ts43Sf/DjSUIi9CabtOSmQG2N5+oHjsq3fohxnREnWuNXFgOn7hklB9lCF7Tr5pdhE1RiA+yTt+bxfyHwcS3Eio8g0ataamzx9i8mjDkyk5NnuwOnIikAEeChEksCefsP/FSQMGXN6uaEzJH+IZzBkfMXHkR7byPpF2OIkuqApco4mrP4CMsyFlaLxPdU73XbNn7P73VEEWm/fAaX0Yf/XyK1rcOUpfinaSFgWgReABUEd0cD7MV6or8yDk3Y3ET6JjkWhKcfEe+jNzmmNbHpqKqoSnKKuMS/BHASszECAwEAAaOBrDCBqTAdBgNVHQ4EFgQUNQby/swhS5LadMlHzrs3IV4E4uYwZAYDVR0jBF0wW4AUNQby/swhS5LadMlHzrs3IV4E4uahQKQ+MDwxJjAkBgNVBAoTHUNlbGVycmEgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRIwEAYDVQQDEwllbmcxNzMxMDCCAQAwDAYDVR0TBAUwAwEB/zAUBgNVHREEDTALggllbmcxNzMxMDAwDQYJKoZIhvcNAQEFBQADggEBAAnDEyYWvkRWgl0OYwcZKPNqxPO/kyWFw1VITgeEHeoYz4u4LVQTJS/JdcEoOYiRBN9HLMCPpLqmzapZijN9VSmqI1mrvh1X9iDnK2iY8l3tWDHVYoVdaj9tKy3zQb6XP88Fi3711+h8ZrLq7VjU8ByR2ICvPP8UtudRc7tkhCaVZ8ZgMmfB92b0ebVdMjM8AIx1fQIG0xpOGAuGeCQ3GCAxYVndeB+I+Dig9CUuyIVPzoqI9E8Sfu6EUrSR/v8HbDLKQdCmwJ2PzOh07qvzpbmtu9d5Z4k0UrRrOduDJ0OEw8PKzbIMHfUg3nrc8B/8cFtxv+MUMUx+67URnJa//m8=-----END CERTIFICATE-----


Distribuição do certificado de CA da Control StationÉ necessário tornar o certificado da Control Station disponível, de forma que possa ser importado por clientes de rede e usado para reconhecer os certificados enviados pelo Data Mover e assinados por essa Control Station.

Etapa Ação

1. Salve o texto do certificado de CA da Control Station em um arquivo (por exemplo, cs_ca_cert.crt).

2. Disponibilize esse arquivo.crt para clientes de rede por meio de um mecanismo apropriado (FTP ou e-mail).

3. Volte a gerar uma solicitação de conjunto e certificado de chaves e importe um certificado assinado para qualquer persona cujos certificados são assinados pela Control Station. A seção "Criando o certificado fornecido pela persona" na página 42 descreve esse procedimento.

4. Se um Data Mover for cliente de outro, importe um novo certificado de CA para o Data Mover apropriado. A seção "Obtendo certificados de CA" na página 42 descreve esse procedimento.


Gerenciando a PKIA seção "Considerações de planejamento para PKI (Public Key Infrastructure, infra-estrutura de chave pública)" na página 26 contém uma descrição geral desse recurso.

As tarefas para gerenciar os conjuntos de chave e certificado da persona são:

◆ "Exibição das propriedades de um conjunto e certificado de chaves" na página 58

◆ "Verificação de conjuntos de chaves vencidos" na página 58

◆ "Eliminação de conjuntos de chaves" na página 59

As tarefas para gerenciar o certificado de CA são:

◆ "Exibição de propriedades do certificado de CA" na página 60

◆ "Verificação de certificados de CA vencidos" na página 60

◆ "Exclusão de certificados de CA" na página 61


Exibição das propriedades de um conjunto e certificado de chaves

Verificação de conjuntos de chaves vencidosNão há maneira automatizada de verificar a existência de conjuntos de chave e certificados vencidos. Em vez disso, é preciso verificar sua existência listando as personas e examinando as datas de expiração dos certificados associados.

Ação

Para exibir as propriedades de um conjunto e certificado de chaves, use esta sintaxe de comando:$ server_certificate <movername> -persona -info {-all | <persona_name> | id=<persona_id>}




Exemplo:

Para exibir o conjunto e certificado de chaves da persona chamada default, digite:$ server_certificate server_2 -persona -info default

Saída

server_2 : id=1 name=default next state=Not Available CURRENT CERTIFICATE: id = 1 subject = CN=test;CN=1.2.3.4 issuer = O=Celerra Certificate Authority;CN=eng173100 start date = 20070606183824Z end date = 20070706183824Z serial number = 05 signature alg. = sha1WithRSAEncryption public key alg. = rsaEncryption public key size = 4096 version = 3

Ação

Para listar todos os conjuntos de chave e certificados que estão atualmente disponíveis, digite:$ server_certificate ALL -persona -list


Eliminação de conjuntos de chavesVocê deve eliminar um conjunto de chaves quando ele estiver vencido, o serviço não for mais necessário ou a solicitação de certificado não for atendida. É possível eliminar o conjunto e certificado de chaves atuais de uma persona, o conjunto e certificado seguintes, ou ambos.

Saída

server_2 : id=1 name=default next state=Request Pending request subject=CN=name;CN=1.2.3.4server_3 : id=1 name=default next state=Not Available CURRENT CERTIFICATE: id=1 subject=CN=test;CN=1.2.3.4 expire=20070608183824Z issuer=O=Celerra Certificate Authority;CN=eng173100

Observação

A data de vencimento de um certificado atual é indicada no campo Expire. 20070608183824Z significa: sexta-feira, 08 de junho de 2007, 18:38:24 (GMT).

Ação

Para eliminar um conjunto de chaves e o certificado associado, use esta sintaxe de comando:$ server_certificate <movername> -persona -clear {<persona_name> | id=<persona_id>} {-next | -current | -both}

onde:<movername> = nome atribuído ao Data Mover físico com o qual a persona está associada.



Exemplo:

Para eliminar o conjunto e certificado de chaves atuais e os próximos para a persona em server_2, digite:$ server_certificate server_2 -persona -clear default -both

Saída

server_2 : done


Exibição de propriedades do certificado de CA

Verificação de certificados de CA vencidosNão há maneira automatizada de verificar a existência de certificados de CA vencidos. Em vez disso, é preciso verificar sua existência listando os certificados vencidos e examinando as datas de expiração.

Ação

Para exibir as propriedades de um certificado de CA, use esta sintaxe de comando:$ server_certificate <movername> -ca_certificate -info {-all | <certificate_id>}


<certificate_id> = ID do certificado.

Observação: Use a opção -all para exibir as propriedades de todos os certificados de CA disponíveis para o Data Mover.

Exemplo:

Para exibir as propriedades do certificado de CA identificado pelo ID de certificado 2, digite:$ server_certificate server_2 -ca_certificate -info 2

Saída

server_2 :id=2subject = C=US;O=VeriSign, Inc.;OU=Class 3 Public Primary Certification Authorityissuer = C=US;O=VeriSign, Inc.;OU=Class 3 Public Primary Certification Authoritystart = 19960129000000Zexpire = 20280801235959Zsignature alg. = md2WithRSAEncryptionpublic key alg. = rsaEncryptionpublic key size = 2048 bitsserial number = 70ba e41d 10d9 2934 b638 ca7b 03cc babfversion = 1

Ação

Para listar todos os certificados de CA que estão atualmente disponíveis, digite:$ server_certificate ALL -ca_certificate -list


Exclusão de certificados de CAÉ necessário excluir um certificado de CA quando ele tiver expirado, estiver comprometido ou não for mais necessário para autenticar um servidor.

Saída

server_2 :id=1subject=O=Celerra Certificate Authority;CN=sorentoissuer=O=Celerra Certificate Authority;CN=sorentoexpire=20120318032639Zid=2subject=C=US;O=VeriSign, Inc.;OU=Class 3 Public Primary Certification Authorissuer=C=US;O=VeriSign, Inc.;OU=Class 3 Public Primary Certification Authorexpire=20280801235959Z

server_3 :id=1subject=O=Celerra Certificate Authority;CN=zeus-csissuer=O=Celerra Certificate Authority;CN=zeus-csexpire=20120606181215Z

Observação

A data de vencimento de um certificado é indicada no campo Expire. 20120318032639Z significa: 18 de março de 2012, 03:26:39 (GMT).

Ação

Para excluir um certificado de CA, use esta sintaxe de comando:$ server_certificate <movername> -ca_certificate -delete {-all | <certificate_id>}


<certificate_id> = ID do certificado. É possível determinar o ID através do comando -ca_certificate -list.

Observação: Use a opção -all para excluir todos os certificados de CA disponíveis no Data Mover.

Exemplo:

Para excluir um certificado de CA em server_2 identificado por seu número de ID, digite:$ server_certificate server_2 -ca_certificate -delete 1

Saída

server_2 : done


Solução de problemas Como parte de um esforço para melhorar e aumentar continuamente o desempenho e os recursos de suas linhas de produtos, a EMC lança periodicamente novas versões de seus produtos de hardware e software. Por isso, algumas das funções descritas neste documento podem não servir para todas as revisões de software ou hardware usadas no momento. Para obter as informações mais atualizadas sobre os recursos dos produtos, consulte as notas da versão do produto.

Se um produto não funcionar adequadamente ou não funcionar conforme descrito neste documento, entre em contato com o representante da EMC.

Onde obter ajudaPara obter informações sobre suporte, produtos e licenciamento da EMC:

Informações sobre produtos — para documentação, notas da versão, upgrades de software ou informações sobre produtos EMC, licenciamento e serviços, vá até o site do EMC Powerlink (registro obrigatório) em:

http://Powerlink.EMC.com

Suporte técnico — para obter suporte técnico, vá para o Atendimento ao Cliente da EMC no Powerlink. Uma vez conectado ao site do Powerlink , vá para Suporte > Solicitação de suporte. Para abrir uma solicitação de serviço via Powerlink, você deve ter um contrato de suporte válido. Entre em contato com seu Representante de Atendimento ao Cliente EMC para obter detalhes sobre a obtenção de um contrato de suporte válido ou a fim de obter respostas a quaisquer perguntas que você tenha sobre sua conta.

Observação: Não solicite um representante de suporte específico a menos que já tenha sido designado um para seu problema específico no sistema.

Roteiro para solução de problemas do EMC Celerra contém informações adicionais sobre a utilização do Powerlink e solução de problemas.

EMC E-Lab Interoperability NavigatorO EMC E-LabTM Interoperability Navigator é uma ferramenta pesquisável on-line, baseada na Web, que permite acesso às matrizes de suporte de interoperabilidade da EMC. Ele está disponível em http://Powerlink.EMC.com. Depois de fazer log-in no Powerlink, vá para Suporte > Informações de interoperabilidade e ciclo de vida do produto > E-Lab Interoperability Navigator.

Solução de problemas de conexão da Control Station com um servidor de diretóriosTestando a conexão da Control Station com um servidor de diretóriosÉ possível verificar se a conexão da Control Station com o servidor de diretórios baseado em LDAP está funcionando, basta selecionar Test na página Administrators >

http://Powerlink.EMC.com


../ProblemResolutionRoadmap/index.htm




Domain Settings. Se você tiver um servidor de diretórios principal e um servidor de diretórios secundário, as duas conexões serão testadas juntas.

Se ao menos um servidor de diretórios puder ser acessado com êxito, a autenticação de usuários administrativos será bem-sucedida mesmo se houver falha na conexão com o outro servidor de diretórios. Entretanto, a função Test continuará a informar a falha até que seja possível realizar a conexão com os dois servidores de diretórios especificados.

Uma falha indica que as configurações de vinculação de domínio, endereços ou caminhos de pesquisa estão incorretas ou que um ou ambos os servidores não estão disponíveis. A função Test apenas assegura que a Control Station possa ser conectada (vinculada) ao servidor de diretórios. Ela não verifica se usuários e grupos podem ser localizados.

Observação: O servidor de diretórios de backup deve aceitar as mesmas configurações de domínio que o servidor de diretórios principal.

Criando uma conta de usuário vinculada ao serviço do diretórioA EMC recomenda que a conta de usuário usada na vinculação ao serviço de diretório seja o mais restrita possível (como uma conta em que o grupo principal é Domain Guests). Se a conta de usuário não conseguir se vincular ao serviço de diretório, verifique o seguinte:

1. Verifique se a Atribuição de direitos de usuários de GPO (Group Policy Objects, objetos de diretiva de grupo) não inclui convidados na lista de usuários que não têm acesso ao controlador de domínio da rede.

2. Nesses ambientes em que os convidados são impedidos de se conectar aos controladores de domínio, o grupo principal da conta de usuário deve ser Domain Users e não Domain Guests.

3. Se os problemas de acesso persistirem, deverá ser usada uma conta de usuário com mais privilégios.

Certifique-se de que a conta escolhida tenha privilégios de leitura/gravação no diretório.

Configurando a sessão SSLPara que a sessão SSL seja criada de maneira com sucesso, as seguintes tarefas de configuração devem ser realizadas corretamente.

◆ Na Control Station deve ser carregado o certificado público da CA que assinou o certificado SSL do servidor de diretórios baseado em LDAP. A Control Station utiliza esse certificado da CA para verificar o certificado recebido pelo servidor LDAP.

◆ O nome de host do servidor baseado em LDAP (especificado nos campos Primary e Backup em Administrators > guia Domain Settings) e o nome comum fornecido no certificado do servidor de diretórios devem coincidir. O valor a ser especificado depende do formato do assunto no certificado do servidor de diretórios, geralmente indicado pelo nome de host, embora possa ser pelo endereço IP.


Solução de problemas em contas locais de usuários administrativosHabilitando uma conta desativada por meio da alteração de senhaO Celerra Manager, como o sistema operacional Linux, ativa uma conta local de usuário administrativo que está desativada, se você alterar a senha dessa conta de usuário. Outras alterações em uma conta desabilitada não fazem com que ela seja habilitada novamente.

Usando contas de usuários locaisCom o Celerra é possível criar contas estritamente locais de usuários administrativos assim como contas locais de usuários administrativos mapeadas no domínio.

Você deve usar uma conta de usuário local para fazer log-in em um Celerra específico. Esse tipo de conta de usuário local é relevante somente para o Celerra no qual foi criada e é usada para gerenciar esse Celerra específico.

As contas locais criadas para usuários de domínios fornecem um mecanismo para verificar se um usuário que faz autenticação por um servidor externo de diretórios tem acesso autorizado ao Celerra Network Server e se esse usuário tem as credenciais locais necessárias, incluindo um UID para realizar tarefas. Você deve usar uma conta de domínio para acessar e gerenciar múltiplos Celerras remotamente, evitando a necessidade de configurar contas de usuários individuais em cada Celerra.

Importante: Não use o nome local de uma conta mapeada por domínio para fazer log-in no Celerra.

Limpando contas de usuários locais desatualizadasEm determinadas circunstâncias, você terá que excluir manualmente as contas de usuários locais desatualizadas do Celerra. Esse problema ocorre quando os nomes de usuários são idênticos. Por exemplo, um usuário, Jennifer Smith, tem uma conta de usuários locais mapeada no domínio chamada JSilva. Posteriormente, Jennifer adota o nome de casada e sua conta no servidor de diretórios passa a ser JSouza, criando uma nova conta mapeada no domínio. Então, quando é criado no servidor de diretórios um novo usuário, João Silva, que tem o nome de usuário JSilva e é mapeado ao Celerra, ele terá a conta de usuário local existente JSilva atribuída e receberá os privilégios anteriormente atribuídos a Jennifer.

A EMC recomenda que você evite a reutilização de nomes de usuários por diferentes usuários físicos no servidor de diretórios. Se essa utilização for inevitável, para impedir a situação possivelmente problemática acima, você deve usar o Celerra Manager para uma das seguintes opções:

◆ Caso o nome de usuário do diretório de um administrador do Celerra seja alterado, altere manualmente o nome de usuário local e o nome de usuário do domínio da conta de usuário local mapeada no domínio.

◆ Caso a conta de um administrador do Celerra seja eliminada do servidor de diretórios, exclua manualmente a conta de usuário local mapeada no domínio e o diretório base.


Noções básicas da criação dos nomes de contas de usuários locaisQuando uma conta de usuário local é mapeada automaticamente de um usuário do domínio, o Celerra atribui a ela um nome com base no nome do servidor de diretórios e no nome do domínio. Quaisquer espaços contidos no nome de usuário serão eliminados.

Solução de problemas em contas de usuários administrativos mapeadas em domínioQuando um usuário administrativo mapeado por domínio faz log-in na Control Station, o nome do domínio fornecido deve ser igual ao nome de domínio ou a um nome de domínio completo que possa ser identificado pelo Celerra, ou seja, o nome definido na página Domain Settings do Celerra Manager. Caso contrário, o usuário não poderá fazer log-in.

Os formatos compatíveis de log-in de usuários mapeados por domínio são:

◆ <nome do domínio>\<usuário> (por exemplo, minhaempresa\ana)

◆ <nome de domínio completo>\<usuário> (por exemplo, minhaempresa.com\ana)

◆ <usuário>@<nome do domínio> (por exemplo, ana@minhaempresa)

◆ <usuário>@<nome do domínio completo > (por exemplo, [email protected])

Observação: Os usuários só podem fazer log-in em um único domínio. Conseqüentemente, minhaempresa e minhaempresa.com são tratados como o mesmo domínio.

Solução de problemas na importação de certificadosOs certificados são usados tanto pelo Data Mover quanto pela Control Station para identificar um ou ambos os lados de uma conexão com SSL ativada. O Data Mover pode importar certificados codificados usando o formato Distinguished Encoding Rules (DER), também conhecido como formato X.509 de código binário ou formato Privacy Enhanced Mail (PEM), também conhecido com formato X.509 com codificação Base64. A Control Station pode importar certificados codificados usando o formato PEM.

Um arquivo de certificado no formato DER é composto por dados binários. O formato PEM utiliza codificação Base64 para transformar texto binário em texto ASCII, traduzindo cada 6 bits em um determinado caractere ASCII e incluindo o texto do certificado (até 64 caracteres) nas linhas BEGIN CERTIFICATE e END CERTIFICATE. Dependendo da origem do arquivo do certificado, o certificado de codificação PEM pode ser precedido por outro texto que relacione o conteúdo do certificado. A tradução de texto binário para texto impede que os dados sejam modificados quando estiverem em trânsito entre sistemas, por exemplo, por e-mail.


Importando um certificado no Data MoverTentando exportar um certificado vencido

Se você receber uma mensagem de erro ao importar um certificado, verifique se a data e a hora de validade do certificado já passaram. Um certificado expirado não pode ser importado no Data Mover.

Importando um certificado codificado em DER

Se você receber uma mensagem de erro ao importar para o Data Mover um certificado codificado em DER, faça o seguinte:

◆ Verifique se o certificado é válido usando uma ferramenta como o OpenSSL ou o Microsoft Certificate Server. Para usar essas ferramentas, o arquivo deve ter uma extensão válida tal como .der, .cer ou .crt.

◆ Se o certificado não for válido, a ferramenta reportará um erro; o arquivo do certificado estará provavelmente corrompido e deverá ser substituído com uma cópia não corrompida.

◆ Se o certificado for válido, use a ferramenta para exportá-lo no formato PEM, verifique se o certificado codificado em PEM é válido e importe esta versão.

Importando um certificado codificado em PEM

Se você receber uma mensagem de erro ao importar para o Data Mover um certificado codificado em PEM, faça o seguinte:

◆ Verifique se o formato PEM do arquivo do certificado está correto.

◆ Verifique se o certificado é válido usando uma ferramenta como o OpenSSL ou o Microsoft Certificate Server. Se o certificado não for válido, a ferramenta reportará um erro; o arquivo do certificado estará provavelmente corrompido e deverá ser substituído com uma cópia não corrompida.

Importando um certificado na Control StationA Control Station não retornará um erro caso você faça upload de um certificado expirado. Porém, a Control Station não usará um certificado vencido para verificar o certificado recebido do servidor de diretórios baseado em LDAP.

É possível determinar a data de validade do certificado instalado atualmente exibindo as propriedades do certificado no campo SSL Certificate.

Mensagens de erro A partir da versão 5.6, todas as novas mensagens de eventos, alertas e status fornecem informações detalhadas e ações recomendadas para ajudá-lo a solucionar a situação.

Para visualizar detalhes de mensagens, use qualquer um dos seguintes métodos:

◆ Celerra Manager:

• Clique com o botão direito do mouse na mensagem de evento, alerta ou status e selecione para visualizar Event Details, Alert Details ou Status Details.


◆ CLI do Celerra:

• Use o comando nas_message -info <message_id> para recuperar as informações detalhadas de determinado erro.

◆ EMC Celerra Network Server Error Messages Guide:

• Use este guia para localizar informações sobre mensagens que estejam no formato de mensagem da versão anterior.

◆ Powerlink:

• Use o texto encontrado na descrição breve da mensagem de erro para pesquisar a base de conhecimentos no Powerlink. Uma vez conectado ao Powerlink, vá para Suporte > Pesquisa na Base de Conhecimentos > Pesquisar tudo.

Programas de treinamento para o clienteOs programas de treinamento para clientes da EMC foram projetados para ajudá-lo a entender como os produtos de armazenamento da EMC funcionam em conjunto e se integram com seu ambiente para aumentar o investimento realizado emtoda a infra-estrutura. Esses programas trazem treinamento on-line, bem como em laboratórios modernos, convenientemente localizados em todo o mundo. Os programas de treinamento para clientes da EMC são desenvolvidos e ministrados por especialistas da EMC. Para obter informações sobre o programa e inscrições, efetue log-in no Powerlink, nosso site da Web para clientes e parceiros, e selecione o menu Treinamento.

../ErrorMsgs/index.htm

../ErrorMsgs/index.htm




Apêndice A: Conjuntos de codificações do SSL aceitosTabela 10 na página 68 lista os conjuntos de codificações aceitos pelo Celerra. A seguinte lista dá os nomes dos conjuntos de codificações do SSL ou TLS relacionados às especificações pertinentes e seus equivalentes no OpenSSL. Deve-se observar que alguns nomes de conjuntos de codificações não incluem a autenticação usada, por exemplo, DES-CBC3-SHA. Nesses casos, é usada a autenticação RSA.

Aplicam-se as seguintes restrições:

◆ Criptogramas NULL e todos os conjuntos de codificações ADH vêm desabilitados por padrão (porque não permitem autenticação).

◆ Alguns conjuntos de codificações não serão aceitos pelo Celerra por causa do tamanho do certificado (se o certificado apresentado pelo Data Mover tiver uma chave de 2.048 bits, os criptogramas com uma chave menor serão rejeitados).

Tabela 10 Conjuntos de codificações do SSL aceitos (página 1 de 2)

Protocolo Nome da especificação Nome OpenSSL

Conjuntos de codificações do SSL v3.0

SSL_RSA_WITH_NULL_MD5 NULL-MD5

SSL_RSA_WITH_NULL_SHA NULL-SHA

SSL_RSA_WITH_DES_CBC_SHA DES-CBC-SHA

SSL_RSA_WITH_3DES_EDE_CBC_SHA DES-CBC3-SHA

SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-RSA-DES-CBC-SHA

SSL_DHE_RSA_WITH_DES_CBC_SHA EDH-RSA-DES-CBC-SHA

SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA EDH-RSA-DES-CBC3-SHA

SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 EXP-ADH-RC4-MD5

SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA EXP-ADH-DES-CBC-SHA

SSL_DH_anon_WITH_DES_CBC_SHA ADH-DES-CBC-SHA


Conjuntos de codificações do TLS v1.0

TLS_RSA_WITH_NULL_MD5 NULL-MD5

TLS_RSA_WITH_NULL_SHA NULL-SHA

TLS_RSA_EXPORT_WITH_RC4_40_MD5 EXP-RC4-MD5

TLS_RSA_WITH_RC4_128_MD5 RC4-MD5

TLS_RSA_WITH_RC4_128_SHA RC4-SHA

TLS_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-DES-CBC-SHA

TLS_DH_anon_WITH_RC4_128_MD5 ADH-RC4-MD5

TLS_DH_anon_WITH_3DES_EDE_CBC_SHA ADH-DES-CBC3-SHA

Conjuntos de codificações AES de RFC3268, ampliando TLS v1.0

TLS_RSA_WITH_AES_128_CBC_SHA AES128-SHA

TLS_RSA_WITH_AES_256_CBC_SHA AES256-SHA

TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE-RSA-AES128-SHA

TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE-RSA-AES256-SHA

TLS_DH_anon_WITH_AES_128_CBC_SHA ADH-AES128-SHA

TLS_DH_anon_WITH_AES_256_CBC_SHA ADH-AES256-SHA

Additional Export 1024 e outros conjuntos de codificações

Observação: Essas codificações também podem ser usadas no SSL v3.

TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA EXP1024-DES-CBC-SHA

TLS_RSA_EXPORT1024_WITH_RC4_56_SHA EXP1024-RC4-SHA

Conjuntos de codificações do SSL v2.0

SSL_CK_DES_64_CBC_WITH_MD5 DES-CBC-MD5

SSL_CK_DES_192_EDE3_CBC_WITH_MD5 DES-CBC3-MD5

Tabela 10 Conjuntos de codificações do SSL aceitos (página 2 de 2)

Protocolo Nome da especificação Nome OpenSSL


Apêndice B: Noções básicas da configuração do servidor de diretóriosEste apêndice oferece informações sobre ferramentas que podem ser usadas para entender melhor a estrutura de informações de sua empresa no servidor de diretórios baseado em LDAP e dicas sobre como interpretar essas informações. Você deve compreender onde seus usuários e grupos estão localizados. Use essas informações para configurar o servidor de diretórios conforme descrito em "Configurando o uso de um servidor externo de diretórios na identificação e autenticação de usuários administrativos" na página 29 e para configurar a conexão entre o cliente baseado em LDAP da Control Station e o servidor de diretórios, realizada por meio de Administradores > guia Domain Settings, no Celerra Manager.

Há várias ferramentas disponíveis para gerenciar serviços de diretório baseados em LDAP, incluindo:

◆ "Usuários e computadores do Active Directory" na página 70

◆ "Ldap Admin" na página 78

Usuários e computadores do Active Directory As contas de usuário e grupo do Active Directory podem ser gerenciadas com o snap-in do MMC que acompanha o ADUC (Active Directory Users & Computers, usuários e computadores do Active Directory). Esse snap-in é instalado automaticamente em cada controlador de domínio Windows. É possível acessar essa ferramenta em Control Panel (painel de controle) >Administrative Tools (ferramentas administrativas) > Active Directory Users & Computers (usuários e computadores do Active Directory).

A Tabela 11 na página 70 relaciona as informações que você precisa saber para se conectar com sucesso ao Active Directory.

Tabela 11 Informações necessárias para se conectar com o servidor de diretórios do Active Directory

Informações necessárias de conexão Seus valores

Nome de domínio completo (também conhecido como o nome distinto de base)

Nome de host ou endereço IP do controlador de domínio/servidor de diretórios principal

Nome de host ou endereço IP do controlador de domínio/servidor de diretórios secundário

Nome da conta (também conhecido como o nome distinto de vinculação)


Etapa Ação

1. Abra o ADUC e (se necessário) se conecte ao domínio. Clique com o botão direito do mouse no nome do domínio e depois selecione Find (Procurar) no menu.


2. Identifique o usuário do domínio que será um usuário administrativo do Celerra. Para localizar o perfil do usuário, digite seu nome no campo Find (Procurar) e clique em Find Now (Procurar agora).

Etapa Ação


3. Adicione o caminho X.500 às informações exibidas do usuário, selecionando View ( xibir) > Choose Columns (Escolher colunas).

E

4. Selecione X500 Distinguished Name (Nome distinto X500) no campo Columns available (Colunas disponíveis) e clique em Add (Adicionar).

Etapa Ação


5. A janela Procurar agora mostra o nome distinto X.500 do usuário administrativo. O nome distinto X.500 contém o nome de usuário (CN=Joe Muggs) e o caminho para o recipiente na estrutura de diretórios em que o usuário está localizado. CN=Users,DC=derbycity,DC=local. Registre o caminho.

Etapa Ação


6. Verifique se todos os outros usuários administrativos do Celerra usam o mesmo caminho:

• Repetindo a pesquisa por todas as contas de usuários administrativos do Celerra

ou

• Navegando para essa área do diretório no ADUC e localizando todas as contas de usuários administrativos do Celerra

7. Repita os passos 1 a 6 para localizar o caminho para o recipiente na estrutura de diretório em que os grupos estão localizados.

Se os caminhos de usuário e grupo forem ambos CN=Users,DC=<domain component>,DC=<domain component>[, DC=<domain component>…] (por exemplo, CN=Users,DC=derbycity,DC=local), você pode usar a opção Active Directory padrão na guia Configurações de domínio. Essa opção pressupõe que os usuários e grupos estão localizados no recipiente padrão (CN=Users), de modo que não seja preciso especificar o caminho de pesquisa para o usuário ou grupo.

Etapa Ação


8. Os usuários podem não estar no recipiente padrão (CN=Users). Em vez disso, podem se encontrar em outros recipientes ou unidades organizacionais dentro do diretório como, por exemplo, em Celerra Users. Nesse caso, é necessário usar a opção Custom Active Directory (Active Directory personalizado) na guia Domain Settings (Configurações de domínio) e introduzir manualmente os caminhos de pesquisa.

9. Os grupos podem não estar no recipiente padrão (CN=Users) e não precisam estar localizados com os usuários. Em vez disso, eles podem se encontrar dentro de outros recipientes e unidades organizacionais no diretório.

Etapa Ação


10. A pesquisa de usuários e grupos de LDAP se inicia com um caminho especificado, pesquisando tal recipiente e todos aqueles abaixo dele. Se os grupos e usuários administrativos do Celerra não estiverem localizados dentro do mesmo recipiente ou unidade organizacional, é necessário usar a interseção (partes comuns) de seus caminhos coletivos ao especificar os caminhos de pesquisa de usuários e grupos. Em alguns casos, é preciso que seja a raiz do domínio. Por exemplo, suponha que os usuários administrativos do Celerra estão armazenados nos seguintes locais do Active Directory:

Caminho 1: CN=Users,DC=derbycity,DC=local

Caminho 2: OU=Celerra Users,OU=EMC Celerra,DC=derbycity,DC=local

Para que o Celerra encontre todos os usuários administrativos, é necessário usar a interseção dos dois caminhos como seu caminho de pesquisa, ou seja, a raiz do domínio DC=derbycity,DC=local.

Digite esse valor no campo User Search Path (Caminho de pesquisa de usuários) na guia Domain Settings (Configurações de domínio).

11. Use de novo a janela Procurar para determinar o caminho X.500 completo da conta que será usada na conexão entre a Control Station do Celerra e o diretório. Nesse caso, não se deve remover o nome de usuário do caminho, visto que ele está sendo especificado para uma conta individual.

Se você estiver usando a opção Default Active Directory (Active Directory padrão) na guia Domain Settings (Configurações de domínio) digite apenas o nome da conta, por exemplo Celerra LDAP Binding, no campo Account Name (Nome da conta). Não é preciso fornecer a sintaxe X.500, pois o Celerra monta um caminhoX500 completo.

Se você estiver usando a opção Custom Active Directory (Active Directory personalizado) na guia Domain Settings (Configurações de domínio) digite o caminho X.500 completo no campo Distinguished Name (Nome distinto).

Etapa Ação


Ldap AdminAo contrário do Active Directory, outros servidores de diretórios baseados em LDAP geralmente não vêm com uma interface gráfica de gerenciamento. Nesse caso, é necessário usar uma ferramenta como o LDAP Admin para encontrar os caminhos de pesquisa apropriados nos servidores LDAP. A ferramenta grátis Ldap Admin (um gerenciador de LDAP do Windows, disponível em ldapadmin.sourceforge.net) permite que você navegue, pesquise, modifique, crie e elimine objetos em um servidor LDAP. A função de cópia para a área de transferência do Ldap Admin é útil em especial para transferir com facilidade os valores para a guia Domain Settings (Configurações de domínio) do Celerra Manager.

A Tabela 12 na página 78 relaciona as informações necessárias ao sucesso da conexão com um Active Directory personalizado ou outro servidor de diretórios baseado em LDAP como o OpenLDAP.

Tabela 12 Informação necessária para conectar-se a um Active Directory personalizado ou outro servidor de diretórios baseado em LDAP

Informações necessárias de conexão Seus valores

Nome de domínio completo (também conhecido como o nome distinto de base)

Nome de host ou endereço IP do servidor de diretórios principal

Nome de host ou endereço IP do servidor de diretórios secundário

Nome distinto (também conhecido como o nome distinto de vinculação).

Caminho de pesquisa de usuários

Atributo de nome de usuário

Caminho de pesquisa de grupos

Atributo de nome de grupo

Classe de grupo

Membro de grupo


Etapa Ação

1. Inicie o Ldap Admin e crie uma nova conexão. Clique em Test connection (Testar conexão) para verificar a conexão.


2. Abra a conexão com o servidor LDAP, clique com o botão direito do mouse no nome do domínio e depois selecione Search (Pesquisar) no menu.

Etapa Ação


3. Identifique o usuário do LDAP que será um usuário administrativo do Celerra. Para localizar o perfil do usuário, digite seu nome no campo Name (Nome) e clique em Start (Iniciar).

Etapa Ação


4. Clique com o botão direito do mouse no usuário apropriado na lista de resultados e selecione Go to (Ir para) no menu. Você usará esse usuário para determinar os caminhos de pesquisa de usuário e grupo. Feche a janela Search (pesquisar).

Etapa Ação


5. Na janela principal do Ldap Admin, observe que a barra de status contém o DN (Distinguished Name, nome distinto) da pasta na qual o usuário está localizado. Muitos servidores LDAP seguem a convenção descrita em RFC2307 e colocam os usuários em um recipiente People.

Etapa Ação


6. Clique com o botão direito do mouse na pasta e depois selecione Copy dn to Clipboard (Copiar dn para a área de transferência) no menu.

7. Na guia Domain Settings (Configurações de domínio) selecione a opção Other Directory Servers (Outros servidores de diretório). Cole o valor de DN no campo User Search Path (Caminho de pesquisa de usuários).

Etapa Ação


8. Verifique se todos os outros usuários administrativos do Celerra usam o mesmo caminho:

• Repetindo a pesquisa por todas as contas de usuários administrativos do Celerra

ou

• Navegando para essa área do diretório no Ldap Admin e localizando todas as contas de usuários administrativos do Celerra

Etapa Ação


9. Repita os passos 2 a 8 para pesquisar o caminho em um nome de grupo para o recipiente na estrutura de diretório onde os grupos estão localizados. Ao pesquisar por nome de grupo, é necessário usar uma pesquisa avançada e fornecer um filtro de pesquisa no formato cn=<nome do grupo>. Uma vez concluída a pesquisa, clique com o botão direito do mouse no grupo apropriado na lista de resultados e selecione Go to (ir para) no menu.

10. A pesquisa de usuários e grupos de LDAP se inicia com um caminho especificado, pesquisando tal recipiente e todos aqueles abaixo dele. Se os grupos e usuários administrativos do Celerra não estiverem localizados dentro do mesmo recipiente ou unidade organizacional, é necessário usar a interseção (partes comuns) de seus caminhos coletivos ao especificar os caminhos de pesquisa de usuários e grupos. Em alguns casos, é preciso que seja a raiz do domínio. Por exemplo, suponha que os usuários administrativos do Celerra estão armazenados nos seguintes locais do LDAP:

Caminho 1: OU=People,DC=openldap-eng,DC=local

Caminho 2: OU=Celerra Users,OU=EMC Celerra, DC=openldap-eng,DC=local

Para que o Celerra encontre todos os respectivos usuários administrativos, é necessário usar a interseção dos dois caminhos como seu caminho de pesquisa, ou seja, a raiz do domínio DC=openldap-eng,DC=local.

Etapa Ação


11. Use a janela Search para localizar a conta de usuário que será usada na conexão entre a Control Station do Celerra e o diretório. Clique com o botão direito do mouse no nome de conta e selecione Copy dn to Clipboard (Copiar dn para a área de transferência). Cole o valor de DN no campo Distinguished Name (Nome distinto) na guia Domain Settings (Configurações de domínio), por exemplo, uid=celerra,ou=People.

Etapa Ação



Índice remissivo

Aacesso administrativo baseado em funções 10

criando 22padrão 24

auditoria 9autenticação CIFS de Kerberos 13

Bbanner de log-in 8

personalizando 36

Ccertificados de CA

adquirindo 50distribuindo 56excluindo 61exibindo 54exibindo propriedades 60gerando 53importando 27, 53listando 50, 60obtendo 27, 42

certificados de chave pública 15certificados de CA 27criando 42eliminando 59enviando a solicitação de certificado à CA 46exibindo 58gerando uma solicitação por conjunto e certificado de

chaves 43importando um certificado assinado pela CA 47listando 58personas 26

certificados, chave públicaconfigurações de segurança NFS. 13Control Station

acesso administrativo baseado em funções 10alterações no sistema operacional Linux 7auditoria 9banner de log-in 8certificados SSL (X.509) 12configurando o uso do servidor de diretórios 29gerenciamento dos serviços de rede 8identificação e autenticação de usuários administrativos

10MOTD 8política de qualidade de senha 11segurança 3, 7segurança para a infra-estrutura 8segurança para controle de acesso 10segurança para proteger dados 12tempo limite de sessão 8usando como CA 42usando servidores de diretórios baseados em LDAP 10

cookie 7, 9

credenciais estilo Windows 14

DData Mover

autenticação CIFS de Kerberos 13certificados SSL (X.509) 15configurações de segurança NFS 13credenciais estilo Windows para usuários UNIX 14gerenciamento de SNMP 14gerenciamento dos serviços de rede 13PKI 15políticas de acesso 14segurança 3, 7segurança para proteger a infra-estrutura 13segurança para proteger dados 15

Ggerenciamento de SNMP 14gerenciamento dos serviços de rede 8, 13

Iidentificação e autenticação de usuários administrativos 10

planejamento 16suporte de interface 16

Infra-estrutura de chave pública, consulte PKI

Mmensagem do dia 8

criando 37MOTD 8

Oopções da interface do usuário 3

Ppersonas

fornecendo um certificado 42gerando conjunto de chaves 26importando certificado 26solicitando certificado assinado 26

PKI 39políticas de acesso 14privilégios administrativos 10, 16

SSecure Socket Layer, consulte SSLsenhas

alterando o padrão 25definindo a política usando um script 32definindo configurações específicas da política 33definindo expiração 33política de qualidade 11, 25

servidor de diretórios baseado em LDAPferramentas 70solução de problemas 63

90 de 92 Guia de configuração de segurança no EMC CelerraVersão 5.6

usando para a identificação e autenticação de usuários administrativos 10, 29

SHA1 7, 9solução de problemas 62

conexão da Control Station com o servidor de diretórios 63

configurando uma sessão SSL 63contas de usuários administrativos mapeadas por

domínio 65contas locais de usuários administrativos 64criando uma conta de vinculação 63

SSL 21alterando a versão do protocolo 40alterando o conjunto de codificações 40conjuntos de codificações aceitos 68solução de problemas 63usando certificados com HTTP 15, 39usando certificados com LDAP 15, 39usando certificados com o Celerra Manager 12usando certificados para conexão entre a Control Station

e servidores de diretório baseados em LDAP 12suporte de checksum 7, 9

Ttempo limite de sessão 8

alterando 35configurando 34desabilitando 35

tokens de sessão 7, 9alterando o valor secreto SHA1 38

Uusuários administrativos

acessando o Celerra 18criando 18criando funções 22criando grupos 22identificando e autenticando com um servidor de

diretórios 19mapeamento local versus mapeamento por domínio 18padrão 16solução de problemas 64, 65

Vverificação de certificado 21


Observações

Sobre este documentoComo parte deste esforço para melhorar e aprimorar continuamente o desempenho e os recursos da linha de produtos do Celerra Network Server, a EMC lança periodicamente novas versões de hardware e software Celerra. Portanto, algumas funções descritas neste documento podem não ser compatíveis com todas as versões dos produtos de software ou hardware Celerra atualmente em uso. Para obter as informações mais atuais sobre os recursos do produto, consulte as notas da versão de seu produto. Se seu sistema Celerra não oferece alguma função descrita neste documento, entre em contato com seu Representante de Atendimento ao Cliente EMC para obter um upgrade de hardware ou uma atualização de software.

Comentários e sugestões sobre documentaçãoSuas sugestões nos ajudarão a aprimorar a precisão, a organização e a qualidade geral da documentação do usuário. Envie uma mensagem para [email protected] com suas opiniões sobre este documento.

Copyright © 1998 -2008 EMC Corporation. Todos os direitos reservados.

A EMC acredita na precisão das informações veiculadas nesta publicação no momento em que elas foram publicadas. As informações estão sujeitas a alteração sem prévio aviso.

AS INFORMAÇÕES DESTA PUBLICAÇÃO SÃO FORNECIDAS "COMO ESTÃO". A EMC CORPORATION NÃO FORNECE NENHUM TIPO DE REPRESENTAÇÃO OU GARANTIA COM RELAÇÃO ÀS INFORMAÇÕES CONTIDAS NESTA PUBLICAÇÃO E ESPECIFICAMENTE SE ISENTA DE GARANTIAS IMPLÍCITAS DE COMERCIALIZAÇÃO OU ADEQUAÇÃO A UM PROPÓSITO ESPECÍFICO.

O uso, cópia e distribuição de qualquer software EMC descrito nesta publicação exigem uma licença de software aplicável.

Para obter as listagens mais atualizadas de nomes de produtos da EMC, consulte EMC Corporation Trademarks em EMC.com.

Todas as outras marcas comerciais aqui utilizadas pertencem a seus respectivos proprietários.

Versão 5.6 92 de 92

Documents

Guia de configuração de segurança no EMC Celerra · 1 de 92 Índice Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .