SSSD-AD(5) Formatos de Ficheiros e Conven SSSD-AD(5)

sssd-ad - Provedor Active Directory do SSSD

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

O provedor AD é um backend usado para ligar a um servidor Active Directory. este provedor requer que a máquina seja junta ao domínio AD e que esteja disponível uma keytab. A comunicação com o backend ocorre por um canal encriptado em GSSAPI, as opções de SSL/TLS não devem ser usadas com o provedor AD e serão sobrepostas por utilização do Kerberos.

O provedor AD suporta ligar a Active Directory 2008 R2 ou posterior. As versões anteriores podem funcionar, mas não são suportadas.

O provedor AD pode ser usado para obter informação e autenticar utilizadores de domínios de confiança. Presentemente apenas domínios de confiança na mesma floresta são reconhecidos. Adicionalmente, servidores de domínios de confiança são sempre auto-descobertos.

O provedor AD permite ao SSSD usar o provedor de identidade sssd-ldap(5) e o provedor de autenticação sssd-krb5(5) com optimizações para ambientes Active Directory. O provedor AD aceita as mesmas opções usadas pelos provedores sssd-ldap e sssd-krb5 com algumas excepções. No entanto, não é necessário nem recomendado definir estas opções.

O provedor AD primariamente copia as opções predefinidas dos provedores ldap e krb5 tradicionais com algumas excepções, as diferenças são listadas na secção “OPÇÕES PREDEFINIDAS MODIFICADAS”.

O provedor AD pode também ser usado como provedor de acesso, chpass, sudo e autofs. Nenhuma configuração do provedor de acesso é requerida no lado cliente.

Se “auth_provider=ad” ou “access_provider=ad” estiverem configurados no sssd.conf então o id_provider tem também de ser definido para “ad”.

Por predefinição, o provedor AD irá mapear valores UID e GID a partir do parâmetro objectSID em Active Directory. Para detalhes sobre isto, veja a secção “MAPEAMENTO de ID” em baixo. Se você deseja desligar o mapeamento de ID e em vez disso confiar nos atributos POSIX definidos em Active Directory, você deve definir

ldap_id_mapping = False

Se devem ser usados atributos POSIX, é recomendado por razões de performance que os atributos sejam também replicados para o Global Catalog. Se os atributos POSIX forem replicados, o SSSD irá tentar localizar o domínio de um ID numérico pedido com a ajuda do Global Catalog e apenas procura nesse domínio. Em contraste, se os atributos POSIX não forem replicados no Global Catalog, o SSSD tem de procurar em todos os domínios na floresta sequencialmente. Por favor note que a opção “cache_first” pode também ajudar a acelerar as buscas dos domínios. Note que se apenas um sub-conjunto de atributos POSIX estiver presente no Global Catalog, os atributos não-replicados atualmente não são lidos a partir do porto LDAP.

Utilizadores, grupos e outras entidades servidas pelo SSSD são sempre tratadas com insensibilidade a maiúsculas/minúsculas no provedor AD para compatibilidade com a implementação LDAP do Active Directory.

SSSD apenas resolve Grupos de Segurança Active Directory. Para mais informação sobre tipos de grupo AD veja: Grupos de segurança Active Directory[1]

SSSD filtra e separa grupos Domain Local de domínios remotos na floresta AD. Por predefinição eles são filtrados por ex quando se segue uma hierarquia de grupo aninhado em domínios remotos porque eles não são válidos no domínio local. Isto é feito para se estar de acordo com a atribuição de membros de grupo de Active Directory que pode ser visto no PAC do bilhete Kerberos dum utilizador publicado por Active Directory.

OPÇÕES DE CONFIGURAÇÃO

Consulte a secção “SECÇÕES DE DOMÍNIO” do manual sssd.conf(5) para detalhes da configuração de um domínio SSSD.

ad_domain (string)

Especifica o nome do domínio Active Directory. Isto é opcional. Se não for fornecido, é usado o nome de domínio da configuração.

Para operação apropriada, esta opção deve ser especificada como a versão curta da versão longa do domínio Active Directory.

O nome de domínio curto (também conhecido como NetBIOS ou nome liso) é auto-detectado pelo SSSD.

ad_enabled_domains (string)

Uma lista separada por vírgulas de domínios Active Directory activos. Se fornecida, o SSSD irá ignorar quaisquer domínios não listados nesta opção. Se deixada por definir, todos os domínios da floresta AD irão estar disponíveis.

Durante a descoberta de domínios, o SSSD irá filtrar alguns domínios onde as bandeiras ou atributos indicam que eles não pertencem à floresta local ou não são de confiança. Se ad_enabled_domains estiver definido, o SSSD irá tentar ativar todos os domínios listados.

Para operação apropriada, esta opção tem de ser especificada toda em minúsculas e como o nome de domínio totalmente qualificado do domínio Active Directory. Por exemplo:

ad_enabled_domains = sales.example.com, eng.example.com

O nome de domínio curto (também conhecido como NetBIOS ou nome liso) será auto-detectado pelo SSSD.

Predefinição: Não definida

ad_server, ad_backup_server (string)

A lista separada por vírgulas de nomes de máquinas dos servidores AD aos quais o SSSD deve ligar por ordem de preferência. Consulte a secção “FAILOVER” para mais informação sobre failover e redundância de serviços.

Isto é opcional se a auto-descoberta estiver activa. Para mais informação sobre descoberta de serviços, consulte a secção “DESCOBERTA DE SERVIÇOS”.

Nota: Domínios de confiança irão sempre auto-descobrir servidores mesmo que o servidor primário esteja explicitamente definido na opção ad_server.

ad_hostname (string)

Opcional. Em máquinas onde o nome-de-máquina(5) não reflete o nome qualificado completo, o sssd irá tentar expandir o nome curto. Se tal não for possível ou se é o nome curto que deve realmente ser usado, defina este parâmetro explicitamente.

