Quais são as etapas necessárias para autenticar usuários de um Active Directory em execução no Windows Server 2012 R2 no FreeBSD 10.0 usando sssdo backend do AD com o Kerberos TGT funcionando?

Existem algumas considerações complicadas para que tudo funcione imediatamente. O FreeBSD suporta apenas a sssdversão 1.9.6 no momento. Portanto, não há suporte para nomes principais da empresa.

Se você tiver um domínio com UPNs não correspondentes, ele falhará no login, uma vez que a autenticação Kerberos falhará durante o processo, mesmo com o FreeBSD suportando Nomes Principais da Empresa com Kerberos, sssdnão será possível lidar com este caso.

Portanto, na versão real, sssdvocê está limitado a ter o Nome Principal do Usuário no mesmo Nome de Domínio, por exemplo:

Domain Name = example.com
NetBIOS Name = EXAMPLE
User Principal Name:
[email protected] sAMAccountName: username

Sabendo disso, podemos descrever as etapas para autenticar com sucesso os usuários do AD no FreeBSD.

1. Configure o Kerberos

Crie o arquivo /etc/krb5.confcom o seguinte conteúdo:

[libdefaults]
    default_realm = EXAMPLE.COM
    dns_lookup_realm = true
    dns_lookup_kdc = true
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = yes

2. Instale o Samba 4.1 e configure-o para ingressar no domínio

Instale o Samba 4.1:

$ pkg install samba41

Crie o arquivo /usr/local/etc/smb4.confcom o seguinte conteúdo:

[global]
    security = ads
    realm = EXAMPLE.COM
    workgroup = EXAMPLE

    kerberos method = secrets and keytab

    client signing = yes
    client use spnego = yes
    log file = /var/log/samba/%m.log

Peça um tíquete Kerberos de administrador:

$ kinit Administrator

Em seguida, ingresse no domínio e crie um keytab

$ net ads join createupn=host/[email protected] -k
$ net ads keytab create -k

3. Instale o pacote sssd e o Cyrus SASL com suporte a Kerberos

Instale os pacotes necessários:

$ pkg install sssd cyrus-sasl-gssapi

Edite o arquivo /usr/local/etc/sssd/sssd.confpara corresponder a essas configurações:

[sssd]
    config_file_version = 2
    services = nss, pam
    domains = example.com

[nss]

[pam]

[domain/example.com]
    # Uncomment if you need offline logins
    #cache_credentials = true

    id_provider = ad
    auth_provider = ad
    access_provider = ad
    chpass_provider = ad

    # Comment out if the users have the shell and home dir set on the AD side
    default_shell = /bin/tcsh
    fallback_homedir = /home/%u

    # Uncomment and adjust if the default principal SHORTNAME$@REALM is not available
    #ldap_sasl_mech = GSSAPI
    #ldap_sasl_authid = [email protected]

4. Adicione suporte sssd ao nsswitch.conf

Edite o arquivo /etc/nsswitch.confpara corresponder a essas configurações:

group: files sss
passwd: files sss

5. Configure o PAM para permitir autenticação sssd e manipular a criação do diretório inicial

Instale pacotes opcionais para criação de diretório inicial:

$ pkg install pam_mkhomedir

Modifique os PAMdomínios necessários para corresponder a essas configurações:

auth            sufficient      /usr/local/lib/pam_sss.so
account         required        /usr/local/lib/pam_sss.so        ignore_unknown_user
session         required        /usr/local/lib/pam_mkhomedir.so  mode=0700
session         optional        /usr/local/lib/pam_sss.so
password        sufficient      /usr/local/lib/pam_sss.so        use_authtok

6. Alterne para o cliente OpenLDAP habilitado para SASL

$ pkg remove -f openldap-client
$ pkg install openldap-sasl-client

7. Finalmente confirme que tudo está funcionando

$ getent passwd <username>

Qual Kerberos você está usando aqui? O built-in ou security / krb5 do MIT?

