Dentro do SharePoint Atualizar as credenciais de conta de segurança

Pav Cherny

Download do código disponível em: ChernySharePoint2009_03.exe(821 KB)

Conteúdo

Serviços e contas de segurança
Serviços e contas de segurança
Um comando para todos os serviços
Passar a distância total
Implantação e usando a solução
Conclusão

Microsoft Windows SharePoint Services (WSS) 3.0 e gerenciamento de segurança do Microsoft Office SharePoint Server (MOSS) 2007 envio até o limite com os serviços e processos de trabalho que dependem de contas de usuário de domínio para oferecer suporte o controle de acesso discricional (DAC) com base no modelo segurança de Windows Server. Na função de contas de segurança, as contas de usuário de domínio sempre tem lutavam atender às necessidades da empresa. Isso se aplica a qualquer ambiente de cliente/servidor e ainda mais portanto farms de servidor dimensão SharePoint, como cada serviço em um farm mantém suas próprias informações de conta e impõe seus próprios procedimentos de atualização específica, independentemente de outros serviços que podem usar as mesmas credenciais. A conta em questão pode ser a mesma conta no Active Directory, mas você ainda precisará atualizar cada serviço individualmente após uma alteração de senha.

Obviamente, primeiro esqueça todos os serviços que usam uma conta. Ele pode ser um desafio para seguir as recomendações de segurança que sugerem usando contas de domínio separados para serviços do SQL Server, serviços de administração central e o timer do SharePoint, pesquisa de serviço e rastreador, provedores de serviços compartilhados (SSPs), pools de aplicativo da Web, serviço Single Sign-on, perfil de importação de usuário e contas de serviços do Excel.

E, obviamente, não há senhas diferentes para cada conta e alterações de senha freqüentes para controlar. Não seria bom mestre esse desafio sem incorrer em sobrecarga administrativa?

Recursos de segurança

Site da Web senhas do Windows SharePoint Services

Nesta segunda parte de uma série de duas partes, abordam aspectos da segurança do SharePoint, especificamente segurança conta manutenção e apresentar uma solução para automatizar as alterações de senha para obter maior segurança e reduzir a sobrecarga administrativa.

A idéia subjacente é relativamente simples: uma solução personalizada pode obter todos os nomes de conta de segurança e senhas usando o modelo de objeto administrativo do SharePoint. A solução pode usar essas informações para fazer logon no Active Directory, alterar as senhas correspondentes por meio de Active Directory Service Interfaces (ADSI) e atualizar serviços todos afetados no farm local.

Dessa forma, os administradores do SharePoint não precisam lidar com senhas de contas de segurança mais. No entanto, não foi tão simples implementando a idéia. No final, eu me vi criar vários componentes, incluindo as extensões de comando Stsadm.exe, páginas de aplicativos para o site de Administração Central do SharePoint 3.0, um serviço do Windows integrada ao SharePoint e uma interface de programação básica para normalizar alterações de senha através de todos os tipos de serviços do SharePoint.

Não tenho tempo suficiente para cobrir todos os serviços do MOSS ainda, mas o protótipo atual oferece suporte a WSS 3.0. Criei um site da Web em sppwd.com que, no futuro próximo, oferecerá os componentes do MOSS e outras atualizações, bem como mais documentação de recursos e interfaces de programação.

O protótipo atual é para fins de teste somente e não deve ser usado em ambientes de produção. Não é totalmente testada, ele Entretanto demonstra que manutenção de conta de segurança do SharePoint não é necessário aumentar a sobrecarga administrativa. O material complementar para nesta coluna, disponível em Downloads de código do TechNet 2009, inclui planilhas, assemblies compilados e código-fonte.

Serviços e contas de segurança

Ter você nunca saber por que você precise usar muitos comandos diferentes para atualizar contas de segurança do SharePoint após alterar uma senha no Active Directory? Em seguida, leia o artigo" Como alterar contas de serviço e senhas de conta de serviço no SharePoint Server 2007 e no Windows SharePoint Services 3.0."