Este campo é usado para determinar a principal máquina em uso na keytab e para executar actualizações DNS dinâmicas. Tem de corresponder ao nome de máquina para a qual a keytab foi emitida.

ad_enable_dns_sites (booleano)

Activa sítios DNS - descoberta de serviços baseada em localização.

Se true e a descoberta de serviços (veja o parágrafo Descoberta de Serviços no fundo do manual) estiver activa, o SSSD irá primeiro tentar descobrir o servidor Active Directory onde ligar para usar o Active Directory Site Discovery e cair para os registos DNS SRV se nenhum sítio AD for encontrado. A configuração DNS SRV, incluindo o domínio de descoberta, é usada também durante a descoberta de sítios.

Predefinição: true

ad_access_filter (string)

Especifica um filtro de controle de acesso LDAP que o utilizador tem de corresponder para obter acesso. A opção “access_provider” tem de ser explicitamente definida para “ad” para esta opção ter efeito. Se você desejar usar o “ad_access_filter” como único esquema de controle de acesso, você tem de desativar o controle de acesso baseado em GPO (veja a opção “ad_gpo_access_control” para detalhes).

A opção também suporta especificar filtros diferentes por domínio ou floresta. Este filtro estendido irá consistir de “KEYWORD:NAME:FILTER”. A palavra chave pode ser ou “DOM”, “FOREST” ou estar em falta.

Se a palavra chave for igual a “DOM” ou estiver em falta, então “NAME” especifica o domínio ou sub-domínio a que o filtro se aplica. Se a palavra chave for igual a “FOREST”, então o filtro é igual a todos os domínios da floresta especificada por “NAME”.

Múltiplos filtros podem ser separados com o caractere “?”, de modo semelhante a como funcionam as bases de busca.

Os membros de grupo aninhado têm de ser procurados para usarem um OID especial “:1.2.840.113556.1.4.1941:” em adição à sintaxe DOM:domain.example.org: completa para assegurar que o analisador não tenta interpretar os caracteres dois pontos associados com o OID. Se você não usar este OID então os membros de grupo aninhado não serão resolvidos. Veja a utilização do exemplo em baixo e consulte aqui mais informação sobre o OID: secção [MS-ADTS] extensões do LDAP[2]

A correspondência mais específica é sempre usada. Por exemplo, se a opção especificou um filtro para um domínio que o utilizador é membro e um filtro global, será aplicado o filtro por-domínio. Se existirem mais correspondências com a mesma especificação, é usada a primeira.

Exemplos:

# apply filter on domain called dom1 only:
dom1:(memberOf=cn=admins,ou=groups,dc=dom1,dc=com)
# apply filter on domain called dom2 only:
DOM:dom2:(memberOf=cn=admins,ou=groups,dc=dom2,dc=com)
# apply filter on forest called EXAMPLE.COM only:
FOREST:EXAMPLE.COM:(memberOf=cn=admins,ou=groups,dc=example,dc=com)
# apply filter for a member of a nested group in dom1:
DOM:dom1:(memberOf:1.2.840.113556.1.4.1941:=cn=nestedgroup,ou=groups,dc=example,dc=com)

Predefinição: Não definida

ad_site (string)

Especifica o sítio AD ao qual o cliente deve tentar ligar. Se esta opção não for fornecida, o sítio AD será auto-descoberto.

Predefinição: Não definida

ad_enable_gc (booleano)

Por predefinição, o SSSD liga-se ao Global Catalog primeiro para obter utilizadores dos domínios de confiança e usa o porto LDAP para obter os membros dos grupos ou como um recurso em caso de falha. Desactivar esta opção faz com que o SSSD apenas se ligue ao porto LDAP do servidor AD actual.

Por favor note que desactivar o suporte a Global Catalog não desactiva o obter de utilizadores de domínios de confiança. O SSSD deve ligar ao porto LDAP dos domínios de confiança. No entanto, Global Catalog tem de ser usado de modo a se resolver membros de grupos de domínios-cruzados.

Predefinição: true

ad_gpo_access_control (string)

Esta opção especifica o modo de operação para a funcionalidade de controle de acesso baseado em GPO. Se vai operar em modo desactivado, modo forçado, ou modo permissivo. Por favor note que a opção “access_provider” tem de ser explicitamente definida para “ad” de modo a esta opção ter efeito.

A funcionalidade de controle de acesso baseada em GPO usa definições de política GPO para determinar se é ou não concedida permissão a um utilizador particular de fazer login na máquina. Para mais informação sobre as definições de políticas suportadas por favor consulte as opções “ad_gpo_map”.

Por favor note que a versão actual do SSSD não suporta grupos embutidos do Active Directory. Os grupos embutidos (tais como Administrators com SID S-1-5-32-544) nas regras de controlo de acesso GPO serão ignorados pelo SSSD. Veja o rasteio de problemas emitido pelo autor https://github.com/SSSD/sssd/issues/5063 .

Antes de executar o controle de acesso o SSSD aplica filtragem de segurança de política de grupo nos GPOs. Para cada login de utilizador singular, é verificada a aplicabilidade dos GPOs que estão vinculados à máquina. De modo a que um GPO seja aplicado a um utilizador, o utilizador ou pelo menos um dos grupos c que pertence tem de ter as seguintes permissões no GPO:

•Read: O utilizador ou um dos seus grupos tem de ter acesso de leitura às propriedades do GPO (RIGHT_DS_READ_PROPERTY)
•Apply Group Policy: O utilizador ou pelo menos um dos seus grupos tem de ter permissão para aplicar o GPO (RIGHT_DS_CONTROL_ACCESS).

Por predefinição, o grupo Authenticated Users está presente num GPO e este grupo tem ambos direitos de acesso Read e Apply Group Policy. Como a autenticação do utilizador tem de ser completada com sucesso antes da filtragem de segurança GPO e o controle de acesso ser arrancado, as permissões do grupo Authenticated Users no GPO também se aplicam sempre ao utilizador.

