Todos sabemos que o serviço de DNS mal configurado trás enormes problemas a funcionalidade de seu domínio. Pesquisando na internet, achei esse excelente site que faz a análise de toda a configuração dos serviços de DNS de sua infraestrutura, baseado em melhores práticas.
Link para o Site: IPOK
Com a Microsoft anunciando que a partir de agora somente irá lançar Sistemas Operacionais para servidores apenas na plataforma 64-bits, alguns administradores de rede sentem que estão sendo forçados a migrar de arquitetura sem razão e sem escolha.
Tenho que dizer que concordo em parte com essa afirmação, realmente uma rede pequena onde não há grandes necessidades de recursos computacionais, não tem a necessidade de migrar de arquitetura apenas para manter seus Sistemas Operacionais atualizados.
Porém, essas pessoas desconhecem que mesmo a mais simples tarefa operacional de seus servidores pode ser mais vantajosa se estiver rodando em um ambiente com arquitetura 64-bits.
O artigo no link abaixo, descreve as vantagens de ter seu ambiente do Active Directory sendo executado em 64-bits.
Essa foi complicada de resolver. Em um determinado ambiente, após a instalação do Service Pack 3 do Windows XP, o equipamento parava de responder a alguns tipos de requisições de rede, como por exemplo uma simples requisição de ping.
Os equipamentos remotos não conseguem “pingar” a máquina com o Service Pack 3 instalado. Entretanto, a máquina com o SP3 consegue acessar normalmente a rede.
As configurações de firewall estão corretas na máquina com o SP3, inclusive com regras que permitem a conexão do protocolo ICMP (usado pelo ping), tanto de entrada como saída.
Após fazer uma breve avaliação do ambiente, identifiquei que existem algumas GPO´s aplicadas ao serviço de firewall do Windows, liberando algumas portas e restringindo outras. Fiz uma pesquisa na internet e achei o problema.
O administrador desse ambiente criou essas GPO´s utilizando um modelo administrativo do Windows Xp de uma versão mais antiga, e com isso, as permissões padrões de acesso a interface WMI não são compatíveis com algumas das alterações feitas com o SP3 do windows XP. Para resolver isso, o administrador tem de excluir essas políticas e criá-las novamente utilizando um arquivo de modelo mais recente ou então, como “workaround” pode-se executar o seguinte comando no prompt de comando (com privilégios de administrador):
SC sdset SharedAccess D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)
Esse comando irá resetar as permissões padrões dos componentes que estão com problemas. Após isso, reinicie o computador que tudo volta ao normal.
Todos sabemos da utilidade que dispositivos com interface USB podem fornecer. Seja o simples fato de fazer backups de arquivos em um Pen Drive, copiar aqueles arquivos de mídia em seu Ipod ou mesmo carregar a bateria do seu celular.
A verdade é que hoje em dia, devido ao baixo custo, o uso de dispositivos de armazenamento Usb creceram vertiginosamente. É possivel comprar um pen drive de 8 Gb por menos de R$ 40,00.
Com isso, cresce nas empresas uma preocupação a mais. Como garantir que os usuários não copiem arquivos confidenciais nesses dispositivos Usb? Imagine uma empresa de softwares que tenha uma cópia dos seus fontes “vazados” na internet por um funcionário. O prejuízo seria inestimável.
Felizmente, existem mecanismos para os administradores de redes coibirem a utilização desses dispositivos em ambientes corporativos. Recentemente, encontrei um artigo da Microsoft que trata dessa questão, e ensina a desativar o uso de dispositivos de armazenamento Usb. Com essas informações, os administradores podem criar GPO’s ou scripts e implementar isso em sua rede.
O artigo pode ser encontrado neste link.
O Microsoft Isa Server 2006 é uma ferramenta de controle, otimização e proteção de rede. Ela age como servidor de firewall e proxy da sua rede, além de ter um poderoso recurso de cache, o que em muitos casos pode diminuir a utilização do seu link de Internet.
A partir da versão 2004 do produto, o recurso de Log foi aprimorado permitindo inclusive que acompanhemos o tráfego de dados em modo real-time.
Em contrapartida, esse recurso tem um pequeno problema. Caso um usuário acesse alguma página de internet, no log, será gravado o IP do site acessado, e não o endereço real do site. Veja o exemplo abaixo:
No campo URL, podemos observar que consta o IP do site, e não o endereço real. Se pensarmos de modo “gerencial”, essa informação acaba não nos servindo muito, certo ? Já existem diversas alternativas comerciais que modificam esse comportamento e gravam os log’s já com o endereço correto do site.
Procurando na Internet, encontrei um plugin gratuito feito por Tarek Majdalani, um russo que tem o título de MVP da Microsoft em Isa Server. Apos baixar o plugin (aqui):
Pronto, a partir de agora o seu Isa Server irá gerar os log’s das Url’s reais acessadas pelos usuários:
Passei recentemente por um problema muito estranho. Na empresa onde trabalho, recentemente fiz uma instalação do EPM 2007, solução composta pelo MOSS2007 e pelo Project Server 2007. A parte mais complicada foi a de migrar os dados da versão antiga do EPM 2003 para o novo farm.
Após um dia inteiro de trabalho, a migração foi concluída com sucesso. Os testes preliminares pós-migração foram feitos e tudo estava funcionando perfeitamente.
Alguns dias depois, quando este farm entrou em produção, os usuários estavam encontrando problemas ao acessar algumas páginas do Project Server. O erro retornado era:
Aliás, o mais estranho mesmo, era que apenas essa informação era retornada. Nenhum código Html era retornado, apenas a string “403 – Forbidden”. Executando algumas ferramentas de tracing, observei que antes dessa mensagem, o servidor respondia com dois pacotes de erro 401.1 do IIS.
Partindo disso, podemos identificar que o problema está relacionado a autenticação do IIS. Se um usuário tivesse privilégios de Administrador do servidor onde estava instalado esse EPM entrasse nessa mesma página, ele conseguia acessar normalmente. E após isso, todos os outros usuários, mesmos os que estavam com problemas, conseguiam abrir a página.
Estranho não? Pesquisando mais a fundo, consegui identificar um padrão para esse comportamento. Todas as vezes que o pool que executava esse contexto no IIS era reiniciado, o problema voltava a ocorrer.
Após alguns testes, finalmente descobri a razão disso e uma maneira de corrigir. O problema estava ocorrendo porque os usuários do meu domínio não tinham privilégios de leitura nos recursos do sistema usados pelo Sharepoint. Para corrigir isso, adicionei o grupo DOMINIO\Domains Users ao grupo local WSS_WPG do servidor onde esta sendo executado o EPM.
Após um reinício do IIS, as coisas voltaram a funcionar perfeitamente.
Todos os administradores de redes sabem que o Active Directory é um dos melhores serviços que a Microsoft já desenvolveu. Já imaginou como seria manter sua rede sem ele?
Em ambientes pequenos não haveria problemas, agora imagine gerenciar uma rede com 2 mil usuários, separados em 16 sites (filiais) em 3 continentes? Pois é, agradeça todos os dias ao tio Bill por isso.
Pouca gente sabe, mas como tudo no mundo, esse serviço tem algumas limitações técnicas. Esse artigo descreve algumas das limitações que existem no Active Directory atualmente.
Número máximo de objetos: cada controlador de domínio na floresta pode criar aproximadamente 2,15 bilhões de objetos durante sua vida;
Número máximo de SSIDs: aproximadamente 1 bilhão de SSIDs únicas;
Associação de Grupos: cada objeto (conta, grupo) pode fazer parte de no máximo 1.015 grupos. Mais informação sobre isso aqui;
Tamanho de FQDNs: Fully qualified domain names não podem exceder 64 caracteres, incluindo traços e pontos;
Tamanho de Nome de Arquivos: o nome e o path do arquivo não podem exceder 255 caracteres.
A explicação dessa e de outras limitações pode ser encontrada neste link.
Recentemente, fui solicitado a resolver um problema onde um determinado usuário não estava conseguindo identificar quais grupos de segurança um determinado usuário fazia parte.
Entendendo e simulando o problema:
Na situação reportada, um programa de terceiros precisava descobrir se uma conta de usuário fazia parte de um determinado grupo no AD. Para isso, fazia uma consulta através do protocolo LDAP usando um usuário com privilégios mínimos cadastrado neste domínio. Através dessa consulta, o programa lia o atributo memberOf dessa conta. Entretanto, o resultado obtido não era o esperado.
Primeiramente, para identificar se havia algum problema relacionado a maneira como esta equipe estava fazendo essa consulta com o LDAP, tentei atingir o ‘goal’ solicitado (retornar o grupo de usuários de um determinado login) utilizando as próprias ferramentas do Windows. Para isso, usei o utilitário dsget.exe. Esse utilitário nos permite fazer consultas aos medados do Active Directory. Para isso, executei com a seguinte sintaxe:
dsget user “CN=user1,OU=Usuarios,DC=cetil,DC=com,DC=br” -memberof
Vejam que 0 segundo parâmetro é o caminho exato desta conta no Active Directory. Utilizei o parâmetro -memberof para que fosse retornado alista de grupos deste usuário.
Verifiquei que ao executar este comando no contexto do usuário utilizado para fazer as consultas LDAP, apenas o Grupo Primário desta conta era retornado, embora ela faça parte de outros grupos. Porque isso acontece então?
Muito simples. A conta utilizada para fazer essa consulta não possui privilégios suficientes para ler os atributos necessários no Schema do Active Directory. Para resolver isso é muito simples:
1- Abra a guia Active Directoy Users and Computers (dsa.msc) , clique com o botão direito em cima do domínio desejado e escolha a opção Delegate Control;
2- Na tela de boas vindas, clique em Next;
3- Na tela de seleção de grupos e usuários, clique em Adicionar e informe a conta a qual você irá atribuir esse privilégio. Após isso, clique em Next;
4- Na tela Tasks to delegate, escolha a opção Create a custom task to delegate e depois clique no botão Next;
5- Na tela Active Directory Object Type, clique em Only the following objects in folder. Após, habilite na lista o item User Objects e clique em Next;
6- Na janela Permissions, desmarque a opção General e habilite a opção Property-specific. Após isso, habilite a opção Read MemberOf e clique em Next;
7- Na tela final, temos um sumário da operação que será realizada. Clique em Finish para que a operação seja confirmada.
8- A partir de agora, a conta de usuário que você atribuiu terá privilégios para ler o atributo MemberOf do metadados do Active Directory, como podemos identificar na imagem abaixo.
Essa operação pode ser feita para delegar o acesso (leitura ou escrita) a qualquer objeto do schema do Active Directory.
Neste tutorial irei mostrar como fazer para migrar e atualizar o MediaWiki. Neste caso em específico, irei atualizar da versão 1.6.8 para a a última versão disponível, no caso a 1.14.0
Primeiro de tudo, pare faça um backup do banco de dados utilizado pela wiki atualmente. No meu caso, como utilizo o MySQL como servidor de banco, o seguinte comando exportará o banco para um arquivo :
mysqldump.exe –user=Login –password=Senha BancoWiki >bancoWiki.backup.sql
Sendo que :
-Login: usuário com permissões de “Lock Tables” e “Select” no banco especificado;
-Senha: senha do usuário;
-BancoWik: nome do banco de dados utilizado pela Wiki atualmente;
Neste caso, o banco da Wiki foi exportado para o arquivo bancoWiki.backup.sql. Agora, precisamos restaurar esse arquivo no novo servidor de banco de dados (Caso o servidor que você irá utilizar é o mesmo, ignore este passo). No novo servidor, copie o arquivo gerado anteriormente e execute o seguinte comando para restaurar o banco de dados:
mysql -u Login -pSenha BancoWiki < bancoWiki.backup.sql
Tome cuidado com o parâmetro -p, a senha vem logo em seguida a este parâmetro, sem espaço.
Desta maneira, o banco será restaurado.
Após o restore do banco, criar o Website onde a Wiki será executada (irei assumir que isso já esteja pronto).
Fazer uma cópia fiel dos arquivos da Wiki antiga para o local no novo servidor. Isso é necessário para levar os arquivos upados. Após p término, fazer o download da última versão do MediaWiki (1.14.0 no meu caso) e extrair para uma pasta temporária.
Agora é necessário copiar esses arquivos extraídos para a pasta onde estavam os arquivos antigos no novo servidor, sobrepondo quando necessário.
Ao término desta etapa, estaremos com os arquivos da nova versão do MediaWiki, porém com os dados antigos ainda. Agora vem a parte interessante:
-Edite o arquivo “LocalSettings.php” da raiz do diretório da Wiki. Faça as alterações necessárias quanto ao acesso a banco de dados (servidor, login, senha);
-Na raiz da Wiki, renomeie o arquivo “AdminSettings.sample” para “AdminSettings.php”. Após isso, edite ele. Altera as variáveis “$wgDBadminuser” e “$wgDBadminpassword” especificando um usuário e senha com privilégios de leitura/gravação no novo banco de dados.
-Após isso, será necessário executar o script de atualização. O detalhe é que esse script somente pode ser executado através de linha de comando. Acesse o DOS, navegue até a pasta onde o PHP está instalado e execute o seguinte comando:
php <PATH TO WIKI>\maintenance\update.php
Altere o <PATH TO WIKI> informando o caminho onde está a wiki (Ex: C:\Inetpub\wwwroot\wiki.
Dessa maneira, o script será executado e fará a migração dos dados!
Bem-vindo ao meu Site.
Estou re-inaugurando hoje este blog, no qual a partir de agora pretendo manter atualizado com alguns artigos que acho que sejam pertinentes a minha área de atuação profissional. Os assuntos focados aqui são o de uso diário de administradores de redes, profissionais da área de infraestrutura e apaixonados por tecnologia. Portanto, divirtam-se!