Ele descreve cinco comandos diferentes (updateaccountpassword, SPSEARCH/farmserviceaccount, SPSEARCH/farmcontentaccessaccount, updatefarm­credentials e editssp/ssplogin), e ele ainda não abrangerá todos os aspectos.

Além disso, o script de exemplo deste artigo, enquanto útil como um modelo, apresenta uma configuração de segurança precária porque ele assume que você use a mesma conta e senha para todos os serviços no farm.. Tente adaptando o script para um ambiente de farm em que cada serviço e aplicativo pool usa uma conta de usuário diferente e senha, e você pode enfrentar um grande desafio de script. Mantendo segurança do sistema por meio de scripts não é fácil em um farm do SharePoint.

A razão para as complexidades é encoberta profundidade dentro o design de segurança do SharePoint. Como você aprendeu, usando o comando de enumservices stsadm -o, SharePoint depende de inúmeros serviços, e cada serviço possui dependências de segurança diferentes.

Se você pesquisar o nome do tipo que o comando enumservices retorna para cada serviço no SDK do WSS 3.0, você encontrará que alguns desses serviços não usam nenhuma conta de segurança, enquanto outros podem usar uma conta de segurança único ou exigir várias contas. Por exemplo, serviços relacionados a mensagens e o serviço de diagnóstico não estão associados a informações de conta de segurança, o serviço de Timer do SharePoint usa uma conta de segurança único, o serviço de pesquisa tem uma conta de serviço, bem como uma conta de rastreador e o serviço de aplicativo da Web pode ter várias contas de segurança como há são pools de aplicativos.

E não existe mais. O serviço de administração do SharePoint, por exemplo, deve usar a conta do sistema local, para que ele não requer uma conta de segurança de domínio, mesmo em um farm do SharePoint. Algumas soluções também podem apresentar seus próprios serviços, como o Microsoft Office Project Server (MOPS) 2007. O céu é o limite, considerando que você também pode ter qualquer número de soluções personalizadas com variáveis requisitos de segurança.

Claro, não há nenhuma maneira de aplicar procedimentos de atualização comuns em um portfólio variado de serviços, portanto, não é nenhuma surpresa que SharePoint apresenta um conjunto rico de comandos de atualização. Basicamente, cada solução deve fornecer suas próprias ferramentas individuais e atualizar procedimentos, aumentando a sobrecarga administrativa em proporção ao número de serviços no ambiente do SharePoint. a Figura 1 ilustra a relação entre os serviços do SharePoint e contas de segurança bem como os comandos de atualização aplicável.

Figura 1 relação entre contas de segurança e serviços do SharePoint

Serviços e contas de segurança

A organização de serviços e contas de segurança pode parecer confusa, mas há uma ordem hierárquica aplicada por meio do modelo de objeto SharePoint, como ilustrado na Figura 2 . Na base de todos os serviços do SharePoint é a classe SPService. Esta classe não inclui uma conta de segurança porque, como mencionado anteriormente, nem todos os serviços requerem credenciais. Serviços que necessitam de credenciais podem herdar uma identidade da classe SPWindowsService ou implementar seus próprios.

A Figura 2 hierarquias de herança de serviços do SharePoint

Por exemplo, a classe SPSearchService, herda de uma identidade de processo da classe SPWindowsService e também mantém sua própria conta de rastreador. A classe SPWebService, por outro lado, não precisa uma identidade de processo SPWindowsService­based, portanto, ele herda diretamente da classe SPService e mantém suas próprias contas de segurança na forma de identidades do pool de aplicativos.

Há vários fatos importantes fora da hierarquia de herança. Primeiro e foremost, existem realmente que muitas maneiras diferentes para lidar com contas de segurança em um farm do SharePoint. Serviços do SharePoint principalmente usam identidades de processo ou identidades de pool de aplicativos. Esses tipos de identidade são muito semelhantes em relação ao atualizar informações de segurança, porque a classe SP­ApplicationPool é derivada da classe SPProcessIdentity.