NOTA: Se o modo de operação está definido para forçar, é possível que os utilizadores que antes tinham permissão de acesso de login tenham agora o acesso de login negado (como ditado pelas definições de política GPO). De modo a facilitar uma transição suave para administradores, está disponível um modo permissivo que não irá forçar as regras de controlo de acesso, mas irá avalia-las e irá escrever uma mensagem no syslog se o acesso teria sido negado. Ao examinar os registos, os administradores podem então fazer as mudanças necessárias antes de definirem o modo de forçar. Para registar o controle de acesso baseado em GPO é requerido o nível de depuração 'trace functions' (veja o manual sssctl(8)).

Existem três valores suportados para esta opção:

•disabled: as regras de controlo de acesso baseadas em GPO não são avaliadas nem forçadas.
•enforcing: as regras de controlo de acesso baseadas em GPO são avaliadas e forçadas.
•permissive: As regras de controle de acesso baseadas em GPO são avaliadas, mas não impostas. Em vez de negar acesso, é emitida uma mensagem no syslog indicando que o utilizador teria o acesso negado, se o valor desta opção estivesse definido para enforcing.

Predefinição: enforcing

ad_gpo_implicit_deny (booleano)

Normalmente quando são encontrados GPOs não aplicáveis, os utilizadores têm o acesso concedido. Quando esta opção é definida para True os utilizadores terão permissão de acesso apenas quando explicitamente concedida por uma regra GPO. Caso contrário os utilizadores terão o acesso negado. Isto pode ser usado para endurecer a segurança mas tenha cuidado quando usar esta opção porque pode negar acesso até a utilizadores do grupo embutido Administrators se nenhuma regra GPO se aplicar a eles.

Predefinição: False

As 2 tabelas seguintes devem ilustrar quando um utilizador é permitido ou negado com base dos direitos de concessão ou negação de login definidos no lado servidor e na definição de ad_gpo_implicit_deny.

ad_gpo_implicit_deny = False (predefinido)
allow-rules deny-rules results
missing missing todos os utilizadores têm permissão
missing present apenas utilizadores não em deny-rules têm permissão
present missing apenas utilizadores em allow-rules têm permissão
present present apenas utilizadores em allow-rules e não em deny-rules têm permissão
ad_gpo_implicit_deny = True
allow-rules deny-rules results
missing missing nenhum utilizador tem permissão
missing present nenhum utilizador tem permissão
present missing apenas utilizadores em allow-rules têm permissão
present present apenas utilizadores em allow-rules e não em deny-rules têm permissão

ad_gpo_ignore_unreadable (booleano)

Normalmente quando algum contentor de política de grupo (objecto AD) de objecto de política de grupo aplicável não pode ser lido pelo SSSD então os utilizadores têm o acesso negado. Esta opção permite ignorar os contentores de política de grupo e com eles as políticas associadas se os seus atributos nesses contentores não forem legíveis pelo SSSD.

Predefinição: False

ad_gpo_cache_timeout (inteiro)

A quantidade de tempo entre procuras de ficheiros de política GPO num servidor AD. Isto irá reduzir a latência e carga no servidor AD se existirem muitos pedidos de controle de acesso feitos num curto período.

Predefinição: 5 (segundos)

ad_gpo_map_interactive (string)

Uma lista separada por vírgulas de nomes de serviço PAM para os quais o controle de acesso baseado em GPO é avaliado com base nas definições de política InteractiveLogonRight e DenyInteractiveLogonRight. Apenas esses GPOs são avaliados para os quais o utilizador tem permissão Read e Apply Group Policy (veja a opção “ad_gpo_access_control”). Se um GPO avaliado conter a definição de logon interactivo deny para o utilizador ou para um dos seus grupos, ao utilizador é negado acesso local. Se nenhum dos GPOs avaliados tiver um direito de logon interactivo definido, ao utilizador é concedido acesso local. Se pelo menos um GPO avaliado conter definições de direito de logon interactivo, ao utilizador é concedido acesso local apenas, se ele ou pelo menos um dos seus grupos fizer parte das definições de política.

Nota: Usando o Editor de Gestão de Política de Grupo este valor é chamado "Allow log on locally" e "Deny log on locally".

É possível adicionar outro nome de serviço PAM ao conjunto predefinido ao usar “+service_name” ou removendo explicitamente um nome de serviço PAM do conjunto predefinido ao usar “-service_name”. Por exemplo, de modo a substituir um nome de serviço PAM predefinido por este direito de login (ex. “login”) por um nome de serviço pam personalizado (ex. “my_pam_service”), você deverá usar a seguinte configuração:

ad_gpo_map_interactive = +my_pam_service, -login

Predefinição: o conjunto predefinido de nomes de serviços do PAM inclui:

•login
•su
•su-l
•gdm-fingerprint
•gdm-password
•gdm-smartcard
•kdm
•lightdm
•lxdm
•sddm
•unity
•xdm

ad_gpo_map_remote_interactive (string)

Uma lista separada por vírgulas de nomes de serviço PAM para os quais o controle de acesso baseado em GPO é avaliado com base nas definições de política RemoteInteractiveLogonRight e DenyRemoteInteractiveLogonRight. Apenas esses GPOs são avaliados para os quais o utilizador tem permissão Read e Apply Group Policy (veja a opção “ad_gpo_access_control”). Se um GPO avaliado conter a definição de logon remoto interactivo deny para o utilizador ou para um dos seus grupos, ao utilizador é negado acesso remoto. Se nenhum dos GPOs avaliados tiver um direito de logon remoto interactivo definido, ao utilizador é concedido acesso remoto. Se pelo menos um GPO avaliado conter definições de direito de logon remoto interactivo, ao utilizador é concedido acesso remoto apenas, se ele ou pelo menos um dos seus grupos fizer parte das definições de política.

Nota: Usando o Editor de Gestão de Política de Grupo este valor é chamado "Allow log on through Remote Desktop Services" e "Deny log on through Remote Desktop Services".

