Administração de sistemas Windows da MicrosoftProfessor Adjunto do Departamento de Engenharia Informática do ISEP IntroduçãoOs sistemas operativos da Microsoft atingiram uma popularidade que domina quase em absoluto a área dos ambientes de trabalho gráficos, a facilidade de utilização, e o baixo custo funcionou como atractivo inicial para os utilizadores, arrastando consigo o desenvolvimento de "software", formando uma reacção em cadeia ao longo dos anos. Depois do sucesso nos postos de trabalho de baixa performance com o "Windows 3.0", "Windows 3.1" começou-se a desenvolver o interesse pelas redes locais e surge o "Window for Workgroups 3.11" ainda a funcionar sobre o sistema operativo MS-DOS, bastante mais tarde surge o Windows 95 com uma interface gráfica renovada e suporte de ficheiros com nomes alargados VFAT. Até ao Windows 3.11 apenas era suportado o sistema FAT que limita os nomes de ficheiros à regra 8+3. Todos estes sistemas operativos forma desenvolvidos com programação de baixo nível, sem grandes preocupações de segurança o que os tornava muito eficiêntes, mas pouco estáveis e seguros. Paralelamente a Microsoft começou a desenvolver do zero outro tipo de sistema operativo que passou a ser conhecido por NT ("New Tecnology") este novo sistema mantém a interface gráfica de sucesso, é compativel com os anteriores ao nível binário, mas no seu interior é totalmente diferente já que implementa os conceitos necessários a um sistema operativo seguro, destacando-se:
Com estes novos conceitos o NT aderiu claramente aos conceitos subjacentes aos sistema do tipo Unix e outros, os programas em execução e os objectos no sistema de ficheiros passaram a ter proprietários, e passaram a estár sujeitos a permissões sempre que um utilizador tenta algum tipo de acesso. Apesar desta caracteristicas estes sistemas ainda não podem ser considerados verdadeiramente multi-utilizador porque não podem correr simultãneamente aplixações de diferentes utilizadores, existe já contudo uma distinção entre utilizador e sistema. Existem assim duas famílias de sistemas operativos Windows da Microsoft que evoluem de forma mais ou menos independente:
Os sistemas da primeira família (95/98/ME), sem segurança, passaram a ser propostos como produtos para uso doméstico e pessoal, enquanto os sistemas NT e derivados como sistemas para uso profissional. Com o desenvolvimento do Windows NT conseguiu-se uma plataforma estável capaz de substitui o desactualizado "LAN Manager" na área dos servidores de rede, nesta altura os servidores de rede eram dominados por variadas plataformas consideravelmente mais estáveis como Unix, NetWare, OS/400 e outros. Deste modo estes sistemas operativos passaram a existir em duas versões, "Server" e "Workstation", na realidade são bastante semelhantes, existindo estas duas versões mais por questões de "marketing". A "família doméstica" e a "família profissional" evoluem de forma apenas parcialmente independente, não sendo de excluir convergencias futuras. As influências entre as duas famílias são claras, algumas propositadas, tais como os aspectos de interface gráfica e compatibilidade, outras mais relacionadas com aproveitamento de aspectos administrativos e necessidade de interoperacionalidade. Sob o ponto de vista de administração os sistema da família doméstica são considerados "não administráveis" ou, mais precisamente, "auto-administrados". Como se trata de sistemas para uso doméstico, não necessitam de segurança, portanto todos os utilizadores têm os mesmos direitos sobre o sistema, ou seja todos os utilizadores são administradores. As grandes preocupações da Microsoft centraram-se por isso em tornar o mais amigáveis possível algumas operações que num sistema "normal" seriam levadas a cabo pelo administrador, tais como instalação/configuração de "hardware" e "software". Grupos de TrabalhoO suporte, "a serio", de rede nos ambientes Windows começou no Windows 3.11 onde surgiu o conceito de "workgroup", dai a designação desta versão "Windows for Workgroups". O conceito de grupo de trabalho ("workgroup") permite associar um conjunto de postos de trabalho "afins" de acordo com uma determinada organização lógica. Os grupos de trabalho inserem-se nos fundamentos da família doméstica, nesta prespectiva não existe qualquer controlo sob os grupos de trabalho, qualquer utilizador pode criar um novo grupo de trabalho ou aderir (inserir o seu posto de trabalho) a um grupo já existente. Os grupos de trabalho da Microsoft obdecem a uma filosofia "peer-to-peer" onde os postos de trabalho são simultanemente clientes e servidores, o termo "servir" ficheiros, directórios e impressoras é então substituido por "partilhar" ficheiros, directorios e impressoras. Os grupos de trabalho constituem portanto uma extensão do conceito de postos de trabalho auto-administrados, para redes auto-administradas e porque os postos de trabalho são também servidores, servidores auto-administrados. Embora numa rede amigável as redes auto-administradas possam ser uma solução a impossibilidade de identificar utilizadores é um problema, a partilha de recursos por um posto de trabalho pode ter dois modos básicos, leitura-apenas e leitura-escrita, e o acesso pode estár condicionado por uma "password". O conceito de grupo de trabalho mantém-se até à actualidade dos sistemas domésticos, como uma arquitectura "peer-to-peer" sem qualquer segurança e baseada na confiança entre os utilizadores da rede. Com o desenvolvimento dos sistemas profissionais Windows NT Workstation e Server, alguns conceitos foram aproveitados para a família doméstica, assim passou a ser possível aos produtos domésticos abrir (de forma limitada) uma sessão num domínio NT, também passou a ser possível usar definições de utilizador residentes em servidores NT para definir as partilhas de ficheiros. Apartir do Windows 95 também passou a ser possível usar "Roaming Profiles" residentes em servidores NT, apesar destes aspectos de integração com os ambientes profissionais os sistemas domésticos devem ser considerados totalmente inseguros e não apropriados para uso profissional. Segurança em Windows NTEm Windows NT, a maioria dos recursos existentes estão sujeitos a restrições de segurança, para esse efeito todos os elementos devem estar identificados internamente, o NT usa os SID ("Security Identifier"). Os SID são usados para identificar os mais diversos tipos de objectos e recursos que possam estar sujeitos a segurança, tais como utilizadores, grupos de utilizadores, máquinas, etc. Os SID são identificadores internos algo complexos, por exemplo "S-1-5-21-267934097-58472510-3484075414", os SID não se destinam unicamente a identificar recursos, identificam recursos em determinados contextos. As informações disponíbilizadas pela Microsoft são reduzidas, mas aparentemente a forma genérica de um SID é: S-ver-subVer-RID1-RID2-RID3[...] Onde "ver" e "subVer" indicam a versão e sub-versão, sendo usados num domínio NT os valores 1 e 5, respectivamente. Os elementos que se seguem são os "Relative Identifiers" (RID) têm diversas finalidades, servem para identificar o recurso, mas também servem para definir algumas propriedades que ele possui. Por exemplo o SID respeitante a um utilizador que entrou num sistema deverá conter RIDs que identifiquem o utilizador, o domínio, o tipo de acesso (local, remoto, ...), se é um administradorou outro utilizador especial, os grupos de utilizadores a que pertence, ... O facto de os SID conterem informação relativa às propriedades do recurso facilita de forma significativa as validações de segurança respeitantes aos acessos pretendidos pelo detentor de um determinado SID. "Access Control List" (ACL) As ACLs são usadas em NT para definir as permissões sobre os objectos, nomeadamente sobre os sistemas de ficheiros do tipo NTFS. Cada objecto do sistema de ficheiros possui associada a sí uma ACL, na ACL do objecto (ficheiro ou directório) estão definidos os seguintes elementos:
As permissões no NTFS são:
Para facilitar a administração é possível condensar estas permissões nos seguintes valores:
A herança de permissões consiste na propagação das entradas das ACLs ao longo da estrutura de directórios, usando as "flags" de herança é possível indicar se uma dada entrada na ACL de um directório deve ser propagada aos ficheiros e sub-directórios nele contidos. Domínios NTCom o aparecimento dos servidores NT a filosofia "peer-to-peer" foi abandonada, adoptando-se um modelo cliente-servidor, neste contexto os "grupos de trabalho" ("WORKGROUP") transformaram-se em domínios ("DOMAIN"), um domínio NT pode ser visto como um "grupo de trabalho" controlado. O acesso (adesão) ao domínio não é livre, fica pendente de autenticação prévia por um servidor NT com a missão de controlar esse domínio, este servidor é o controlador primário de domínio ("PRIMARY DOMAIN CONTROLER"). Um domínio NT é constituido por servidores NT, apenas um dos quais é o "Primary Domain Controler" (PDC), postos de trabalho NT ("Workstation") e pode aceitar ainda utilizadores de postos de trabalho Windows de tipo pessoal (Ex.: Windows/98). Os utilizadores que estão definidos no controlador de domínio são utilizadores do domínio, esses utilizadores podem abrir a sua sessão de trabalho no domínio, recebendo então credenciais de segurança que lhe permitem aceder aos recursos do domínio sem necessidade de autenticações adicionais. As contas de utilizador em domínios NT, contêm as difinições relativas ao utilizador, entre as quais a localização do seu directório pessoal de trabalho ("HOME DIRECTORY"), que se pode encontrar no PDC, ou em qualquer outro servidor do domínio. A figura seguinte mostra a parte caixa de diálogo para definição da "HOME DIRECTORY", usada no "User Manager for Domains", aplicação de gestão de utilizadores num domínio NT:  Outra caracteristica importante da abertura de sessão num domínio NT é a possíbilidade de se impor a executação de um determinado programa, normalmente conhecido por "Login Script", como parte integrante do processo de abertura, este programa será executado na máquina cliente, após a autenticação do utilizador. A integração dos postos de trabalho no domínio depende do tipo de postos de trabalho, os postos com segurança (Windows NT), necessitam de uma "conta de máquina" no PDC, os postos sem segurança (sistemas pessoais/domésticos) não possuem essa capacidade e a entrada no domínio é realizada apenas ao nível do utilizador. As "contas de máquina" são tratadas no PDC de forma semelhante às contas dos utilizadores, nomeadamente possuem uma "password" associada, quando um posto de trabalho é inserido no domínio é gerada uma "password" que é guardada no posto de trabalho, quando um utilizador entra no posto de trabalho, antes da autenticação do utilizador, realiza-se a autenticação da máquina. A autenticação do posto de trabalho é indirecta, o cliente e o PDC definem uma chave de sessão ARC4 baseada na "password" da máquina cliente e em valores aleatórios gerados por ambos, deste modo a "password" não é enviada pela rede. Uma vez definida a chave secreta de sessão, as trocas de dados criticas entre o cliente e o PDC serão cifradas com esta chave secreta, nomeadamente os dados relativos à autenticação do utilizador e credenciais de segurança transmitidas pelo PDC. No NT 4.0 a chave de sessão é definidas no primeiro "login" de um utilizador no domínio, mantendo-se em efeito até a máquina ser reinicializada. As "password" de máquina são automaticamante mudadas todas as semanas, durante o processo de autenticação da máquina cliente. Igualmente a "password" do utilizador não é transmitida durante a autenticação do mesmo, em seu lugar são enviados "hash codes" resultantes da aplicação de dois algoritmos distintos. Apesar de complexo, podem existir falhas de seguramnça, uma delas relaciona-se com o facto de a primeira "password" da máquina cliente ser enviada de forma legivel pela rede durante o processo de inserção no domínio, mas isto acontece apenas uma vez. De um modo geral são de realçar as grandes preocupações de segurança nos processos da autenticação. No caso de postos de trabalho domésticos não existe "password" de máquina cliente, deste modo a chave de sessão terá de ser gerada sem o seu auxilio. Perfis de UtilizadorO conceito de perfil de utilizador ("User Profile"), em Windows, vai muito além do conceito que lhe está associado em outros sistemas, não se devendo confundir com conta de utilizador ("User Account"). Em ambiente Windows da Microsoft o perfil de utilizador contém todas as informações de configuração de "software" que dizem respeito ao utilizador, como desde o Windows 95 essas informações se encontram guardadas no "registry" (base de dados interna de configuração do sistema) existe uma parte do "registry" que diz respeito ao utilizador e portanto faz parte do "perfil do utilizador", além do "registry" do utilizador, também fazem parte do perfil vários directórios que são manuseados pelo utilizador, tais como:
O perfil de cada utilizado é guardado num directório, que contém o "registry" do utilizador (ficheiro NTUSER.DAT ou USER.DAT, conforme se trate de um sistema profissional ou doméstico) e o conjunto de directórios que fazem parte do perfil. Os perfis de utilizador são guardados no directório %SYSTEMROOT%/Profiles/{nome-de-utilizador}, quando o utilizador entra localmente na máquina, o respectivo perfil é activado, nomedamente o seu "registry". Os perfis de utilizador não são contudo coerentes com os domínios, porque o perfil de utilizador deveria estar associado à respectiva conta no PDC, não sendo assim, apesar de efectuar sempre o "login" no mesmo domínio o perfil iria variar com o posto de trabalho usado. A colocação directa dos perfis de utilizador no PDC revelou-se inviável porque os sistemas operativos Windows da Microsoft e por consequencia a maioria do "software" tem muitas dificuldade em usar a baixo nível informação disponível em servidores. A solução encontrada foi contornar o problema, assim:
Os perfis de utilizador usados deste modo forma designados de "Roaming Profiles". Esta solução resolveu os problemas, mas surgiram algumas situações a considerar:
Relativamente aos dois últimos aspectos as consequêcias podem ser a inutilização do "Roaming Profile". Porque a operação de "download" pode ser algo demorada e porque os utilizadores normalmente não mudam com muita frequência de posto de trabalho, depois do "upload" as cópias locais dos perfis não são eliminadas. Deste modo no "login" seguinte basta comparar as datas do perfil local com a versão no servidor para verificar se o "download" é necessário. O "Roaming Profile" de um utilizador é armazenado num directório designado para o efeito na respectiva conta no PDC, vulgarmente é usada a respectiva "HOME DIRECTORY", dentro do sub-directório Profile especificamente criado para o efeito. Existem algumas diferenças importantes no manuseamento dos "Roaming Profiles" entre os sistemas profissionais (NT, 2000, ...) e os sistemas sem segurança (Windows/95, Windows/98, ...), a mais importante deve-se ao facto de este últimos usarem directamente a "HOME DIRECTORY" e não o sub-directório "Profile" para guardar o "Roaming Profile" no servidor, além disso, estes sistemas não distinguirem os utilizadores através de identificadores, mas sim através do seu "username", não sendo possível como em NT a coexistência de um perfil local e um "roaming" com o mesmo "username". Embora pareca trivial o problema da falta de distinçaão entre utilizadores locais e utilizadores do domínio pode conduzir a situações complicadas quando se altera a configuração de uma máquina deste tipo para passar a efectuar "login" no domínio. Outro problema é a falta de segurança, quando um utilizador efectua o "login" no domínio o seu perfil é copiado para o disco local, depois de o utilizador efectuar o "logout" o seu perfil mantém-se no disco, sendo acessível a todos os utilizadores. "Mandatory Profile"Num contexto de utilização de "roaming profiles" pode ser interessante ser possível impedir certos utilizadores de alterarem o seu perfil. Isto pode justificar-se por exemplo para utilizadores que tendem a alterar o seu ambiente de trabalho e depois não o sabem repor num estádo funcional. Para este efeito é possível recorrer a um "Mandatory Profile". Um "mandatory profile" é um perfil de utilizador identico a um "roaming profile", armazenado num servidor, mas num directório sobre o qual os utilizadores apenas possuem direitos de leitura. Para evitar que os clientes tentem efectuar o "upload", gerando erros por falta de permissões, o ficheiro NTUSER.DAT deve ser alterardo para NTUSER.MAN, deste modo o cliente detecta que está a ser usado um "mandatory profile" e não tenta o "upload" durante o "logout". Depois de preparado o "mandatory profile", basta nas definições das contas dos utilizadores no PDC, definir o "user profile path" de forma apropriada. Os ambientes sem segurança (Windows 98, ...) também suportam "mandatory profiles", mas como o perfil de utilizador é guardado na "home directory" e o "profile path" é ignorado, são colocados alguns problemas, assim o USER.DAT deverá ser alterado para USER.MAN, mas deverá manter-se na "home directory". Politicas de sistemaAs politicas de sistema ("System Policies") permitem estabelecer configurações impostas pelo administrador. Trata-se de valores do "registry" que são inseridos no "registry" do sistema imediatamente após o "login" do utilizador. As políticas de sistema afectam não apenas a parte do "registry" referente ao utilizador, mas também a parte referente ao sistema, assim definindo um determinado valor de uma chave do "registry" nas politicas de sistema ele vais ser gradualmemnte aplicado a todas as máquinas e utilizadores. As politicas de sistema são guardadas nos ficheiros NTCONFIG.POL e CONFIG.POL, respectivamente para ambientes com e sem segurança e devem estár colocados no directório NETLOGON do PDC, desse modo quando o utilizador realiza o "login" no domínio o ficheiro apropriado será aplicado. As politicas de sistema são uma ferramenta bastante poderosa porque permitem impôr de uma forma global (domínio) configurações aos utilizadores e aos proprios sistemas clientes que fazem parte do domínio, sendo ainda possível definir politicas distintas para diferentes utilizadores, grupos de utilizadores e máquinas. O manuseamento das politicas de sistema (ficheiros NTCONFIG.POL e CONFIG.POL no directório NETLOGON do PDC) é efectuado com uma ferramenta propria, o editor de politicas:  O editor de politicas possui uma interface amigável e disponibiliza uma forma mais agradável de observar determinados valores do "registry", podendo ser usado directamente sobre o "registry" da máquina onde é usado, sobre o "registry" de máquinas acessiveis pela rede, ou sobre definições de politica de sistema, neste último caso terá de ser aberto o ficheiro NTCONFIG.POL ou CONFIG.POL, conforme apropriado. O sistema de politicas tem associado a sí um problema tipo "ovo de colombo", para que as politicas sejam carregadas do PDC é necessário que a máquina cliente esteja configurada para esse efeito, para garantir isso em todas as máquinas do domínio tal deve ser definido na política de sistema, mas se a politica de sistema não é carregada ... A figura seguinte ilustra a definição dessa politica com o respectivo editor, em Windows/98:  Podemos observar que a politica definida força a definição da actualização remota do "registry" (carregamento da politica de sistema), sendo usado o modo automático, no caso usar o CONFIG.POL do directório NETLOGON do PDC. Pode-se ainda observar que as políticas são constituidas por caixa de 3 estados, o estado não verificado (caixa em branco) significa que o valor deve ser removido do "registry" quando a política for aplicada, o estado sombreado indica que o valor não deve ser alterado ao aplicar a política (sem efeito), o estado activo indica que o valor deve ser definido no "registry" quando a politica for activada. Se em lugar de uma politica o editor for usado directamente sobre um "registry", o estado sombreado deixa de existir porque não faz sentido. Para que o editor de politicas possa interpretar os valores do "registry" constantes no registo ou no ficheiro de politica, necessita de ser préviamente configurado por "templates" (ficheiros com extensão ADM). Templates do registo Os templates de registo definem formas de ver e manipular valores do "registry" com o editor de politicas, directamente ou através de politicas de sistema, são ficheiros de texto que são previamente carregados pelo editor de politicas:  Existem disponíveis diversos ficheiros ADM, alguns incluidos no próprio sistema, outros disponíveis em "Resource Kits", é no entanto possível criar novos ficheiros, isso será conveniente quando se pretender administrar determinados valores do "registry" que não estão contemplados nas versões disponíveis.
|