Em segundo lugar, as identidades dos serviços do SharePoint estão disponíveis para aplicativos administrativos e scripts personalizados. É possível ir para cada serviço individual do SharePoint por meio da classe base SP­Service para acessar os nomes de logon e senhas.

Em terceiro lugar, o modelo de objeto SharePoint já sabe como lidar com identidades do processo e identidades de pool de aplicativo. Entre outras coisas, o modelo de objeto inclui a lógica para definir e atualizar as senhas, portanto, você não precisará reinventar a roda ao usar ferramentas personalizadas. Você só precisará chamar os métodos necessários, embora isso não é sem obstáculos porque o SDK do WSS não explicar as dependências muito bem.

Atualizar contas de segurança requer a mais de definir as propriedades nome de usuário e senha (ou SecurePassword) de identidades de processo (SPProcess­Identity) ou identidades de pool de aplicativos (SPApplicationPool) e chamando o método Update. Isso não coloca o farm novamente em estado operacional. O método Update apenas atualiza a senha no banco de dados de configuração do SharePoint, mas ele não atualiza os serviços base ou pools de aplicativo.

É importante ter em mente que os recursos afetados existem fora do ambiente de SharePoint. Serviços do Windows mantêm suas informações de segurança no banco de dados do Service Control Manager (SCM), localizadas no registro em cada servidor em HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services.

Aplicativos da Web, por outro lado, estão recursos do IIS. Para atualizá-los, você deve chamar método de implantação da identidade juntamente com o método Update. O método de implantação dispara a lógica de SharePoint para atualizar todos os servidores no farm por meio de chamadas de API locais e trabalhos de timer do SharePoint. Ele também altera chave de credencial do farm se a alteração afeta a senha do pool de aplicativos para o aplicativo Web da Administração Central (SPWebService.AdministrationService).

Essa alteração de senha também afeta o serviço de Timer do SharePoint, que está intimamente ligado com a infra-estrutura administrativa, portanto, você não precisa atualizar o serviço de Timer do SharePoint diretamente. Para obter detalhes sobre os procedimentos padrão para realizar alterações de senha em um ambiente de farm com vários servidores, leia minha coluna do mês passado " Manter credenciais de conta de segurança."

Um comando para todos os serviços

Apesar das complexidades, a boa notícia é que o modelo de objeto SharePoint cuida de todos os detalhes de atualização detalhes em um server farm. Precisamos apenas tirar proveito dos recursos existentes em uma extensão de STSADM personalizada para implementar um comando de atualização única para todos os serviços:

stsadm -o changepwd -user DOMAIN\Account -oldpwd old_p@ssw0rd
 -newpwd new_ p@ssw0rd

Não é realmente necessário para vários comandos de atualização diferente. Afinal, é claro que você deve alterar a senha em todos os locais, incluindo do Active Directory, banco de dados de configuração, o banco de dados de serviços de Windows, IIS e que outros repositórios de credencial um determinado serviço pode usar.

Ele não uma opção para deixar uma senha desatualizada atrás. Com uma extensão de comando cuidar de todas as dependências implica alterações de senha mais consistentes em todos os recursos afetados e menos problemas de senha-relacionados no farm.

Além disso, a implementação de uma extensão de STSADM é fácil e divertido. Apenas execute os passos descritos no SDK do WSS sob o título" Como: Estender o utilitário STSADM." Também recomendo que você fazer check-out Blog do Carlos Lapointe Para exemplos excelentes e uma lista impressionante de extensões útil que pode ser útil em seu trabalho diário como um administrador do SharePoint.

Com os STSADM implementação detalhes fora do caminho, podem se concentrar nossos esforços como implementar a solução real, que é difícil suficiente considerando que podem de serviços do SharePoint usar qualquer número de credenciais. Isso pode incluir identidades de processo, identidades de pool de aplicativos e outras contas.

Não é apenas possível saber as dependências de segurança de cada serviço do SharePoint com antecedência. Você pode obter imediatamente com os serviços padrão do WSS e MOSS, mas uma solução realmente útil deve também oferecer suporte a serviços personalizados com requisitos diferentes.