É possível adicionar outro nome de serviço PAM ao conjunto predefinido ao usar “+service_name” ou removendo explicitamente um nome de serviço PAM do conjunto predefinido ao usar “-service_name”. Por exemplo, de modo a substituir um nome de serviço PAM predefinido por este direito de login (ex. “sshd”) por um nome de serviço pam personalizado (ex. “my_pam_service”), você deverá usar a seguinte configuração:

ad_gpo_map_remote_interactive = +my_pam_service, -sshd

Predefinição: o conjunto predefinido de nomes de serviços do PAM inclui:

•sshd
•cockpit

ad_gpo_map_network (string)

Uma lista separada por vírgulas de nomes de serviço PAM para os quais o controle de acesso baseado em GPO é avaliado com base nas definições de política NetworkLogonRight e DenyNetworkLogonRigh. Apenas esses GPOs são avaliados para os quais o utilizador tem permissão Read e Apply Group Policy (veja a opção “ad_gpo_access_control”). Se um GPO avaliado conter a definição de logon de rede interactivo deny para o utilizador ou para um dos seus grupos, ao utilizador é negado acesso de rede. Se nenhum dos GPOs avaliados tiver um direito de logon de rede interactivo definido, ao utilizador é concedido acesso. Se pelo menos um GPO avaliado conter definições de direito de logon de rede interactivo, ao utilizador é concedido acesso apenas, se ele ou pelo menos um dos seus grupos fizer parte das definições de política.

Nota: Usando o Editor de Gestão de Política de Grupo este valor é chamado "Access this computer from the network" e "Deny access to this computer from the network".

É possível adicionar outro nome de serviço PAM ao conjunto predefinido ao usar “+service_name” ou removendo explicitamente um nome de serviço PAM do conjunto predefinido ao usar “-service_name”. Por exemplo, de modo a substituir um nome de serviço PAM predefinido por este direito de login (ex. “ftp”) por um nome de serviço pam personalizado (ex. “my_pam_service”), você deverá usar a seguinte configuração:

ad_gpo_map_network = +my_pam_service, -ftp

Predefinição: o conjunto predefinido de nomes de serviços do PAM inclui:

•ftp
•samba

ad_gpo_map_batch (string)

Uma lista separada por vírgulas de nomes de serviço PAM para os quais o controle de acesso baseado em GPO é avaliado com base nas definições de política BatchLogonRight e DenyBatchLogonRight. Apenas esses GPOs são avaliados para os quais o utilizador tem permissão Read e Apply Group Policy (veja a opção “ad_gpo_access_control”). Se um GPO avaliado conter a definição de logon em lote interactivo deny para o utilizador ou para um dos seus grupos, ao utilizador é negado acesso em lote. Se nenhum dos GPOs avaliados tiver um direito de logon em lote interactivo definido, ao utilizador é concedido acesso. Se pelo menos um GPO avaliado conter definições de direito de logon em lote interactivo, ao utilizador é concedido acesso apenas, se ele ou pelo menos um dos seus grupos fizer parte das definições de política.

Nota: Usando o Editor de Gestão de Política de Grupo este valor é chamado "Allow log on as a batch job" e "Deny log on as a batch job".

É possível adicionar outro nome de serviço PAM ao conjunto predefinido ao usar “+service_name” ou removendo explicitamente um nome de serviço PAM do conjunto predefinido ao usar “-service_name”. Por exemplo, de modo a substituir um nome de serviço PAM predefinido por este direito de login (ex. “crond”) por um nome de serviço pam personalizado (ex. “my_pam_service”), você deverá usar a seguinte configuração:

ad_gpo_map_batch = +my_pam_service, -crond

Nota: O nome do serviço Cron pode diferir dependendo da distribuição Linux usada.

Predefinição: o conjunto predefinido de nomes de serviços do PAM inclui:

•crond

ad_gpo_map_service (string)

Uma lista separada por vírgulas de nomes de serviço PAM para os quais o controle de acesso baseado em GPO é avaliado com base nas definições de política ServiceLogonRight e DenyServiceLogonRight. Apenas esses GPOs são avaliados para os quais o utilizador tem permissão Read e Apply Group Policy (veja a opção “ad_gpo_access_control”). Se um GPO avaliado conter a definição de logon de serviço deny para o utilizador ou para um dos seus grupos, ao utilizador é negado acesso de serviço. Se nenhum dos GPOs avaliados tiver um direito de logon de serviço definido, ao utilizador é concedido acesso. Se pelo menos um GPO avaliado conter definições de direito de logon de serviço, ao utilizador é concedido acesso apenas, se ele ou pelo menos um dos seus grupos fizer parte das definições de política.

Nota: Usando o Editor de Gestão de Política de Grupo este valor é chamado "Allow log on as a service" e "Deny log on as a service".

É possível adicionar um nome de serviço PAM ao conjunto predefinido ao usar “+service_name”. Como o conjunto predefinido está vazio, não é possível remover um nome de serviço PAM do conjunto predefinido. Por exemplo, de modo a adicionar um serviço pam personalizado (ex. “my_pam_service”), você deve usar a seguinte configuração:

ad_gpo_map_service = +my_pam_service

Predefinição: não definida

ad_gpo_map_permit (string)

Uma lista separada por vírgulas de nomes de serviço PAM para os quais o acesso baseado em GPO é sempre concedido, independentemente de quaisquer Direitos de Logon GPO.

É possível adicionar outro nome de serviço PAM ao conjunto predefinido ao usar “+service_name” ou removendo explicitamente um nome de serviço PAM do conjunto predefinido ao usar “-service_name”. Por exemplo, de modo a substituir um nome de serviço PAM predefinido por um de acesso permitido incondicionalmente (ex. “sudo”) por um nome de serviço pam personalizado (ex. “my_pam_service”), você deverá usar a seguinte configuração:

ad_gpo_map_permit = +my_pam_service, -sudo

Predefinição: o conjunto predefinido de nomes de serviços do PAM inclui:

•polkit-1
•sudo
•sudo-i
•systemd-user

ad_gpo_map_deny (string)

