SSSD-KRB5(5)

NAME
sssd-krb5 - Provedor Kerberos do SSSD

DESCRIÇÃO

Este manual descreve a configuração do backend de autenticação Kerberos 5 para sssd(8). Para uma referência detalhada da sintaxe, consulte a secção “FORMATO DE FICHEIRO” do manual sssd.conf(5).

O backend de autenticação Kerberos 5 contém provedores auth e chpass. Tem de ser pareado com um provedor de identidade de modo a funcionar correctamente (por exemplo, id_provider = ldap). Alguma informação requerida pelo backend de autenticação Kerberos 5 tem de ser fornecida pelo provedor de identidade, tal como o Kerberos Principal Name (UPN) do utilizador. A configuração do provedor de identidade deve ter uma entrada para especificar o UPN. Por favor consulte o manual do provedor de identidade aplicado para detalhes sobre como configurar isto.

Este backend também fornece controle de acesso baseado no ficheiro .k5login no directório home do utilizador. Veja k5login(5) para mais detalhes. Por favor note que um ficheiro .k5login vazio irá negar todo o acesso a este utilizador. Para activar esta funcionalidade, use 'access_provider = krb5' na sua configuração do SSSD.

Em casos onde o UPN não está disponível no backend de identidade, o sssd irá construir um UPN usando o formato nome-utilizador@krb5_realm.

OPÇÕES DE CONFIGURAÇÃO

Se o auth-module krb5 for usado num domínio SSSD, as seguintes opções têm de ser usadas. Veja o manual sssd.conf(5), secção “SECÇÕES DE DOMÍNIO”, para detalhes sobre a configuração de um domínio SSSD.

krb5_server, krb5_backup_server (string)
    Especifica a lista separada por vírgulas de endereços IP ou nomes de máquinas dos servidores Kerberos aos quais o SSSD deve ligar, pela ordem de preferência. Para mais informação sobre failover e redundância de servidores, veja a secção “FAILOVER”. Um número de porto adicional (com dois pontos a preceder) pode ser acrescentado aos endereços ou nomes de máquinas. Se vazia, é activada a descoberta de serviços; para mais informação, consulte a secção “DESCOBERTA DE SERVIÇOS”.

    Quando se usa descoberta de serviços para servidores KDC ou kpasswd, o SSSD primeiro procura por entradas DNS que especifiquem _udp como o protocolo e regressa a _tcp se nenhuma for encontrada.

    Esta opção tinha o nome “krb5_kdcip” em lançamentos anteriores do SSSD. Apesar do nome antigo ser reconhecido por agora, aconselha-se os utilizadores a migrarem os seus ficheiros de configuração para usar “krb5_server” em vez disto.

krb5_realm (string)
    O nome do reino Kerberos. Esta opção é requerida e tem de ser especificada.

krb5_kpasswd, krb5_backup_kpasswd (string)
    Se o serviço de mudança de palavra passe não estiver a correr no KDC, podem ser definidos aqui servidores alternativos. Pode ser acrescentado um número de porto opcional (precedido pelo caractere dois pontos) aos endereços ou nomes de máquinas.

    Para mais informação sobre failover e redundância de servidores, veja a secção “FAILOVER”. NOTA: Mesmo que não existam mais servidores kpasswd para tentar, o backend não é comutado para operar offline se a autenticação contra o KDC ainda for possível.

    Predefinição: Usar o KDC

krb5_ccachedir (string)
    Directório para guardar as caches de credenciais. Todas as sequências de substituição de krb5_ccname_template podem ser usadas aqui também, excepto %d e %P. O directório é criado como privado e com o utilizador como dono, com as permissões definidas para 0700.

    Predefinição: /tmp

krb5_ccname_template (string)
    Localização da cache de credenciais do utilizador. Actualmente são suportados três tipos de cache de credenciais: “FILE”, “DIR” e “KEYRING:persistent”. A cache pode ser especificada como TYPE:RESIDUAL, ou como um caminho absoluto, o que implica o tipo “FILE”. No modelo, as seguintes sequências são substituídas:

    %u
        nome de login

    %U
        UID de login

    %p
        nome principal

    %r
        nome de reino

    %h
        directório home

    %d
        valor de krb5_ccachedir

    %P
        o ID de processo do cliente SSSD

    %%
        um literal '%'

    Se o modelo terminar com 'XXXXXX' é usado o mkstemp(3) para criar um nome de ficheiro único numa maneira segura.

    Quando se usam tipos KEYRING, o único mecanismo suportado é “KEYRING:persistent:%U”, o qual usa o chaveiro do kernel Linux para guardar as credenciais numa base por UID. Esta é também a escolha recomendada, pois é o método mas seguro e previsível.

    O valor predefinido para o nome da cache de credenciais é obtido a partir do perfil guardado no ficheiro de configuração krb5.conf de todo o sistema na secção [libdefaults]. O nome da opção é default_ccache_name. Veja o parágrafo EXPANSÃO DE PARÂMETROS em krb5.conf(5)'s para informação adicional sobre o formato de expansão definido pelo krb5.conf.

    NOTA: Por favor tenha atenção que o modelo de expansão de cache libkrb5 de krb5.conf(5) usa sequências de expansão diferentes do SSSD.

    Predefinição: (de libkrb5)