Lidar com várias melhor é realizada por meio de uma API. A API desmembra a extensão de comando dos serviços base e dessa maneira permite aos desenvolvedores conecte seus próprios componentes que contém a lógica para executar alterações de senha para seus serviços.

Chamo esses componentes conectáveis proxies de serviço. Por contar com esses componentes de proxy, a extensão de comando pode acomodar qualquer serviço, os desenvolvedores não precisam fornecer ferramentas de atualização de senha adicional mais e os administradores não devem lidar com complexidades de segurança de serviços subjacentes mais. Assim, diminui a carga administrativa para manter contas de segurança em um ambiente do SharePoint.

Nosso proxy do serviço API deve fazer duas coisas básicas: ele deve habilitar a extensão de comando para determinar as contas de segurança de cada serviço com suporte e ele deve habilitar a extensão de comando atualizar as senhas associadas. Da mesma forma, a API requer dois métodos: Resolve­Identities e ChangePassword.

Em primeiro lugar, a extensão de comando enumera todos os serviços no farm. usando a coleção SPFarm.Local.Services. Para cada tipo de serviço, a extensão de comando também dinamicamente carrega um proxy de serviço, registrado para o serviço em um arquivo de configuração com base em XML que segue a convenção de nomenclatura passwordproxies.*.xml (como passwordproxies.WSSProxies.xml).

Em seguida, a extensão do comando chama o método ResolveIdentities o proxy de serviço registrado, passando uma referência ao objeto serviço. O componente proxy extrai as contas de segurança desejado do serviço de base e retorna essa informação para a extensão de comando.

O resultado é uma associação entre contas de segurança e serviços que é o contrário da associação estabelecida no modelo de objeto SharePoint. Em vez de serviços sendo os principais das contas de segurança, contas de segurança são agora os pais dos serviços, conforme ilustrado na Figura 3 . Essa arquitetura reflete a relação real entre serviços e contas de segurança melhor.

A Figura 3 reverter a relação entre contas de segurança e serviços do SharePoint

Mais importante, a extensão de comando pode atualizar agora as contas de segurança no Active Directory e, em seguida, iterar em todos os objetos serviço dependente para chamar o método ChangePassword dos proxies correspondentes para atualizar a senha.

Novamente, os componentes de proxy contém a lógica de específico do serviço necessário para realizar as alterações de senha. A extensão de comando propriamente dito não lidam com detalhes de implementação específico do serviço.

Se você estiver interessado nos detalhes, consulte no material complementar arquivo SPPwdServiceProxy.cs. Ele define o proxy API por meio de um resumo SPPwdServiceProxy classe com seus dois métodos, ResolveIdentities e ChangePassword. Para obter exemplos de implementação, consulte as definições de classes na biblioteca de classes WSSProxies.

A biblioteca WSSProxies ilustra como usar o proxy de serviço API para executar alterações de senha para os serviços padrão do WSS 3.0. Não é complicado para alterar senhas de contas de segurança por meio de programação. Tudo o que você precisa são três linhas de código para identidades de processo e das mesmas três linhas para identidades do pool de aplicativos. O modelo de objeto SharePoint faz o resto.

Somente a conta rastreamento da classe SPSearchService representa um desafio porque Microsoft marcado como a gravação de senha de rastreamento somente, para que você não pode lê-lo com métodos comuns. Isso torna difícil para a solução aos desenvolvedores criar soluções de segurança.

Passar a distância total

Com uma extensão de único comando abrangendo todos os serviços, permita-nos se concentrar nossa atenção na algumas oportunidades de aprimoramento adicional. O primeiro é eliminar a necessidade de especificar senhas em texto não criptografado em um prompt de comando, que não é uma prática de segurança. Até mesmo a mais simples caixa de senha na interface gráfica do usuário seria máscara essas informações.

Outra oportunidade é aumentar a complexidade das senhas sem aumentar a carga administrativa. Talvez a senhas com sete caracteres alfanuméricos aleatórios eram depois considerado seguro, mas que suposição foi estabelecida um muito tempo atrás e provavelmente não mantém true para contas de segurança agora.