Uma lista separada por vírgulas de nomes de serviço PAM para os quais o acesso baseado em GPO é sempre negado, independentemente de quaisquer Direitos de Logon GPO.

É possível adicionar um nome de serviço PAM ao conjunto predefinido ao usar “+service_name”. Como o conjunto predefinido está vazio, não é possível remover um nome de serviço PAM do conjunto predefinido. Por exemplo, de modo a adicionar um serviço pam personalizado (ex. “my_pam_service”), você deve usar a seguinte configuração:

ad_gpo_map_deny = +my_pam_service

Predefinição: não definida

ad_gpo_default_right (string)

Esta opção define como o controle de acesso é avaliado para nomes de serviço PAM que não estão listados explicitamente em uma das opções ad_gpo_map_*. Esta opção pode ser definida de duas maneiras diferentes. Primeiro, esta opção pode ser definida para se usar um direito de login predefinido. Por exemplo, se esta opção for definida para 'interactive', significa que os nomes de serviços PAM não mapeados irão ser processados com base nas definições de política InteractiveLogonRight e DenyInteractiveLogonRight. Em alternativa, esta opção pode ser definida para ou permitir sempre ou negar sempre o acesso a nomes de serviços PAM não mapeados.

Os valores suportados para esta opção incluem:

•interactive
•remote_interactive
•network
•batch
•service
•permit
•deny

Predefinição: deny

ad_maximum_machine_account_password_age (inteiro)

O SSSD irá verificar uma vez por dia se a palavra passe da conta da máquina é mais antiga que a idade dada em dias e tentar renova-la. Um valor de 0 irá desactivar a tentativa de renovação.

Predefinição: 30 dias

ad_machine_account_password_renewal_opts (string)

Esta opção só deve ser usada para testar a tarefa de renovação de conta da maquina. A opção espera 3 inteiros separados por dois pontos (':'). O primeiro inteiro define o intervalo em segundos da frequência que a tarefa irá correr. O segundo especifica o tempo limite inicial em segundos antes da tarefa correr pela primeira vez após o arranque. O terceiro valor opcional especifica um desvio aleatório máximo aos dois valores anteriores para evitar atualizações de muitas máquinas ao mesmo tempo ("problema estranho trovejante"). Se este valor estiver em falta ou vazio será usado o valor string '0'.

O quarto valor string opcional identifica o binário ajudante que deve ser usado para a renovação. Atualmente são suportados adcli e realm. Se este valor estiver em falta ou vazio na string de valor será usado realm . Como o ajudante é arrancado como o utilizador do SSSD que o corre pode haver uma hipótese que a renovação vá falhar se este utilizador não tiver permissão para modificar o ficheiro keytab onde estão guardadas as credenciais da conta da máquina. Este será tipicamente o caso de adcli.

realm não está a atualizar a keytab diretamente mas está a chamar o processo realmd, o qual corre como utilizador root, para esta tarefa. realmd pode permitir acesso a utilizadores não-privilegiados coma a ajuda de PolicyKit e por predefinição o SSSD fornece regras apropriadas para o utilizador que o SSSD está a correr como.

Predefinição: 86400:750:300:realm (24h, 12m30s and 5m)

ad_update_samba_machine_account_password (booleano)

Se activa, quando o SSSD renova a palavra passe da conta da máquina, será também actualizada na base de dados do Samba. Isto previne que a cópia do Samba da palavra passe da conta da máquina fique desactualizada quando é configurada para usar AD para autenticação.

Predefinição: false

ad_use_ldaps (booleano)

Por predefinição o SSSD usa o porto 389 do LDAP simples e o porto 3628 do Global Catalog. Se esta opção estiver definida para True, o SSSD irá usar o porto 636 do LDAPS e o porto 3629 do Global Catalog com proteção LDAPS. Como o AD não permite ter múltiplas camadas de encriptação numa única ligação, e nós ainda queremos usar SASL/GSSAPI ou SASL/GSS-SPNEGO para autenticação a propriedade de segurança do SASL maxssf é definida para 0 (zero) para essas ligações.

Predefinição: False

dyndns_update (booleano)

Opcional. Esta opção diz ao SSSD para actualizar automaticamente o servidor DNS Active Directory com o endereço IP deste cliente. A actualização é segura usando GSS-TSIG. Como uma consequência, o administrador do Active Directory só precisa de permitir actualizações seguras para a zona do DNS. O endereço IP da ligação LDAP AD é usado para as actualizações, se não for caso contrário especificado ao se usar a opção “dyndns_iface”.

NOTA: Em sistemas antigos (como o RHEL 5), para este comportamento poder ter fiabilidade de funcionamento, o reino Kerberos predefinido tem de ser definido apropriadamente em /etc/krb5.conf

Predefinição: true

dyndns_ttl (inteiro)

O TTL a aplicar ao registo de cliente DNS quando o actualiza. Se dyndns_update for false isto não tem efeito. Isto irá sobrepor o TTL do lado servidor se definido por um administrador.

Predefinição: 3600 (segundos)

dyndns_iface (string)

Optional. Applicable only when dyndns_update is true. Choose the interface or a list of interfaces whose IP addresses should be used for dynamic DNS updates. The name of interface can be a wildcard pattern prefixed with ! for interface excluding. First match stops the evaluation. For example list !eth1, * instruct SSSD to use all interfaces except eth1. See man 7 glob for details about patterns.

NOTA: Apesar de ainda ser possível usar a opção antiga ipa_dyndns_iface, os utilizadores devem migrar para usardyndns_iface no seu ficheiro de configuração.

Predefinição: Usa o endereço IP da interface que é usada para ligação AD LDAP

Example: dyndns_iface = em[12], !vnet1, vnet*

dyndns_address (string)

Optional. Applicable only when dyndns_update is true. A list of IP addresses or IP networks to be used for dynamic DNS updates. Network addresses must be in CIDR format. An entry can be prefixed with ! to indicate exclusion. The best match is used to determine whether an address is included or excluded (i.e., a longer prefix takes precedence).

Default: No filtering of IP addresses.

Example: dyndns_address = 10.0.0.0/16, !10.0.1.0/24

dyndns_refresh_interval (inteiro)

Quão frequente deve o backend executar a actualização DNS periódica em adição à actualização automática executada quando o backend fica online. Esta opção é opcional e aplicável apenas quando dyndns_update é true. Note que o valor mais baixo possível é 60 segundos, no caso de o valor fornecido ser inferior a 60, o parâmetro irá assumir apenas o menor valor.

Predefinição: 86400 (24 horas)

dyndns_update_ptr (booleano)

Se o registo PTR também deve ser explicitamente actualizado quando se actualiza os registos de DNS dos clientes. Aplicável apenas quando dyndns_update é true.

Note que o parâmetro dyndns_update_per_family não se aplica para atualizações de registo PTR Essas atualizações são sempre enviadas em separado.

Predefinição: TRUE

dyndns_force_tcp (booleano)

Se o utilitário nsupdate deve por predefinição usar TCP para comunicar com o servidor DNS.

Predefinição: False (deixa o nsupdate escolher o protocolo)

dyndns_auth (string)

Se o utilitário nsupdate deve usar autenticação GSS-TSIG para actualizações de segurança com o servidor DNS, actualizações não seguras podem ser enviadas ao definir esta opção para 'none'.

Predefinição: GSS-TSIG

dyndns_auth_ptr (string)

Se o utilitário nsupdate deve usar autenticação GSS-TSIG para actualizações PTR de segurança com o servidor DNS, actualizações não seguras podem ser enviadas ao definir esta opção para 'none'.

Predefinição: O mesmo que dyndns_auth

dyndns_server (string)

O servidor DNS a usar quando executa uma actualização de DNS. Na maioria das configurações, é recomendado deixar esta opção por definir.

Definir esta opção faz sentido em ambientes onde o servidor DNS é diferente do servidor de identidade ou quando usamos DNS encriptado.

O parâmetro ode ser uma string simples que contém um nome DNS ou um endereço IP. Também pode ser um URI. O URI pode parecer-se com dns://servername/ ou dns+tls://1.2.3.4:853#servername/.

O segundo exemplo ativa protocolo DNS-sobrer-TLS para atualizações de DNS. O utilitário nsupdate tem de suportar DoT - verifique o manual do nsupdate antes de o ativar no SSSD.

Por favor note que esta opção só será usada em tentativas de recurso quando a tentativa anterior que usa definições se auto-detecção falhe ou quando DNS-sobre-TLS estiver ativo.

Predefinição: None (deixa o nsupdate escolher o servidor)

dyndns_update_per_family (booleano)

A actualização DNS é por predefinição feita em dois passos - actualização IPv4 e depois actualização IPv6. Nalguns casos pode ser desejável executar a actualização IPv4 e IPv6 num único passo.

Predefinição: true

dyndns_dot_cacert (string)

Esta opção especifica o ficheiro do certificado da autoridade de certificados (em formato PEM) de modo a verificar o certificado TLS do servidor remoto quando se usa DoT.

Predefinição: Nenhum (usa o armazém de certificados global)

dyndns_dot_cert (string)

Esta opção define o ficheiro de certificado(s) para autenticação para o transporte DoT para o servidor remoto. É esperado que o ficheiro de cadeia de certificados esteja em formato PEM.

As opções dyndns_dot_cert e dyndns_dot_key têm de ser ambas definidas para se conseguir autenticação TLS mútua.

Predefinição: Nenhuma (Não usa autenticação TLS)

dyndns_dot_key (string)

Esta opção define o ficheiro chave para encriptação autenticada para o transporte DoT ao servidor remoto. É esperado que o ficheiro da chave privada esteja em formato PEM.

Predefinição: Nenhuma (Não usa autenticação TLS)

override_homedir (string)

Sobrepõe o directório home do utilizador. Você pode ou fornecer um valor absoluto ou um modelo. No modelo, as seguintes sequências são substituídas:

%u

nome de login

%U

Número UID

%d

nome de domínio

%f

nome do utilizador totalmente qualificado (utilizador@domínio)

%l

A primeira letra do nome de login.

%P

UPN - Nome Principal de Utilizador (nome@REINO)

%o

O valor homedir que é definido no directório do provedor de identidade.

Esta substituição foi desenhada para ser usada num cenário de confiança IPA-AD. Se esta substituição for usada para a opção subdomain_homedir, vai propagar o valor do directório home do domínio AD para os clientes IPA. Neste cenário, a opção tem de ser definida na configuração SSSD no servidor IPA onde o SSSD está a correr em modo servidor.

%h

O caminho definido para o atributo de directório homedir do provedor de identidade, mas em minúsculas. Para detalhes do uso, veja %o.

%H

O valor da opção de configuração homedir_substring.

%%

um literal '%'

Esta opção também pode ser definida por-domínio.

exemplo:

override_homedir = /home/%u

Predefinição: Não definida (o SSSD irá usar o valor obtido de LDAP)

Por favor note, o directório home duma sobreposição específica para o utilizador, seja localmente (veja sss_override(8)) ou centralmente gerida por id-overrides de IPA , tem uma precedência mais alta e será usada em vez do valor dado por override_homedir.

homedir_substring (string)

O valor desta opção será usado na expansão da opção override_homedir se o modelo conter a string de formato %H. Uma entrada de directório LDAP pode conter directamente este modelo para que esta opção possa ser usada para expandir o caminho do directório home para cada máquina cliente (ou sistema operativo). Pode ser definida por-domínio ou globalmente na secção [nss]. Um valor especificado numa secção domain irá sobrepor aquele definido na secção [nss].

Predefinição: /home

krb5_confd_path (string)

Caminho absoluto de um directório onde o SSSD deve colocar trechos de configuração do Kerberos.

Para desactivar a criação de trechos de configuração defina o parâmetro para 'none'.

Predefinição: não definida (sub-directório krb5.include.d do directório pubconf do SSSD)

OPÇÕES PREDEFINIDAS MODIFICADAS

Certas predefinições de opções não correspondem às suas predefinições de backend respectivos, estes nomes de opção e predefinições específicas de provedor AD estão listadas em baixo:

•krb5_validate = true
•krb5_use_enterprise_principal = true

•ldap_schema = ad
•ldap_force_upper_case_realm = true
•ldap_id_mapping = true
•ldap_sasl_mech = GSS-SPNEGO
•ldap_referrals = false
•ldap_account_expire_policy = ad
•ldap_use_tokengroups = true
•ldap_sasl_authid = sAMAccountName@REALM (typically SHORTNAME$@REALM)

Por predefinição um provedor AD procura um principal diferente que o provedor LDAP, porque num ambiente Active Directory os principais são divididos em dois grupos - Principais de Utilizador e Principais de Serviço. Apenas o Principal de Utilizador pode ser usado para obter um TGT e por predefinição, o principal de objecto de computador é constituído pelo seu sAMAccountName e o reino AD, O principal host/hostname@REALM well-known é um Principal de Serviço e assim não pode ser usado para se obter TGT com ele.

Configuração do NSS

•fallback_homedir = /home/%d/%u

O provedor AD define automaticamente "fallback_homedir = /home/%d/%u" para fornecer directórios home pessoais para utilizadores sem o atributo homeDirectory. Se o seu Domínio AD está povoado apropriadamente com atributos Posix, e você quer evitar este comportamento de recurso, você pode explicitamente definir "fallback_homedir = %o".

Note que o sistema tipicamente espera um directório home na pasta /home/%u: Se você decidir usar uma estrutura diferente de directórios, outras partes do seu sistema podem precisar de ser ajustadas.

Como exemplo a criação automática de directórios home em combinação com selinux requer afinação do selinux, caso contrário o directório home será criado com contexto selinux errado.

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

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 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.

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”.

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).

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.

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

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

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

A funcionalidade de mapeamento de ID permite ao SSSD actuar como um cliente de Active Directory sem requerer aos administradores estenderem os atributos de utilizador para suportar atributos POSIX para identificadores de utilizador e grupo.

NOTA: Quando o mapeamento de ID está activo, os atributos uidNumber e gidNumber são ignorados. Isto é para evitar a possibilidade de conflitos entre valores designados automaticamente e designados manualmente. Se você precisa usar valores designados manualmente, TODOS os valores têm de ser atribuídos manualmente.

Por favor note que alterar as opções de configuração relacionadas com mapeamento de ID irá fazer com que os IDs de utilizador e grupo mudem. De momento, o SSSD não suporta alterar os IDs, assim a base de dados do SSSD tem de ser removida. Porque as palavras passe em cache são também guardadas na base de dados, remover a base de dados só deve ser feito enquanto os servidores de autenticação estão alcançáveis, caso contrário os utilizadores podem ficar bloqueados de fora. De modo a palavra passe em cache, tem de ser executada uma autenticação. Não é suficiente usar sss_cache(8) para remover a base de dados, em vez disso o processo consiste de:

•Certificar que os servidores remotos são alcançáveis
•Parar serviço SSSD
•Remover a base de dados
•Arrancar o serviço SSSD

Mais ainda, como a mudança de IDs pode necessitar de ajustes noutras propriedades do sistema tais como o dono de ficheiros e directórios, é recomendado planear com antecedência e testar a configuração do mapeamento de ID meticulosamente.

Active Directory fornece um objectSID para cada objecto utilizador e grupo no directório. Este objectSID pode ser partido em componentes que representam a identidade de domínio Active Directory e o identificador relativo (RID) do objecto utilizador ou grupo.

O algoritmo de mapeamento de ID do SSSD toma uma gama de UIDs disponíveis e divide-a em secções de componente de tamanho igual - chamadas fatias ou "slices"-. Cada fatia representa o espaço disponível para um domínio Active Directory.

Quando uma entrada de utilizador ou grupo para um domínio particular é encontrada pela primeira vez, o SSSD aloca uma das fatias disponíveis para esse domínio. De modo a tornar esta atribuição de fatia repetível em diferentes máquinas cliente, nós selecionamos a fatia com base no seguinte algoritmo:

A string SID é passada através do algoritmo murmurhash3 para a converter num valor cinza de 32-bit. Depois nós pegamos no modulus deste valor com o número total de fatias disponíveis para escolher a fatia.

NOTA: É possível de se encontrar colisões na cinza e modulus subsequentes. Nestas situações, iremos selecionar a próxima fatia disponível, mas pode não ser possível de reproduzir o mesmo conjunto exacto de fatias em outras máquinas (pois a ordem com que são encontradas irá determinar a sua fatia). Nesta situação, é recomendado ou mudar para usar atributos POSIX explícitos em Active Directory (desactivando o mapeamento de ID) ou configurar um domínio predefinido para garantir que pelo menos um é sempre consistente. Veja “Configuração” para detalhes.

Configuração mínima (na secção “[domain/DOMAINNAME]”):

ldap_id_mapping = True
ldap_schema = ad

A configuração predefinida consiste em configurar 10,000 fatias, cada uma capaz de conter até 200,000 IDs, a começar de 200,000 e ir até a 2,000,200,000. Isto deve ser suficiente para a maioria dos desenvolvimentos.

Configuração Avançada

ldap_idmap_range_min (inteiro)

Especifica o limite mais baixo (inclusive) do alcance de IDs POSIX a usar para mapear SIDs de utilizador e grupo Active Directory. É o primeiro ID POSIX que pode ser usado para o mapeamento.

NOTA: Esta opção é diferente de “min_id” em que “min_id” actua para filtrar o resultado de pedidos a este domínio, ao passo que esta opção controla a gama de atribuição de ID. Esta é uma distinção subtil, mas o bom conselho geral será que “min_id” seja menor ou igual a “ldap_idmap_range_min”

Predefinição: 200000

ldap_idmap_range_max (inteiro)

Especifica o limite mais alto (exclusivo) do alcance de IDs POSIX a usar para mapear SIDs de utilizador e grupo Active Directory. É o primeiro ID POSIX que não pode mais ser usado para o mapeamento, isto é, um maior que o último que pode ser usado para o mapeamento.

NOTA: Esta opção é diferente de “max_id” em que “max_id” actua para filtrar o resultado de pedidos a este domínio, ao passo que esta opção controla a gama de atribuição de ID. Esta é uma distinção subtil, mas o bom conselho geral será que “max_id” seja maior ou igual a “ldap_idmap_range_max”

Predefinição: 2000200000

ldap_idmap_range_size (inteiro)

Especifica o número de IDs disponível para cada fatia. Se o tamanho do alcance não se dividir uniforme nos valores mínimo e máximo, irá criar o máximo de fatias completas que conseguir.

NOTA: O valor desta opção tem de ser pelo menos tão grande quando o RID planeado do mais alto utilizador para usar no servidor Active Directory. As procuras e login de utilizador irão falhar para qualquer utilizador cujo RID seja maior que este valor.

Por exemplo, o seu utilizador Active Directory adicionado mais recente tem um objectSid=S-1-5-21-2153326666-2176343378-3404031434-1107, “ldap_idmap_range_size” tem de ser pelo menos 1108 pois o tamanho de alcance é igual ao RID máximo menos o RID mínimo mais um (ex. 1108 = 1107 - 0 + 1).

É importante planear com antecedência para futura expansão, pois modificar este valor ira resultar e modificar todos os mapeamentos de ID no sistema, deixando os utilizadores com IDs locais diferentes dos que antes tinham.

Predefinição: 200000

ldap_idmap_default_domain_sid (string)

Especifica o SID de domínio do domínio predefinido. Isto irá garantir que este domínio irá sempre ser atribuído à fatia zero no mapa de ID, contornando o algoritmo murmurhash descrito em cima.

Predefinição: não definida

ldap_idmap_default_domain (string)

Especifica o nome do domínio predefinido.

Predefinição: não definida

ldap_idmap_autorid_compat (booleano)

Muda o comportamento do algoritmo de mapeamento de ID para se comportar de modo mais semelhante ao algoritmo “idmap_autorid” do winbind.

Quando esta opção está configurada, os domínios serão alocados começando da fatia zero e aumentando monotonicamente com cada domínio adicional.

NOTA: Este algoritmo é não-determinístico (depende da ordem em que os utilizadores e grupos são requisitados). Se este modo for requerido para compatibilidade com máquinas que correm winbind, é recomendado que se também use a opção “ldap_idmap_default_domain_sid” para garantir que pelo menos um domínio é consistentemente alocado para a fatia zero.

Predefinição: False

ldap_idmap_helper_table_size (inteiro)

Número máximo de fatias secundárias que é tentado quando se executa mapeamento de id UNIX para SID.

Nota: Podem ser geradas fatias secundárias adicionais quando o SID está a ser mapeado para id de UNIX e RID parte do SID está fora de alcance para as fatias secundárias geradas até ao momento. Se o valor de ldap_idmap_helper_table_size for igual a 0 então nenhuma fatia secundária adicional será gerada.

Predefinido: 10

SSSD suporta procurar nomes de SIDs Well-Known, isto é, SIDs com um significado especial codificado. Como os utilizadores e grupos genéricos relacionados a esses SIDs Well-Known não têm equivalente num ambiente Linux/UNIX, nenhuns IDs de POSIX estão disponíveis para esses objectos.

O espaço de nome SID está organizado em autoridades que podem ser vistas como diferentes domínios. As autoridades para os SIDs Well-Known são

•Null Authority
•World Authority
•Local Authority
•Creator Authority
•Mandatory Label Authority
•Authentication Authority
•NT Authority
•Built-in

As versões capitalizada desses nomes são usadas como nomes de domínio quando se retorna o nome totalmente qualificado de um SID Well-Known.

Como alguns utilitários permitem modificar informação de controle de acesso baseado em SID com a ajuda de um nome em vez de se usar o SID diretamente, o SSSD suporta procurar o SID pelo nome também. Para evitar colisões apenas os nomes totalmente qualificados podem ser usados para procurar SIDs Well-Known. Como resultado os nomes de domínio “NULL AUTHORITY”, “WORLD AUTHORITY”, “ LOCAL AUTHORITY”, “CREATOR AUTHORITY”, “MANDATORY LABEL AUTHORITY”, “AUTHENTICATION AUTHORITY”, “NT AUTHORITY” e “BUILTIN” não devem ser usados como nomes de domínio no sssd.conf.

O seguinte exemplo assume que o SSSD está actualmente configurado e example.com é um dos domínios na secção [sssd]. Este exemplo mostra apenas as opções específicas do provedor AD.

[domain/EXAMPLE]
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad
ad_server = dc1.example.com
ad_hostname = client.example.com
ad_domain = example.com

O provedor de controle de acesso AD verifica se a conta expirou. Tem o mesmo efeito que a seguinte configuração do provedor LDAP:

access_provider = ldap
ldap_access_order = expire
ldap_account_expire_policy = ad

No entanto, a menos que o provedor de controle de acesso “ad” seja explicitamente configurado, o provedor de acesso predefinido é “permit”. Por favor note que se você configurar um provedor de acesso diferente do “ad”, você tem de definir todos os parâmetros da ligação (tal como URIs do LDAP e detalhes de encriptação) manualmente.

Quando o provedor autofs é definido para “ad”, é usado o mapeamento de atributos esquema RFC2307 (nisMap, nisObject, ...), porque estes atributos estão incluídos no esquema Active Directory predefinido.

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)

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

1.
Grupos de segurança Active Directory
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups
2.
secção [MS-ADTS] extensões do LDAP
https://msdn.microsoft.com/en-us/library/cc223367.aspx
01/18/2026 SSSD