VMware ESXi autenticando os usuários no Active Directory

Meus jovens, virtualização é um caminho sem volta, creio que todos sabem disso.

Virtualbox é bom, mas rarissimamente você verá em ambiente de produção.

VMware é o que tem de sobra por aí. Então, prepare-se, pois é o que tem de sobra no mercado.

Provavelmente os próximos laboratórios que forem postados aqui, serão utilizando VMware ESXi, e algumas (muitas) vezes utilizando o CentOS como sistema operacional. Nesses casos, saiba que a implementação foi feita no trabalho. Quando for openSUSE no Virtualbox, aí é laboratório feito em casa :)

Então, sem mais delongas, ao post:

Fazer o ESXi autenticar no Active Directory!

Sendo direto, o que iremos fazer é: Ingressar com o ESXi no Active Directory (chamaremos de AD), como uma máquina normal. Eu fiquei até espantado com a velocidade em que ele ingressa: 2 segundos (na minha rede). Raramente vejo um host windows ingressando com menos de 5 segundos. Aos passos:

Premissas:

O host deve estar com o DNS setado para o DNS do AD, como qualquer máquina. Geralmente é o mesmo servidor;

O NTP deve estar correto. Esse também geralmente é o mesmo do AD;

O Grupo ESX Admins DEVERÁ existir no seu AD, e nesse grupo, as contas que terão acesso ao hypervisor.

Após acessar o hypervisor, clique em Configuration e no grupo Software, clique em DNS and Routing

 Verifique se as configurações de nome e DNS estão de acordo. Essas informações serão usadas para criar o objeto dentro do AD.

 Caso não esteja, clique em Properties... e defina o domínio, servidor DNS preferencial e qual os domínios onde deverá ser feito o lookup.

Em seguida, ainda no grupo Software, clique em Authentication Services. No canto superior direito, clique em Properties..

 Altere o tipo de serviço de diretório (Select Directory Service Type) para Active Directory. Em Domain Settings, defina o domínio como o da sua empresa e clique em Join Domain.

E pronto! Seu hypervisor ingressou no domínio.

 Viu? Tá dentro!

 Configurações Adicionais
Se você precisa utilizar um grupo diferente, por exemplo, um grupo com permissões limitadas para executar tarefas dentro do hypervisor, você pode fazer seguinte:

Clique em Permissions

Clique com o botão direito na tela e selecione Add Permission...

Defina quais as permissões (Assigned Role) que serão atribuídas a esse grupo. Clique em Add...

 Em Domain, selecione o seu domínio...

...E coloque o nome de seu grupo no campo Search. Faça a busca e dê dois cliques no grupo. Depois, clique em OK.

 Verifique se está tudo ok. Se sim, clique em OK.

 Veja que o grupo do AD agora está com as permissões.

Em breve, mais posts sobre VMware ESXi. Aguardem o/

Read More

OTRS autenticando no Active Directory (AD LDAP)

O OTRS é uma ferramenta de service desk, muito boa por sinal. Estou fazendo alguns testes com ela em minha rede, para substituir o GLPI. Sei que o GLPI é muito bom, mas o acho muito feio e o designer que tinha, já saiu. Então, me resta utilizar algo pronto e bonito :)
Enfim, vamos as configurações:

As configurações do OTRS devem ser feitas diretamente no arquivo Config.pm, que fica dentro do diretório /opt/otrs/Kernel, caso você instale por meio de um pacote .rpm - até recomendo, simplifica e agiliza em muito, até na hora de atualizar as versões.

Então, segue o meu arquivo de configuração:

#Enable LDAP authentication for Customers / Users
  $Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::LDAP';
  $Self->{'Customer::AuthModule::LDAP::Host'} = 'winad01.linux.local';
  $Self->{'Customer::AuthModule::LDAP::BaseDN'} = 'DC=linux,DC=local';
  $Self->{'Customer::AuthModule::LDAP::UID'} = 'sAMAccountName';
  $Self->{'Customer::AuthModule::LDAP::SearchUserDN'} = 'CN=otrs,OU=services,DC=linux,DC=local';
  $Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = 'SeuPassword?';
    # CustomerUser
    # (customer user ldap backend and settings)
    $Self->{CustomerUser} = {
        Name => 'LDAP Data Source',
        Module => 'Kernel::System::CustomerUser::LDAP',
        Params => {
            # ldap host
            Host => 'winad01.linux.local',
            # ldap base dn
            BaseDN => 'dc=linux, dc=local',
            # search scope (one|sub)
            SSCOPE => 'sub',
            UserDN => 'CN=otrs,OU=services,DC=linux,DC=local',
            UserPw => 'SeuPassword?',
            AlwaysFilter => '(&(objectClass=user)(objectCategory=person))',
            SourceCharset => 'utf-8',
            DestCharset   => 'utf-8',
            # Net::LDAP new params (if needed - for more info see perldoc Net::LDAP)
            Params => {
#               port => 389,
                port => 3268,
                timeout => 120,
                async => 0,
                version => 3,
            },
        },
                ReadOnly => 1,
                # customer unique id
        CustomerKey => 'sAMAccountName',
        # customer #
        CustomerID => 'mail',
        CustomerUserListFields => ['cn', 'mail'],
        CustomerUserSearchFields => ['cn', 'givenname', 'mail'],
        CustomerUserSearchPrefix => '',
        CustomerUserSearchSuffix => '*',
        CustomerUserSearchListLimit => 250,
        CustomerUserPostMasterSearchFields => ['mail'],
        CustomerUserNameFields => ['givenname', 'sn'],
        # show not own tickets in customer panel, CompanyTickets
        CustomerUserExcludePrimaryCustomerID => 0,
        # add an ldap filter for valid users (expert setting)
#       CustomerUserValidFilter => '(!(description=locked))',
        # administrator can't change customer preferences
        AdminSetPreferences => 0,
#        # cache time to live in sec. - cache any database queries
        CacheTTL => 120,
  Map => [
            # note: Login, Email and CustomerID are mandatory!
            # if you need additional attributes from AD, just map them here.
            # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly
#            [ 'UserSalutation', 'Title',      'title',           1, 0, 'var', '', 0 ],
            [ 'UserFirstname',  'Firstname',   'givenname',       1, 1, 'var', '', 0 ],
            [ 'UserLastname',   'Lastname',    'sn',              1, 1, 'var', '', 0 ],
            [ 'UserLogin',      'Username',    'sAMAccountName',             1, 1, 'var', '', 0 ],
            [ 'UserEmail',      'Email',       'mail',            1, 1, 'var', '', 0 ],
            [ 'UserCustomerID', 'CustomerID',  'sAMAccountName',            0, 1, 'var', '', 0 ],
#            [ 'UserCustomerIDs', 'CustomerIDs', 'second_customer_ids', 1, 0, 'var', '', 0 ],
            [ 'UserPhone',      'Phone',      'telephoneNumber', 1, 0, 'var', '', 0 ],
#            [ 'UserAddress',    'Address',    'postaladdress',   1, 0, 'var', '', 0 ],
#            [ 'UserComment',    'Comment',    'description',     1, 0, 'var', '', 0 ],
            [ 'UserMobile',     'Mobile',      'mobile', 1, 0, 'var', '', 0 ],
            [ 'UserRoom',       'Room',        'physicalDeliveryOfficeName', 1, 0, 'var', '', 0 ],
        ],
    };

No nosso exemplo:

linux.local: Nosso domínio

winad01.linux.local: endereço do Active Directory

Esse é exatamente meu arquivo de configuração, que autentica em um controlador de domínio Windows Server 2012 R2, que não aceita conexões anônimas por padrão.

Um detalhe que percebi é que ele se conecta a porta 3268, diferente da 389 do LDAP. A porta 3268 é a do Global Catalog Search Base. Para maiores informações, leiam aqui: http://technet.microsoft.com/en-us/library/cc978012.aspx

Até a próxima :)

Read More