Ao instalar o sssd, é necessário instalar o security / krb5, que ainda é considerado experimental no FreeBSD. Assim esta pergunta.

Não estou tendo sorte em obter os usuários / grupos do AD ao executar comandos 'getent'. pode ser que o nome NETBIOS seja diferente do nome de domínio - no meu caso, o nome de domínio é dawnsign.com e o nome NETBIOS é DSP.

Eu configurei apenas o módulo de login pam.d. Quais outros módulos pam precisam ser editados para que uma autenticação bem-sucedida ocorra?

Qualquer informação adicional seria muito apreciada!

Recompilar o samba4 a partir do ports é possível usar a autenticação winbind como o linux, mesmo sem o sssd. Simplesmente recompile o samba4 das portas após ativar o sasl ldap

    pkg remove samba41 
    pkg install cyrus-sasl-gssapi samba36-libsmbclient pam_mkhomedir ldb 
    pkg remove -f openldap-client 
    pkg install openldap-sasl-client 
    cd /usr/ports/security/sssd && make install

Isso recompilará o samba com todo o suporte necessário (gssapi, ldap, kerberos) e editará o nsswitch.conf assim

passwd: files winbind
group: files winbind

Olá

Esta é uma pequena atualização sobre o uso do sssd v1.11.7

Se você estiver usando o "id_provider = ad" e vir o seguinte erro no arquivo de log sssd:

/var/log/sssd/sssd_example.com.log
(Sun Oct  5 18:41:37 2014) [sssd[be[alidaho.com]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-12)[Not Supported]
(Sun Oct  5 18:41:37 2014) [sssd[be[alidaho.com]]] [sasl_bind_send] (0x0080): Extended failure message: [unknown error]

Você pode usar o procedimento a seguir para resolver esse problema e fazer a integração do AD funcionar corretamente. Agora construa o sssd v1.11.7 com suporte ao Samba, é necessário construir a partir do src sssd para que seja vinculado ao libsasl2

​pkg remove samba41
pkg install cyrus-sasl-gssapi samba36-libsmbclient pam_mkhomedir ldb
pkg remove -f openldap-client
pkg install openldap-sasl-client
cd /usr/ports/security/sssd && make install

Aqui está o meu guia sobre integração de AD via SSSD com essas versões do FreeBSD, no momento em que este artigo foi escrito (6/2017)

• FreeBSD 10.3 e 11.0 (10.3-RELEASE-p18 e 11.0-RELEASE-p9)

• Instalação (e os divertidos problemas de empacotamento e dependência)

  • Os pacotes necessários não parecem ser compatíveis com o Heimdal Kerberos; portanto, as coisas devem ser instaladas e compiladas com os sinalizadores do MIT Kerberos ativados. Provavelmente, isso é mais um problema de dependência de empacotamento do que um problema de compatibilidade real.
  • O Heimdal é instalado com o sistema base, portanto, você deixa dois conjuntos de comandos Kerberos se você instalar o MIT Kerberos, um configurado /usr/bine outro em /usr/local/bin. Como nenhum dos arquivos básicos do sistema parece estar em um pacote, você não pode simplesmente remover o material Heimdal KRB. Algo para estar ciente.

  • Dependências de encaminhamento dos vários pacotes (deps interessantes em negrito, deps conflitantes em negrito e itálico):

    • net-mgmt/adcli:net/openldap24-sasl-client
    • security/cyrus-sasl2-gssapi: security/cyrus-sasl2
    • net/openldap24-sasl-client: security/cyrus-sasl2
    • security/sssd: security/nss
    • security/sssd:security/krb5
    • security/sssd: security/cyrus-sasl2
    • security/sssd:net/openldap24-client
    • security/sssd: lang/python27
    • security/sssd: lang/python2
    • security/sssd: dns/c-ares
    • security/sssd: devel/tevent
    • security/sssd: devel/talloc
    • security/sssd: devel/popt
    • security/sssd: devel/pcre
    • security/sssd: devel/libunistring
    • security/sssd: devel/libinotify
    • security/sssd: devel/gettext-runtime
    • security/sssd: devel/ding-libs
    • security/sssd: devel/dbus
    • security/sssd: databases/tdb
    • security/sssd: databases/ldb

  • Dependências reversas dos vários pacotes:

    • net/openldap24-sasl-client: sysutils/msktutil
    • net/openldap24-sasl-client: net/nss-pam-ldapd-sasl
    • net/openldap24-sasl-client: net-mgmt/adcli
      • Como vemos a nós sssdmesmos, requer o MIT Kerberos, embora tenhamos o Heimdal como pacote básico
      • adclideseja openldap-sasl-client, mas outros pacotes (incluindo subdependências de sssd) openldap-clientsão recebidos, o que é mutex com o cliente sasl (por qualquer motivo bobo). Isso torna a instalação um pouco trabalhosa, mesmo com um conjunto mínimo de pacotes binários.
      • Essas dependências estão presentes nos pacotes de repositório binário e se os pacotes forem criados na árvore de portas. Isso requer um método de instalação específico e irritante para obter tudo o que precisamos (abordado abaixo).

  • Até o momento em que este artigo foi escrito, o pacote binário para SSSD para FreeBSD não inclui suporte para AD no SSSD

    • A versão de portas do SSSD teve que ser construída com as opções apropriadas (make config) ativadas:
      • SMB
    • O SSSD também deseja obter o openldap-client, quando realmente precisa do openldap-sasl-client para funcionar corretamente.
  • A versão binária do pkg adcliexiste, mas, até o momento, não funciona.
    • Novamente, a versão do ports foi compilada com as opções apropriadas ativadas:
      • GSSAPI_MIT
  • cyrus-sasl-gssapi é necessário, mas a versão binária do pkg não funciona e possui problemas de dependência estranhos que fazem com que remova o SSSD.
    • Crie-o a partir de portas com a opção MIT-KRB5 ativada:
      • GSSAPI_MIT
  • openldap-sasl-client é necessário para a funcionalidade, mas o SSSD deseja obter a versão não SASL do openldap.
    • Para fazer isso funcionar
      • configure openldap-sasl-clientcom a GSSAPIopção selecionada ( make config) nas portas.
      • Faça o make in ports para construí-lo
      • Antes de fazer a instalação, faça um pkg remove –f openldap-client
        • Isso removerá openldap-clientsem a remoção automática de quaisquer outros pacotes (como SSSD) e permitirá a instalação da versão SASL
      • Faça uma instalação make para o openldap-sasl-client
        • Isso o instalará no sistema
  • Isso fornecerá o que é necessário para um SSSD funcional com recursos do AD.
  • Observe que, se você compilar o SSSD a partir de portas, ele criará MUITAS dependências, o que fará com que sejam construídas e exija que as opções de configuração sejam escolhidas.
    • Sugere-se que você instale o pacote binário primeiro com o pkg install sssd e remova-o com pkg remove –f sssd
      • Isso fará com que os pacotes binários da maioria das coisas que o SSSD precise ser extraído e remova a necessidade de criar tudo isso depende das portas, o que leva algum tempo.
    • Depois de removido, reinstale o SSSD das portas com as opções mencionadas acima ativadas e você precisará reconstruir apenas os quatro pacotes mencionados acima para obter uma configuração funcional.

  • (Opcional) Depois que tudo estiver funcionando e verificado, você pode usar pkg createpara criar pacotes binários dos quatro pacotes com as opções apropriadas ativadas e usá-los em vez de construí-los nas portas de todos os sistemas. A instalação do binário segue um padrão semelhante ao processo de construção de portas:

    • pkg install sssd-1.11.7_8.txz
      • Sua versão pode ser diferente, é claro
      • Isso instalará o pacote binário para SSSD e extrairá tudo o que ele precisa do repositório do FreeBSD.
    • pkg add os outros pacotes (não instalar, adicionar), salvando o pacote openldap por último.
    • Antes de adicionar, openldap-sasl-clientfaça umpkg remove –f openldap-client
      • Isso elimina a versão não SASL e permite que nossa versão seja instalada
    • pkg add openldap-sasl-client-2.4.44.txz
      • Novamente, sua versão pode ser diferente
    • Você deve terminar com os pacotes necessários instalados.
    • Ele pode ser possível alterar os metadados para o binário SSSD antes de fazer o pkg createpara substituir a dependência openldap-clientcom openldap-sasl-clienta remover a necessidade de fazer isso remove / reinstalação. Ainda não tive tempo de fazer isso.
      • Além disso, existem subdependências do SSSD que também são utilizadas openldap-client, então você também precisará corrigi-las.
    • Observe que todas essas notas são das versões desses pacotes atualmente na árvore de ports, até o momento em que este documento foi escrito , e das dependências que eles associaram a eles. Tudo isso pode mudar à medida que o FreeBSD atualiza a árvore de portas e os binários. Talvez um dia tenhamos uma versão binária de tudo que extrai todas as dependências corretas com as opções adequadas configuradas para a funcionalidade do AD imediatamente.

  • Configuração Kerberos:

    • Exemplo de arquivo /etc/krb5.conf:

[libdefaults]
   default_realm = MYDOMAIN.NET
   forwardable = true
# Normalmente, tudo o que você precisa em um ambiente AD, pois os registros DNS SRV
# identificará os servidores / serviços AD / KRB. Comente se você
# deseja apontar manualmente para o servidor AD
dns_lookup_kdc = true
[reinos]
   MYDOMAIN.NET = {
# Se você está apontando manualmente para um servidor AD diferente do que está no DNS
# admin_server = adserver.mydomain.net
# kdc = adserver.mydomain.net
   }
[domínio_domínio]
   mydomain.net = MYDOMAIN.NET
   .mydomain.net = MYDOMAIN.NET

• (recuar)
  • Configuração SSSD:
    • Este exemplo pressupõe atributos POSIX no AD para usuários e grupos, geralmente necessários para quando um está substituindo um ambiente existente que já estabeleceu UIDs e GIDs.
    • Exemplo de arquivo /usr/local/etc/sssd/sssd.conf:

[sssd]
config_file_version = 2
domínios = MYDOMAIN.NET
serviços = nss, pam, pac
fallback_homedir = / casa /% u

[domínio / MYDOMAIN.NET]
id_provider = ad
access_provider = ad
auth_provider = ad
chpass_provider = ad
# use atributos do AD POSIX, comente se você estiver usando gerado automaticamente
# UIDs e GIDs.
ldap_id_mapping = Falso
cache_credentials = true
ad_server = adserver.mydomain.net
# se você não tiver o bash, ou o que estiver no loginShell da conta do AD
atributo # instalado
override_shell = / bin / tcsh

• (recuar)
  • Configuração do PAM:
    • A configuração do PAM no FreeBSD é um pouco complicada devido à maneira como o OpenPAM funciona. Não entrarei em detalhes, mas para usar o pam_sss para SSSD e fazê-lo funcionar, além de fazer logins de senhas, você deve colocar o pam_unix no arquivo duas vezes. Pelo que entendi, isso tem a ver com uma verificação secundária que é feita "nos bastidores" que exige que o segundo módulo pam_unix seja aprovado.
      • Aqui está a lista dos /etc/pam.darquivos que eu tive que modificar para fazer o SSSD funcionar com o FreeBSD:

/etc/pam.d/sshd:

#
# $ FreeBSD: releng / 11.0 / etc / pam.d / sshd 197769 2009-10-05 09: 28: 54Z des $
#
# Configuração do PAM para o serviço "sshd"
#

# auth
auth suficiente pam_opie.so no_warn no_fake_prompts
requisito de autenticação pam_opieaccess.so no_warn allow_local
#auth suficiente pam_krb5.so no_warn try_first_pass
#auth suficiente pam_ssh.so no_warn try_first_pass
auth suficiente pam_unix.so no_warn try_first_pass nullok
auth suficiente pam_sss.so use_first_pass
autenticação necessária pam_unix.so no_warn use_first_pass

# conta
conta necessária pam_nologin.so
#account required pam_krb5.so
conta necessária pam_login_access.so
conta necessária pam_unix.so
conta pam_sss.so suficiente

# sessão
#session opcional pam_ssh.so want_agent
sessão opcional pam_sss.so
sessão necessária pam_mkhomedir.so mode = 0700
sessão necessária pam_permit.so

# senha
#password suficiente pam_krb5.so no_warn try_first_pass
#password suficiente pam_unix.so try_first_pass use_authtok nullok
senha suficiente pam_unix.so try_first_pass use_authtok
senha suficiente pam_sss.so use_authtok

/etc/pam.d/system:

#
# $ FreeBSD: releng / 11.0 / etc / pam.d / system 197769-05-10 09: 28: 54Z des $
#
# Padrões em todo o sistema
#

# auth
auth suficiente pam_opie.so no_warn no_fake_prompts
requisito de autenticação pam_opieaccess.so no_warn allow_local
#auth suficiente pam_krb5.so no_warn try_first_pass
#auth suficiente pam_ssh.so no_warn try_first_pass
#auth necessário pam_unix.so no_warn try_first_pass nullok
auth suficiente pam_unix.so no_warn try_first_pass
auth suficiente pam_sss.so use_first_pass
autenticação necessária pam_deny.so

# conta
#account required pam_krb5.so
conta necessária pam_login_access.so
conta necessária pam_unix.so
conta pam_sss.so suficiente

# sessão
#session opcional pam_ssh.so want_agent
sessão necessária pam_lastlog.so no_fail
sessão opcional pam_sss.so
sessão necessária pam_mkhomedir.so mode = 0700

# senha
#password suficiente pam_krb5.so no_warn try_first_pass
#password required pam_unix.so no_warn try_first_pass
senha suficiente pam_unix.so no_warn try_first_pass nullok use_authtok
senha suficiente pam_sss.so use_authtok
#password obrigatório pam_deny.so

/etc/pam.d/su:

#
# $ FreeBSD: releng / 11.0 / etc / pam.d / su 219663 2011-03-15 10: 13: 35Z des $
#
# Configuração do PAM para o serviço "su"
#

# auth
auth suficiente pam_rootok.so no_warn
auth suficiente pam_self.so no_warn
requisito de autenticação pam_group.so no_warn group = wheel root_only fail_safe ruser
auth inclui system.dist

# conta
conta inclui system.dist

# sessão
sessão necessária pam_permit.so

• (recuar)

  • Notas:
    • system.disté uma cópia do /etc/pam.d/systemarquivo de ações . Ele está incluído no /etc/pam.d/suarquivo acima para evitar problemas com o comando su.
    • Ainda é possível suacessar as contas do AD como raiz, já que uma vez raiz, sunão é necessário autenticar e as informações da conta são extraídas pela opção de serviço de nome via SSSD.
    • Se você realmente deseja mudar de um usuário (não root) para outro, deve-se usar apenas sudopor razões de segurança
    • Você também pode usar ksue isso funciona para alternar do usuário A para o usuário B
      • O Heimdal ksu(in /usr/bin) não tem o SUID definido por padrão
        • Para fazer Heimdal ksufuncionar,chmod u+s /usr/bin/ksu
      • O MIT Kerberos ( krb5pacote instalado no /usr/local/bin) é SUID na instalação
    • Como o Heimdal faz parte do pacote base, você terá os dois conjuntos de binários Kerberos.
      • Você pode querer ajustar os caminhos padrão , como /usr/local/binantes /usr/bin, etc
    • ksu solicitará ao usuário a senha AD / Kerberos do usuário de destino
    • passwdnão funcionará para alterar sua senha do AD / Kerberos, mesmo se você adicionar pam_sss.soao arquivo PAM passwd. O passwdbinário suporta apenas o uso local e NIS kpasswdpara alterar sua senha nos servidores AD / Kerberos.

  • Comutador de serviço de nome:

    • O /etc/nsswitch.confarquivo deve ser configurado para usar o serviço sss para senhas e grupos. Exemplo:
      • group: files sss
      • passwd: files sss

  • Ingressando em um domínio:

    • Existem duas ferramentas principais no * nixs para ingressar na sua caixa Linux
      • adcli
        • Esta é a minha ferramenta preferida. Funciona muito bem e tudo pode ser feito em uma única linha de comando. As credenciais podem ser dadas de maneira não interativa (via stdin, etc.)
        • Não requer um kinitantes de usar, ele o faz com base nos dados fornecidos.
          • Exemplo:
            • adcli join -D mydomain.net -U Administrator--show-details –v
            • adcli join –H adclient.mydomain.net -D mydomain.net -U Administrator --show-details -v
              • Este formulário é recomendado, pois o utilitário nem sempre descobre o FQDN corretamente. Quando você fornece o FQDN que corresponde ao DNS direto e reverso do host, os princípios são criados corretamente. Se o utilitário usar o nome do host incorreto (não incluindo o domínio DNS, por exemplo), algumas entidades de serviço não serão criadas e coisas como SSH no host poderão falhar.
      • netUtilitário Samba
        • O netutilitário faz parte do conjunto Samba.
        • Este utilitário requer que os detalhes do domínio sejam configurados no smb.confarquivo de configuração, o que torna mais difícil e inconveniente o uso, principalmente de maneira não interativa.
        • Essas ferramentas também exigem que você obtenha um tíquete Kerberos antes de usá-lo kinit. Novamente, isso é mais inconveniente e torna um pouco mais difícil o uso não interativo em um script, pois há duas etapas em vez de uma.
          

  • Considerações sobre SSHD:

    • Conseguir que o SSHD funcione com AD e SSSD é geralmente bastante simples
    • As seguintes opções precisam ser adicionadas ao /etc/ssh/sshd_config
      • GSSAPIAuthentication yes
        • Ative a autenticação da API GSS para SSHD. Isso fará com que o SSHD seja autenticado no AD KDC
      • PasswordAuthentication yes
        • Permita que os usuários efetuem login com senhas. Necessário se você deseja que um usuário obtenha um ticket KRB5 após o login. Sem isso ativado, o sistema não pode descriptografar o TGT enviado pelo KDC.
      • ChallengeResponseAuthentication yes
        • Para o FreeBSD, esse método parece funcionar melhor.
          • Certifique-se de configurar PasswordAuthentication noao usar esta opção.
          • Este é o único método que encontrei para o FreeBSD que trabalha para alterar uma senha expirada no login. Se você usar o outro, ele chama /bin/passwd, que não suporta nada além de NIS e arquivo de senha local.
      • GSSAPICleanupCredentials yes
        • (opcional) fará um kdestroylogout
      • GSSAPIStrictAcceptorCheck no
        • (opcional) Essa opção geralmente é necessária se o SSHD estiver confuso sobre seu próprio nome de host, for multihomed etc., ou usar outro objeto de serviço diferente para se comunicar com o KDC. Normalmente, o SSHD usa a entidade de serviço host/<FQDN>@REALMpara falar com o KDC, mas às vezes erra (por exemplo, se o nome do host não corresponder ao nome DNS do servidor SSH). Essa opção permite que o SSHD use qualquer objeto principal no /etc/krb5.keytabarquivo, que inclua oshost/<FQDN>@REALM
    • Dependendo da combinação de opções que você usa, pode ou não ser necessário adicionar entidades de host ao KDC para os endereços IPv4 e IPv6 do seu host para ssh -K <ip>que funcionem sem solicitar uma senha (presumindo que você já tenha um 'kinit', claro).