Que tal usando 50 ou mais caracteres para recursos importantes, tais como contas de segurança do SharePoint: 3ZK2AQUuqZ7/M7­NBIEvc {XKregSMaVmQgiZaZXik­hL8E {dQuwyQ para o farm conta; TA3pIa7yUyJikc6FxTFl = K9EQcb8lBn­hp8ej03lt3 + mA = 7aqgKA para o aplicativo da Web padrão; DLj­XYA PXMzzAxrHvO/L9MZyd0SkVuMv9/co0ocluYCq/4TID/n + para a conta do serviço pesquisa; e qjoNlEvOX $ 7vbEjrnDd5lXLPYvZEFf­gRpij $8amSbEVpj2O474Q para a conta do rastreador?

Ele apresenta-me como funny imaginar um administrador digitar esses tipos de senhas manualmente. Outra oportunidade de melhoria se relaciona com verificações de segurança. Por padrão, SharePoint não avisar você sobre configurações de segurança fraca, como pools de aplicativos tenham acesso à metabase do IIS ou usando a conta do farm como sua identidade de segurança. Uma solução personalizada pode executar essas verificações regularmente.

E finalmente, por que fazer os administradores de SharePoint precisará lidar com essas senhas para contas de segurança? Os invasores são talvez os únicos interessados em saber essas senhas. Os administradores geralmente não precisam usá-los.

Obviamente, o SharePoint oferece muita de opções para lidar com essas oportunidades. Você pode usar scripts, mas scripts geralmente manipular senhas em texto não criptografado. Você pode usar trabalhos de timer personalizados, que processa o serviço de Timer do SharePoint em intervalos programados, mas o serviço de timer já se encarrega de várias tarefas, incluindo as implantações de credenciais.

É difícil coordenar trabalhos de implantação de credencial com trabalhos de alteração de senha. Parece que funcionou melhor implementar um serviço de SharePoint separado que utiliza a conta do farm como sua identidade de processo para obter acesso total ao modelo de objeto administrativo do SharePoint.

Entre outras coisas, você pode interromper esse serviço a qualquer momento sem afetar outros processos, e você pode desativar este serviço se você preferir alterar senhas manualmente. A solução inclui várias ferramentas para essa finalidade, como as extensões de comando STSADM, um aplicativo do Windows e páginas de aplicativo Administração Central personalizadas, conforme exibido na Figura 4 .

A Figura 4 arquitetura da solução SPPwd

Basicamente, todos os aplicativos de SPPwd contam com o mesmo conjunto de extensões de STSADM, portanto não há apenas um caminho de código, independentemente da qual ferramenta você usar. Através de uma camada de lógica comercial comum, as extensões de comando em conjunto com os proxies de serviço executam o real processar, enquanto os aplicativos SPPwd usam objetos de stub para carregar as extensões de comando dinamicamente em tempo de execução.

Este rigidez permite que você substitua certas extensões de comando sem ter que modificar os aplicativos SPPwd. Por exemplo, se você preferir usar um gerador de senha diferentes, você pode criar uma extensão de comando, implantá-lo no cache global de assemblies e modificar a entrada de comando genpwd no arquivo de configuração stsadmcommands.passwordmanagement.xml. A solução coloca na pasta %Programas%\Common Files\Microsoft Shared\Web Server Extensions\12\Config acordo com as convenções de extensibilidade de STSADM.

O gerador de padrão cria essas senhas longas, que devem ser suficientes na maioria dos casos. a Figura 5 lista as extensões de comando SPPwd com uma breve descrição de sua finalidade. <extension>Você também pode usar o stsadm - ajuda <extensão> comando para exibir mais informações sobre parâmetros disponíveis e exemplos de linha de comando.

Implantação e usando a solução

As planilhas em material complementar descrevem em detalhes como implantar e usar a solução SPPwd em um ambiente de servidor único bem como em um farm de servidor. Você só precisará implantar a solução em um servidor do SharePoint usando os comandos de STSADM addsolution e deploysolution padrão.

SharePoint, em seguida, distribui a solução para todos os servidores do farm por meio de trabalhos de timer. Assim que esses trabalhos são concluídos, você pode ativar o recurso de solução para estender o site da Administração Central e instalar o serviço do Windows usando a extensão de comando sppwdsetup.

O material complementar inclui um arquivo DeployTo.bat para automatizar essas tarefas. Entre outras coisas, o arquivo em lotes demonstra como aguardar trabalhos de timer para concluir antes de prosseguir com outras etapas de implantação.

Por padrão, o serviço de SPPwd só está disponível no servidor em que você executar o arquivo de DeployTo.bat. Você pode configurar o serviço para ser executado em vários servidores do SharePoint, mas há apenas uma instância de uma conta de segurança no Active Directory, e ele impõe os seguintes requisitos de dois: apenas uma instância de serviço SPPwd pode ser autoritativo para uma conta de segurança em particular, e a conta de segurança não deve ser usada em vários farms.

Ter várias instâncias do serviço processar a mesma conta pode causar problemas de acesso simultâneo e não é necessária pois SharePoint propaga atualizações de credencial no farm local automaticamente. Compartilhar contas não são suportadas porque o serviço SPPwd não é possível atualizar informações de conta de segurança entre vários farms de segurança.

O serviço SPPwd só atualiza contas de segurança que especificam nome de domínio no atributo adminDescription totalmente qualificado do servidor de e que confirme em seu atributo de descrição que eles só estão usados no local farm do SharePoint, conforme indicado na Figura 6 . Consulte o material complementar para obter mais informações sobre a configuração de contas de segurança e o serviço de SPPwd para automatizar as alterações de senha.

A Figura 6 SPPwd implantação e configuração de conta de segurança

Conclusão

Contas de segurança são principais alvos de ataques, porque eles podem fornecer acesso completo a todos os conjuntos de sites e dados de site em um farm, independentemente das permissões e os controles de acesso definidos no nível do SharePoint. Uma estratégia básica para impedir esses ataques subseqüente é usar senhas de conta de alta segurança e alterá-los com freqüência.

Isso é desafiadora para realizar porque as contas de usuário de domínio não alterem suas senhas em seus próprios. Você deve executar as alterações de senha manualmente ou usar uma solução automatizada. O modo escolhido, há várias dependências que a documentação do SharePoint e o SDK do WSS não descrevem muito bem.

Você deve atualizar e implantar senhas alteradas e há questões adicionais relacionadas à conta farm. Por exemplo, quando você altera a senha da conta do farm, você alterar a chave de credencial do farm, e isso afeta a capacidade de recuperação do banco de dados de configuração de backup.

No entanto, há não alternativa para alterar a senha de conta do farm regularmente se você quiser manter a segurança do sistema em um farm do SharePoint. Verifique se que você executar um backup após alterar a senha da conta do farm.

Automatizar as alterações de senha é complicado Apesar o fato de que o modelo de objeto SharePoint inclui a lógica necessária para executar atualizações de credenciais. Pode parecer fácil rapidamente primeiro, mas até mesmo uma abordagem baseada em script pode ativá rapidamente em um grande desafio. Uma solução completa baseada no Microsoft .NET Framework e o modelo de objeto administrativo do SharePoint é uma boa opção, mas a melhor solução só pode vir diretamente de Microsoft na forma de inovações de conta de sistema adicionais.

Quase 10 anos atrás, a Microsoft modificou a conta do sistema local para acomodar as necessidades dos clientes da empresa usando o Microsoft Exchange Server. Eventualmente isso resultou na conta do serviço de rede com o Windows Server 2003. Mas a conta do serviço de rede não é adequada para farms de servidor, para que nós deve usar contas de usuário de domínio e lidar com a manutenção associada e problemas de segurança para o melhor de nossa capacidade.

pav Cherny é um especialista IT e autor especializado em tecnologias Microsoft para colaboração e a comunicação unificada. Suas publicações incluem informes oficiais, manuais de produto e livros com um foco em operações de TI e administração do sistema. Pav é presidente da Biblioso Corporation, uma empresa especializada em serviços de documentação e localização gerenciados.