krb5_keytab (string)
    A localização da keytab a usar quando se valida credenciais obtidas a partir de KDCs.

    Predefinição: Sistema keytab, normalmente /etc/krb5.keytab

krb5_store_password_if_offline (booleano)
    Guarda a palavra passe do utilizador se o provedor estiver offline e usa-a para pedir um TGT quando o provedor ficar online de novo.

    NOTA: esta funcionalidade só está disponível em Linux. As palavras passe guardadas deste modo são mantidas em texto simples no chaveiro do kernel e são potencialmente acessíveis pelo utilizador root (com dificuldade).

    Predefinição: false

krb5_use_fast (string)
    Activa autenticação segura flexível em túnel (FAST) para a pré-autenticação do Kerberos. As seguintes opções são suportadas:

    never (nunca) usa FAST. Isto é equivalente a não definir de todo esta opção.

    try (tenta) usar FAST. Se o servidor não suportar FAST, continua com a autenticação sem isso.

    demand (obriga) a usar FAST. A autenticação falha se o servidor não requerer fast.

    Predefinição: não definida, isto é, FAST não é usado.

    NOTA: é requerido uma keytab ou suporte a PKINIT anônimo para se usar FAST.

    NOTA: SSSD suporta FAST apenas com MIT Kerberos versão 1.8 e posterior. Se o SSSD for usado com uma versão antiga do MIT Kerberos, usar esta opção é um erro de configuração.

krb5_fast_principal (string)
    Especifica o principal servidor a usar para FAST.

krb5_fast_use_anonymous_pkinit (booleano)
    Se definido para true tenta usar PKINIT anônimo em vez de uma keytab para obter a credencial requerida para FAST. A opção krb5_fast_principal é ignorada neste caso.

    Predefinição: false

krb5_use_kdcinfo (booleano)
    Especifica se o SSSD deve instruir as bibliotecas Kerberos qual reino e quais KDCs usar. Esta opção está ligada por predefinição, se você a desactivar, você precisa de configurar a biblioteca Kerberos usando o ficheiro de configuração krb5.conf(5).

    Veja o manual sssd_krb5_locator_plugin(8) para mais informação no plugin locador.

    Predefinição: true

krb5_kdcinfo_lookahead (string)
    Quando krb5_use_kdcinfo é definida para true, você pode limitar a quantidade de servidores lidados para sssd_krb5_locator_plugin(8). Isto pode ser útil quando existem demasiados servidores descobertos usando o registo SRV.

    A opção krb5_kdcinfo_lookahead contém dois números separados pelo caractere dois pontos. O primeiro número representa o número de servidores primários usados e o segundo número especifica o número de servidores de backup.

    Por exemplo, 10:0 significa que até 10 servidores primários serão lidados para sssd_krb5_locator_plugin(8) mas nenhum servidor de recurso.

    Predefinição: 3:1

krb5_use_enterprise_principal (booleano)
    Especifica se o principal de utilizador deve ser tratado como principal de empresa. Veja a secção 5 de RFC 6806 para mais detalhes sobre principais de empresa.

    Predefinição: false (fornecedor AD: true)

    O provedor IPA irá definir a opção para 'true' se detectar que o servidor é capaz de lidar principais de empresa e a opção não está definida explicitamente no ficheiro de configuração.

krb5_use_subdomain_realm (booleano)
    Especifica para se usar reinos de sub-domínios para a autenticação de utilizadores de domínios de confiança. Esta opção pode ser definida para 'true' se principais de empresa foram usadas com upnSuffixes que são desconhecidos nos KDCs do domínio pai. Se a opção for definida para 'true' o SSSD irá tentar enviar o pedido directamente para um KDC do domínio de confiança de onde o utilizador venha.

    Predefinição: false

krb5_map_user (string)
    A lista de mapeamentos é dada como uma lista separada por vírgulas de pares “username:primary” onde “username” é um nome de utilizador UNIX e “primary” é uma parte utilizador de um principal kerberos. Este mapeamento é usado quando o utilizador é autenticado usando “auth_provider = krb5”.

    exemplo:

        krb5_realm = REALM
        krb5_map_user = joe:juser,dick:richard

    “joe” e “dick” são nomes de utilizador UNIX e “juser” e “richard” são primários de principais do kerberos. Para utilizador “joe” resp. “dick” o SSSD irá tentar fazer kinit como “juser@REALM” resp. “richard@REALM”.

    Predefinição: não definida

krb5_auth_timeout (inteiro)
    Tempo limite em segundos após um pedido de autenticação online ou pedido de mudança de palavra passe abortado. Se possível, o pedido de autenticação é continuado em offline.

    Predefinição: 6

krb5_validate (booleano)
    Verifica com a ajuda de krb5_keytab que o TGT obtido não foi falsificado. A keytab é verificada por entradas sequencialmente, e a primeira entrada com um reino correspondente é usada para validação. Se nenhuma entrada corresponder ao reino, é usada a última entrada na keytab, Este processo pode ser usado para validar ambientes que usam confiança de reino-cruzada ao colocar a entrada keytab apropriada como a última entrada ou a única entrada no ficheiro keytab.

    Predefinição: false (Provedor IPA e AD: true)

    Por favor note que a validação do bilhete é o primeiro passo quando se verifica o PAC (veja 'pac_check' no manual sssd.conf(5) para detalhes). Se a validação de bilhete estiver desativada as verificações de PAC serão também saltadas.

krb5_renewable_lifetime (string)
    Requisita um bilhete renovável com um tempo de vida total, dado como um inteiro imediatamente seguido de uma unidade de tempo:

    s para segundos

    m para minutos

    h para horas

    d para dias.

    Se não existir nenhuma unidade dada, é assumido s.

    NOTA: Não é possível misturar unidades. Para definir um tempo de vida renovável de uma hora e meia, use '90m' em vez de '1h30m'.

    Predefinição: não definido, ou seja, o TGT não é renovável

krb5_lifetime (string)
    Requisita um bilhete com um tempo de vida, dado como um inteiro imediatamente seguido de uma unidade de tempo:

    s para segundos

    m para minutos

    h para horas

    d para dias.

    Se não existir nenhuma unidade dada é assumido s.

    NOTA: Não é possível misturar unidades. Para definir um tempo de vida de uma hora e meia por favor use '90m' em vez de '1h30m'.

    Predefinição: não definida, isto é, o tempo de vida de bilhete predefinido configurado no KDC.

krb5_renew_interval (string)
    O tempo em segundos entre duas verificações se o TGT deve ser renovado. Os TGTs são renovados se cerca de metade do seu tempo de vida for excedido, dado como um inteiro imediatamente seguido por uma unidade de tempo:

    s para segundos

    m para minutos

    h para horas

    d para dias.

    Se não existir nenhuma unidade dada, é assumido s.

    NOTA: Não é possível misturar unidades. Para definir um tempo de vida renovável de uma hora e meia, use '90m' em vez de '1h30m'.

    Se esta opção não for definida ou for 0 a renovação automática é desactivada.

    Predefinição: não definida

krb5_canonicalize (booleano)
    Especifica se a máquina e o principal utilizador devem ser canonizados. Esta funcionalidade está disponível com o MIT Kerberos 1.7 e versões posteriores.

    Predefinição: false

FAILOVER

A funcionalidade failover permite aos backends mudarem automaticamente para o servidor diferente se o servidor actual falhar.

  Sintaxe do Failover

A lista de servidores é dada como uma lista separada por vírgulas; é permitido qualquer número de espaços em volta das vírgulas. Os servidores são listados pela ordem de preferência. A lista pode conter qualquer número de servidores.

Para cada opção de configuração activa-failover, existem duas variantes: primary e backup. A ideia é que os servidores na lista primária são preferidos e os servidores backup são apenas procurados se os servidores primários não puderem ser alcançados. Se um servidor backup for selecionado, é definido um tempo limite de 31 segundos. Após este tempo limite o SSSD irá periodicamente tentar re-ligar a um dos servidores primários. Se tiver sucesso, irá substituir o servidor actualmente activo (backup).

  O Mecanismo Failover

O mecanismo failover distingue entre uma máquina e um serviço. O backend primeiro tenta resolver o nome de máquina de uma dada máquina; se esta tentativa de resolução falhar, a máquina é considerada offline. Não são feitas mais tentativas de ligar a esta máquina para qualquer outro serviço. Se a tentativa de resolução tiver sucesso, o backend tenta ligar a um serviço nesta máquina. Se a tentativa de ligação a serviço falhar, então este serviço particular é considerado offline e o backend automaticamente muda para o próximo serviço. A máquina continua a ser considerada online e pode ainda ser tentada para outro serviço.

São feitas mais tentativas de ligação a máquinas ou serviços marcados como offline após um período de tempo especificado; isto é actualmente duramente codificado a 30 segundos.

Se não existirem mais máquinas para tentar, o backend muda todos para modo offline, e depois tenta re-ligar a cada 30 segundos.

  Tempo limite e afinação do Failover

Resolver um servidor a onde ligar pode ser tão simples como correr uma única consulta DNS ou pode invocar vários passos, tais como encontrar o sítio correto ou tentar múltiplos nomes de máquinas no caso de alguns dos servidores configurados não estarem alcançáveis. Os cenários mais complexos podem durar algum tempo e o SSSD precisa de equilibrar entre disponibilizar tempo suficiente para terminar o processo de resolução mas por outro lado, não demorar muito tempo antes de regressar ao modo offline. Se os registos de depuração do SSSD mostrarem que a resolução do servidor atingiu o tempo limite antes de ser contactado um servidor vivo, você pode considerar mudar os tempos limite.

Esta secção lista as afinações disponíveis. Por favor consulte as suas descrições no manual sssd.conf(5).

dns_resolver_server_timeout
    Tempo em milissegundos que define quanto tempo deve o SSSD falar com um único servidor DNS antes de tentar o próximo.

    Predefinição: 1000

dns_resolver_op_timeout
    Tempo em segundos que diz quanto tempo deve o SSSD tentar resolver uma única consulta DNS (ex. resolução de um nome de máquina ou dum registo SRV) antes de tentar o próximo nome de máquina ou domínio de descoberta.

    Predefinição: 3

dns_resolver_timeout
    Quanto tempo deve o SSSD tentar resolver um serviço failover. Esta resolução de serviço internamente pode incluir vários passos, tal como resolver consultas SRV de DNS ou localizar o sítio.

    Predefinição: 6

Para provedores baseados em LDAP, a operação de resolução é executada como parte de uma operação de ligação LDAP. Assim, também o tempo limite “ldap_opt_timeout” deve ser definido para um valor maior que “dns_resolver_timeout” que por sua vez deve ser definido para um valor maior que “dns_resolver_op_timeout” o qual deve ser maior que “dns_resolver_server_timeout”.

DESCOBERTA DE SERVIÇOS

A funcionalidade de descoberta de serviços permite aos backends encontrarem automaticamente os servidores apropriados para ligarem para usarem uma consulta DNS especial. Esta funcionalidade não é suportada para servidores de salvaguarda (backup).

  Configuração

Se nenhum servidor for especificado, o backend automaticamente usa a descoberta de serviços para tentar encontrar um servidor. Opcionalmente, o utilizador pode escolher usar ambos endereços de servidor fixos e a descoberta de serviços ao inserir uma palavra chave especial “_srv_”, na lista de servidores. A ordem de preferência é mantida. Esta funcionalidade é útil se, por exemplo, o utilizador prefere usar descoberta de serviços sempre que possível, e regressar a um servidor específico quando não se descobrem servidores usando DNS.

  O nome de domínio

Por favor consulte o parâmetro “dns_discovery_domain” no manual sssd.conf(5) para mais detalhes.

  O protocolo

As consultas geralmente especificam _tcp como o protocolo. As excepções estão documentadas na descrição da opção respectiva.

  Veja também

Para mais informação sobre o mecanismo de descoberta de serviços, consulte RFC 2782.

EXEMPLO

O exemplo seguinte assume que o SSSD está presentemente configurado e FOO é um dos domínios na secção [sssd]. Este exemplo mostra apenas configuração da autenticação Kerberos; não inclui nenhum provedor de identidade.

    [domain/FOO]
    auth_provider = krb5
    krb5_server = 192.168.1.1
    krb5_realm = EXAMPLE.COM

VEJA TAMBÉM

sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-idp(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(1), sss_ssh_knownhosts(1), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5)

AUTHORS

O autor do SSSD - https://github.com/SSSD/sssd/