Sabe aqueles usuários que criamos agora há pouco? Então, exclua todos eles! Isso mesmo... não queremos ter que gerenciar todas essas contas individualmente: vamos autenticar os usuários da rede para fornecer acesso ao Wildfire. Ah, vamos excluir também os grupos. Para excluir os usuários e grupos você tem duas opções: um a um (pela console administrativa do Wildfire) ou todos ao mesmo tempo, diretamente na console do PostgreSQL, assim:
wildfire=# DELETE FROM jivegroup;
wildfire=# DELETE FROM jiveuser WHERE username LIKE 'user%';
No nosso domínio, temos dois grupos: LOIRAS e MORENAS, com os respectivos usuários:
Queremos então que estes usuários utilizem suas próprias senhas da rede para se autenticar no Wildfire. Pelo que eu pude entender, lendo a documentação no Wildfire e alguns fóruns na Internet, o esquema de "Group Sharing" (compartilhamento de grupo) não associa-se diretamente com os grupos de segurança do Windows. Sendo assim, teremos que criar manualmente os grupos no Wildfire, mas isso já não é mais problema, pois isto para nós já é uma tarefa muito divertida.
Até o presente momento ainda não tinha citado um arquivo que é de suma importância para o funcionamento do sistema. Trata-se do wildfire.xml, que pode ser localizado dentro do diretório conf de onde o mesmo foi descompactado (no nosso caso, /usr/local/wildfire/conf/wildfire.xml). Este sujeito é o responsável pelos principais parâmetros do Wildfire, como por exemplo: porta onde será executado, idioma, usuários que poderão acessar a console administrativa, configurações para acesso ao banco de dados, e configurações para utilização com LDAP (que é a parte que nos interessa agora). Como vocês já devem saber, o XML trata suas cláusulas de uma forma hierarquicamente muito bem organizada. Sabemos também que os comentários são iniciados por "<!--” e encerrados por “-->". Abra, no seu editor de textos preferido, o arquivo wildfire.xml do seu servidor e observe as configurações atuais. Você verá que as sessões ldap e provider estão comentadas, porque estamos utilizando usuários criados localmente. Vamos então descomentá-las e configurá-las de acordo com o nosso ambiente. As sessões ficarão assim:
<ldap>
<host>69.171.38.1</host>
<port>389</port>
<usernameField>sAMAccountName</usernameField>
<nameField>displayName</nameField>
<emailField>mail</emailField>
<baseDN>DC=playboy,DC=com,DC=br</baseDN>
<adminDN>CN=Administrator,CN=Users,DC=playboy,DC=com,DC=br</adminDN>
<adminPassword>***senha-do-administrator***</adminPassword>
<debugEnabled>true</debugEnabled>
</ldap>
<provider>
<user>
<className>org.jivesoftware.wildfire.ldap.LdapUserProvider</className>
</user>
<auth>
<className>org.jivesoftware.wildfire.ldap.LdapAuthProvider</className>
</auth>
</provider>
Não se esqueça de remover os comentários que delimitam essas sessões. Obviamente, dentre outras adequações ao seu domínio (como host, baseDN, etc.), onde está registrado "***senha-do-administrator***" você deve substituir pela senha que cadastrou durante a instalação do Microsoft Windows.
Um pouco acima destas configurações, você deverá descomentar a cláusula que define quais usuários poderão acessar a console administrativa do Wildfire, veja:
<authorizedUsernames>kelly.key,scheila.carvalho</authorizedUsernames>
Assim, somente estes dois usuários poderão acessar a console administrativa. E, por enquanto, essas são as únicas alterações necessárias no wildfire.xml. Reinicialize (stop e start) o serviço do Wildfire para que as alterações sejam efetivadas.
Entre novamente na console administrativa do Wildfire e tente logar-se como "admin". Não fique surpreso se não conseguir, pois o Wildfire agora está orientado a não mais buscar informações sobre usuários no banco de dados do PostgreSQL, mas sim na base LDAP regida pelo Active Directory. Fique a vontade para efetuar logon com um dos usuários do domínio que você especificou em <authorizedUsernames> no wildfire.xml. Viu como funciona bem? ;) Observe o nome do usuário (e a opção de Sair) no canto superior direito da console administrativa:
Dentro da console administrativa, clique na guia "Usuários/Grupos" e perceba que lhe serão apresentados todos os usuários do domínio. Observe que além delas outras contas serão exibidas, como contas de grupos, contas de computadores, etc:
Nós, que estamos sempre preocupados com organização, detestamos essa mistura de contas. Queremos que sejam listados apenas os usuários que criamos, sem os usuários padrões do sistema, grupos, computadores, etc. Para isso criaremos, no Active Directory, uma Organization Unit chamada "NudeGirls" e migraremos todos os usuários pra lá, assim:
Agora, devemos informar ao Wildfire que ele deve pegar como referência não mais todos os usuários do domínio, mas sim os usuários pertencentes à Organization Unit "NudeGirls". Para isso, abra novamente o arquivo wildfire.xml e altere a linha da baseDN para:
<baseDN>OU=NudeGirls,DC=playboy,DC=com,DC=br</baseDN>
Reinicialize o serviço do Wildfire, efetue logon na console administrativa (com um dos usuários autorizados), clique na guia de "Usuários/Grupos" e observe o resultado:
Agora sim, são exibidos apenas os contatos que criamos. Na verdade usei este exemplo para demonstrar que você pode também controlar quais usuários estarão habilitados a utilizar o comunicador instantâneo dentro da sua rede. Uma forma simples e prática, seria criar uma Organization Unit com um nome bastante intuitivo (como por exemplo "Jabber") e mover para ela somente aqueles usuários que desejamos permitir que acessem o comunicador, bastando apenas definir no parâmetro baseDN a "OU" que criamos. Sim, existem outras formas de fazer esse controle, mas esta é a mais simples e... funciona bem!
Entretanto, se quisermos que todos os usuários que tenham permissão para utilizar o comunicador apareçam automaticamente nos clientes (e organizados em grupos), devemos, manualmente, criar os grupos utilizando a console administrativa do Wildfire e adicionarmos os usuários neles. Se não fizermos assim, o cliente ao se conectar não exibirá contato algum, e teremos que adicionar nele (cliente) manualmente os contatos que desejarmos. Se já quisermos que os contatos sejam exibidos automaticamente, basta criar grupos no Wildfire e adicionar usuários aos grupos e compartilhá-los, habilitando a opção "Ativar o compartilhamento de grupos nos contatos". Veja o exemplo onde criarmos dois grupo no Wildfire, igual criamos no Active Directory:
Agora sim, o cliente exibe todos os contatos que tem um grupo associado. Vejamos abaixo:
Aproveitando que temos alguns usuários on-line, vamos explorar um interessante serviço que é o de conferência. No cliente neos, acesse o discreto menu em sua barra superior, então aponte para "Mensageiro instantâneo" e depois para "Serviços":
Uma janela se abre, exibindo os serviços disponíveis no servidor:
Clique então no botão "Unir-se/Criar" e a seguinte janela surge:
Observe que aquele nome dado ao serviço de conferência é adicionado ao FQDN do servidor. No nosso caso, o nome do servidor ao qual nos conectaremos passa a ser "salas.messenger.playboy.com.br". Informaremos então uma sala a ser criada (caso a mesma não exista) e um apelido para ser usado nela. Eis que uma nova sala é criada, e o usuário que a criou passa a ser o operador (administrador) da mesma, característica representada por uma @ no início do apelido (alguém aqui já usou IRC? :). Veja:
Pra que serve uma sala de bate-papo se você é o único presente? Ora, convide então um colega pra participar. Clique no ícone de convite, e uma janela surgirá exibindo todos os contatos on-line. Selecione um ou mais contatos e acione o botão convidar:
Opcionalmente, você poderá redigir uma mensagem a ser enviada como convite aos outros usuários:
Do outro lado, o seu contato receberá uma notificação de que você o está convidando para ingressar em uma sala de conferência:
Ao aceitar o convite, uma outra janela exibe informações sobre a sala/servidor e opcionalmente pode-se alterar o seu apelido a ser exibido na sala. Depois de visualizar ou alterar os campos clique em "Unir-se/Criar":
Está então criada uma sala pública (sem a necessidade de se digitar uma senha para ingressar) onde todos se comunicam como em uma conferência:
Certamente teremos alguns clientes Linux na nossa rede. Para estes casos escolhi o renomado GAIM para se utilizado como cliente desta plataforma. Vamos configurá-lo facilmente:
Clique no ícone "Contas" e adicione uma nova conta, utilizando o protocolo "Jabber" com as credenciais de um dos usuários da rede:
Os clientes que estão conectados são exibido:
O GAIM tem o gracioso recurso de selecionarmos se queremos ou não omitir os grupos vazios e os usuários desconectados. Dessa forma podemos "despoluir" a tela, exibindo apenas os contatos on-line. Acredite isto é bastante útil quando se tem uma grande lista de contatos. Para ingressarmos naquela sala onde estão os outros usuários, mesmo sem termos sido convidado, clique no botão "Bate-papo" e preencha os dados com as informações do servidor/sala:
A inferface é um pouco diferente, mas os recursos são os mesmos:
Conforme dito anteriormente, o usuário que cria a sala recebe o poder de operador (gerenciador) da sala. A ele é atribuído condições de, nomear novos gerenciadores, moderadores, proprietários e até expulsar usuários indesejados, veja:
Opcionalmente, um motivo pode ser especificado para a expulsão:
É, pelo visto nem sempre é uma boa idéia ingressar em uma sala sem ter sido convidado ;)
Como foi dito desde o começo, não vou entrar em grandes detalhes do cliente. É responsabilidade sua descobrir os inúmeros e interessantes recursos deste e de outros clientes que desejar usar.
Vamos voltar à console administrativa do Wildfire e olharmos o status dos nossos usuários. Efetue logon com um usuário autorizado e selecione a guia "Usuários/Grupos":
Visualmente podemos saber se nossos usuários estão conectados (ícone verde), conectados mas ausentes (ícone amarelo) ou desconectados (ícone em tons de cinza). Além disso, podemos acionar a guia "Sessões" para gerenciar o estado da conexão dos usuários, verificar quais estão utilizando conexão segura e até mesmo desconectá-los: