SSSD-AD(5) Formatos de Ficheiros e Conven SSSD-AD(5) NAME sssd-ad - Provedor Active Directory do SSSD DESCRICAO Este manual descreve a configuracao do provedor AD sssd(8). Para uma referencia detalhada da sintaxe, consulte a seccao "FORMATO DE FICHEIRO" do manual sssd.conf(5). O provedor AD e um backend usado para ligar a um servidor Active Directory. este provedor requer que a maquina seja junta ao dominio AD e que esteja disponivel uma keytab. A comunicacao com o backend ocorre por um canal encriptado em GSSAPI, as opcoes de SSL/TLS nao devem ser usadas com o provedor AD e serao sobrepostas por utilizacao do Kerberos. O provedor AD suporta ligar a Active Directory 2008 R2 ou posterior. As versoes anteriores podem funcionar, mas nao sao suportadas. O provedor AD pode ser usado para obter informacao e autenticar utilizadores de dominios de confianca. Presentemente apenas dominios de confianca na mesma floresta sao reconhecidos. Adicionalmente, servidores de dominios de confianca sao sempre auto-descobertos. O provedor AD permite ao SSSD usar o provedor de identidade sssd- ldap(5) e o provedor de autenticacao sssd-krb5(5) com optimizacoes para ambientes Active Directory. O provedor AD aceita as mesmas opcoes usadas pelos provedores sssd-ldap e sssd-krb5 com algumas excepcoes. No entanto, nao e necessario nem recomendado definir estas opcoes. O provedor AD primariamente copia as opcoes predefinidas dos provedores ldap e krb5 tradicionais com algumas excepcoes, as diferencas sao listadas na seccao "OPCOES PREDEFINIDAS MODIFICADAS". O provedor AD pode tambem ser usado como provedor de acesso, chpass, sudo e autofs. Nenhuma configuracao do provedor de acesso e requerida no lado cliente. Se "auth_provider=ad" ou "access_provider=ad" estiverem configurados no sssd.conf entao o id_provider tem tambem de ser definido para "ad". Por predefinicao, o provedor AD ira mapear valores UID e GID a partir do parametro objectSID em Active Directory. Para detalhes sobre isto, veja a seccao "MAPEAMENTO de ID" em baixo. Se voce deseja desligar o mapeamento de ID e em vez disso confiar nos atributos POSIX definidos em Active Directory, voce deve definir ldap_id_mapping = False Se devem ser usados atributos POSIX, e recomendado por razoes de performance que os atributos sejam tambem replicados para o Global Catalog. Se os atributos POSIX forem replicados, o SSSD ira tentar localizar o dominio de um ID numerico pedido com a ajuda do Global Catalog e apenas procura nesse dominio. Em contraste, se os atributos POSIX nao forem replicados no Global Catalog, o SSSD tem de procurar em todos os dominios na floresta sequencialmente. Por favor note que a opcao "cache_first" pode tambem ajudar a acelerar as buscas dos dominios. Note que se apenas um sub-conjunto de atributos POSIX estiver presente no Global Catalog, os atributos nao-replicados atualmente nao sao lidos a partir do porto LDAP. Utilizadores, grupos e outras entidades servidas pelo SSSD sao sempre tratadas com insensibilidade a maiusculas/minusculas no provedor AD para compatibilidade com a implementacao LDAP do Active Directory. SSSD apenas resolve Grupos de Seguranca Active Directory. Para mais informacao sobre tipos de grupo AD veja: Grupos de seguranca Active Directory[1] SSSD filtra e separa grupos Domain Local de dominios remotos na floresta AD. Por predefinicao eles sao filtrados por ex quando se segue uma hierarquia de grupo aninhado em dominios remotos porque eles nao sao validos no dominio local. Isto e feito para se estar de acordo com a atribuicao de membros de grupo de Active Directory que pode ser visto no PAC do bilhete Kerberos dum utilizador publicado por Active Directory. OPCOES DE CONFIGURACAO Consulte a seccao "SECCOES DE DOMINIO" do manual sssd.conf(5) para detalhes da configuracao de um dominio SSSD. ad_domain (string) Especifica o nome do dominio Active Directory. Isto e opcional. Se nao for fornecido, e usado o nome de dominio da configuracao. Para operacao apropriada, esta opcao deve ser especificada como a versao curta da versao longa do dominio Active Directory. O nome de dominio curto (tambem conhecido como NetBIOS ou nome liso) e auto-detectado pelo SSSD. ad_enabled_domains (string) Uma lista separada por virgulas de dominios Active Directory activos. Se fornecida, o SSSD ira ignorar quaisquer dominios nao listados nesta opcao. Se deixada por definir, todos os dominios da floresta AD irao estar disponiveis. Durante a descoberta de dominios, o SSSD ira filtrar alguns dominios onde as bandeiras ou atributos indicam que eles nao pertencem a floresta local ou nao sao de confianca. Se ad_enabled_domains estiver definido, o SSSD ira tentar ativar todos os dominios listados. Para operacao apropriada, esta opcao tem de ser especificada toda em minusculas e como o nome de dominio totalmente qualificado do dominio Active Directory. Por exemplo: ad_enabled_domains = sales.example.com, eng.example.com O nome de dominio curto (tambem conhecido como NetBIOS ou nome liso) sera auto-detectado pelo SSSD. Predefinicao: Nao definida ad_server, ad_backup_server (string) A lista separada por virgulas de nomes de maquinas dos servidores AD aos quais o SSSD deve ligar por ordem de preferencia. Consulte a seccao "FAILOVER" para mais informacao sobre failover e redundancia de servicos. Isto e opcional se a auto-descoberta estiver activa. Para mais informacao sobre descoberta de servicos, consulte a seccao "DESCOBERTA DE SERVICOS". Nota: Dominios de confianca irao sempre auto-descobrir servidores mesmo que o servidor primario esteja explicitamente definido na opcao ad_server. ad_hostname (string) Opcional. Em maquinas onde o nome-de-maquina(5) nao reflete o nome qualificado completo, o sssd ira tentar expandir o nome curto. Se tal nao for possivel ou se e o nome curto que deve realmente ser usado, defina este parametro explicitamente. Este campo e usado para determinar a principal maquina em uso na keytab e para executar actualizacoes DNS dinamicas. Tem de corresponder ao nome de maquina para a qual a keytab foi emitida. ad_enable_dns_sites (booleano) Activa sitios DNS - descoberta de servicos baseada em localizacao. Se true e a descoberta de servicos (veja o paragrafo Descoberta de Servicos no fundo do manual) estiver activa, o SSSD ira 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 sitio AD for encontrado. A configuracao DNS SRV, incluindo o dominio de descoberta, e usada tambem durante a descoberta de sitios. Predefinicao: true ad_access_filter (string) Especifica um filtro de controle de acesso LDAP que o utilizador tem de corresponder para obter acesso. A opcao "access_provider" tem de ser explicitamente definida para "ad" para esta opcao ter efeito. Se voce desejar usar o "ad_access_filter" como unico esquema de controle de acesso, voce tem de desativar o controle de acesso baseado em GPO (veja a opcao "ad_gpo_access_control" para detalhes). A opcao tambem suporta especificar filtros diferentes por dominio ou floresta. Este filtro estendido ira 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, entao "NAME" especifica o dominio ou sub-dominio a que o filtro se aplica. Se a palavra chave for igual a "FOREST", entao o filtro e igual a todos os dominios da floresta especificada por "NAME". Multiplos filtros podem ser separados com o caractere "?", de modo semelhante a como funcionam as bases de busca. Os membros de grupo aninhado tem de ser procurados para usarem um OID especial ":1.2.840.113556.1.4.1941:" em adicao a sintaxe DOM:domain.example.org: completa para assegurar que o analisador nao tenta interpretar os caracteres dois pontos associados com o OID. Se voce nao usar este OID entao os membros de grupo aninhado nao serao resolvidos. Veja a utilizacao do exemplo em baixo e consulte aqui mais informacao sobre o OID: seccao [MS-ADTS] extensoes do LDAP[2] A correspondencia mais especifica e sempre usada. Por exemplo, se a opcao especificou um filtro para um dominio que o utilizador e membro e um filtro global, sera aplicado o filtro por-dominio. Se existirem mais correspondencias com a mesma especificacao, e 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) Predefinicao: Nao definida ad_site (string) Especifica o sitio AD ao qual o cliente deve tentar ligar. Se esta opcao nao for fornecida, o sitio AD sera auto-descoberto. Predefinicao: Nao definida ad_enable_gc (booleano) Por predefinicao, o SSSD liga-se ao Global Catalog primeiro para obter utilizadores dos dominios de confianca e usa o porto LDAP para obter os membros dos grupos ou como um recurso em caso de falha. Desactivar esta opcao 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 nao desactiva o obter de utilizadores de dominios de confianca. O SSSD deve ligar ao porto LDAP dos dominios de confianca. No entanto, Global Catalog tem de ser usado de modo a se resolver membros de grupos de dominios-cruzados. Predefinicao: true ad_gpo_access_control (string) Esta opcao especifica o modo de operacao para a funcionalidade de controle de acesso baseado em GPO. Se vai operar em modo desactivado, modo forcado, ou modo permissivo. Por favor note que a opcao "access_provider" tem de ser explicitamente definida para "ad" de modo a esta opcao ter efeito. A funcionalidade de controle de acesso baseada em GPO usa definicoes de politica GPO para determinar se e ou nao concedida permissao a um utilizador particular de fazer login na maquina. Para mais informacao sobre as definicoes de politicas suportadas por favor consulte as opcoes "ad_gpo_map". Por favor note que a versao actual do SSSD nao 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 serao 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 seguranca de politica de grupo nos GPOs. Para cada login de utilizador singular, e verificada a aplicabilidade dos GPOs que estao vinculados a maquina. 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 permissoes no GPO: o Read: O utilizador ou um dos seus grupos tem de ter acesso de leitura as propriedades do GPO (RIGHT_DS_READ_PROPERTY) o Apply Group Policy: O utilizador ou pelo menos um dos seus grupos tem de ter permissao para aplicar o GPO (RIGHT_DS_CONTROL_ACCESS). Por predefinicao, o grupo Authenticated Users esta presente num GPO e este grupo tem ambos direitos de acesso Read e Apply Group Policy. Como a autenticacao do utilizador tem de ser completada com sucesso antes da filtragem de seguranca GPO e o controle de acesso ser arrancado, as permissoes do grupo Authenticated Users no GPO tambem se aplicam sempre ao utilizador. NOTA: Se o modo de operacao esta definido para forcar, e possivel que os utilizadores que antes tinham permissao de acesso de login tenham agora o acesso de login negado (como ditado pelas definicoes de politica GPO). De modo a facilitar uma transicao suave para administradores, esta disponivel um modo permissivo que nao ira forcar as regras de controlo de acesso, mas ira avalia-las e ira escrever uma mensagem no syslog se o acesso teria sido negado. Ao examinar os registos, os administradores podem entao fazer as mudancas necessarias antes de definirem o modo de forcar. Para registar o controle de acesso baseado em GPO e requerido o nivel de depuracao 'trace functions' (veja o manual sssctl(8)). Existem tres valores suportados para esta opcao: o disabled: as regras de controlo de acesso baseadas em GPO nao sao avaliadas nem forcadas. o enforcing: as regras de controlo de acesso baseadas em GPO sao avaliadas e forcadas. o permissive: As regras de controle de acesso baseadas em GPO sao avaliadas, mas nao impostas. Em vez de negar acesso, e emitida uma mensagem no syslog indicando que o utilizador teria o acesso negado, se o valor desta opcao estivesse definido para enforcing. Predefinicao: enforcing ad_gpo_implicit_deny (booleano) Normalmente quando sao encontrados GPOs nao aplicaveis, os utilizadores tem o acesso concedido. Quando esta opcao e definida para True os utilizadores terao permissao de acesso apenas quando explicitamente concedida por uma regra GPO. Caso contrario os utilizadores terao o acesso negado. Isto pode ser usado para endurecer a seguranca mas tenha cuidado quando usar esta opcao porque pode negar acesso ate a utilizadores do grupo embutido Administrators se nenhuma regra GPO se aplicar a eles. Predefinicao: False As 2 tabelas seguintes devem ilustrar quando um utilizador e permitido ou negado com base dos direitos de concessao ou negacao de login definidos no lado servidor e na definicao de ad_gpo_implicit_deny. +-----------------------------------------------+ | ad_gpo_implicit_deny = False (predefinido) | +------------+------------+---------------------+ |allow-rules | deny-rules | results | +------------+------------+---------------------+ | missing | missing | todos os | | | | utilizadores tem | | | | permissao | +------------+------------+---------------------+ | missing | present | apenas utilizadores | | | | nao em deny-rules | | | | tem permissao | +------------+------------+---------------------+ | present | missing | apenas utilizadores | | | | em allow-rules tem | | | | permissao | +------------+------------+---------------------+ | present | present | apenas utilizadores | | | | em allow-rules e | | | | nao em deny-rules | | | | tem permissao | +------------+------------+---------------------+ +-----------------------------------------------+ | ad_gpo_implicit_deny = True | +------------+------------+---------------------+ |allow-rules | deny-rules | results | +------------+------------+---------------------+ | missing | missing | nenhum utilizador | | | | tem permissao | +------------+------------+---------------------+ | missing | present | nenhum utilizador | | | | tem permissao | +------------+------------+---------------------+ | present | missing | apenas utilizadores | | | | em allow-rules tem | | | | permissao | +------------+------------+---------------------+ | present | present | apenas utilizadores | | | | em allow-rules e | | | | nao em deny-rules | | | | tem permissao | +------------+------------+---------------------+ ad_gpo_ignore_unreadable (booleano) Normalmente quando algum contentor de politica de grupo (objecto AD) de objecto de politica de grupo aplicavel nao pode ser lido pelo SSSD entao os utilizadores tem o acesso negado. Esta opcao permite ignorar os contentores de politica de grupo e com eles as politicas associadas se os seus atributos nesses contentores nao forem legiveis pelo SSSD. Predefinicao: False ad_gpo_cache_timeout (inteiro) A quantidade de tempo entre procuras de ficheiros de politica GPO num servidor AD. Isto ira reduzir a latencia e carga no servidor AD se existirem muitos pedidos de controle de acesso feitos num curto periodo. Predefinicao: 5 (segundos) ad_gpo_map_interactive (string) Uma lista separada por virgulas de nomes de servico PAM para os quais o controle de acesso baseado em GPO e avaliado com base nas definicoes de politica InteractiveLogonRight e DenyInteractiveLogonRight. Apenas esses GPOs sao avaliados para os quais o utilizador tem permissao Read e Apply Group Policy (veja a opcao "ad_gpo_access_control"). Se um GPO avaliado conter a definicao de logon interactivo deny para o utilizador ou para um dos seus grupos, ao utilizador e negado acesso local. Se nenhum dos GPOs avaliados tiver um direito de logon interactivo definido, ao utilizador e concedido acesso local. Se pelo menos um GPO avaliado conter definicoes de direito de logon interactivo, ao utilizador e concedido acesso local apenas, se ele ou pelo menos um dos seus grupos fizer parte das definicoes de politica. Nota: Usando o Editor de Gestao de Politica de Grupo este valor e chamado "Allow log on locally" e "Deny log on locally". E possivel adicionar outro nome de servico PAM ao conjunto predefinido ao usar "+service_name" ou removendo explicitamente um nome de servico PAM do conjunto predefinido ao usar "-service_name". Por exemplo, de modo a substituir um nome de servico PAM predefinido por este direito de login (ex. "login") por um nome de servico pam personalizado (ex. "my_pam_service"), voce devera usar a seguinte configuracao: ad_gpo_map_interactive = +my_pam_service, -login Predefinicao: o conjunto predefinido de nomes de servicos do PAM inclui: o login o su o su-l o gdm-fingerprint o gdm-password o gdm-smartcard o kdm o lightdm o lxdm o plasmalogin o sddm o unity o xdm ad_gpo_map_remote_interactive (string) Uma lista separada por virgulas de nomes de servico PAM para os quais o controle de acesso baseado em GPO e avaliado com base nas definicoes de politica RemoteInteractiveLogonRight e DenyRemoteInteractiveLogonRight. Apenas esses GPOs sao avaliados para os quais o utilizador tem permissao Read e Apply Group Policy (veja a opcao "ad_gpo_access_control"). Se um GPO avaliado conter a definicao de logon remoto interactivo deny para o utilizador ou para um dos seus grupos, ao utilizador e negado acesso remoto. Se nenhum dos GPOs avaliados tiver um direito de logon remoto interactivo definido, ao utilizador e concedido acesso remoto. Se pelo menos um GPO avaliado conter definicoes de direito de logon remoto interactivo, ao utilizador e concedido acesso remoto apenas, se ele ou pelo menos um dos seus grupos fizer parte das definicoes de politica. Nota: Usando o Editor de Gestao de Politica de Grupo este valor e chamado "Allow log on through Remote Desktop Services" e "Deny log on through Remote Desktop Services". E possivel adicionar outro nome de servico PAM ao conjunto predefinido ao usar "+service_name" ou removendo explicitamente um nome de servico PAM do conjunto predefinido ao usar "-service_name". Por exemplo, de modo a substituir um nome de servico PAM predefinido por este direito de login (ex. "sshd") por um nome de servico pam personalizado (ex. "my_pam_service"), voce devera usar a seguinte configuracao: ad_gpo_map_remote_interactive = +my_pam_service, -sshd Predefinicao: o conjunto predefinido de nomes de servicos do PAM inclui: o sshd o cockpit ad_gpo_map_network (string) Uma lista separada por virgulas de nomes de servico PAM para os quais o controle de acesso baseado em GPO e avaliado com base nas definicoes de politica NetworkLogonRight e DenyNetworkLogonRigh. Apenas esses GPOs sao avaliados para os quais o utilizador tem permissao Read e Apply Group Policy (veja a opcao "ad_gpo_access_control"). Se um GPO avaliado conter a definicao de logon de rede interactivo deny para o utilizador ou para um dos seus grupos, ao utilizador e negado acesso de rede. Se nenhum dos GPOs avaliados tiver um direito de logon de rede interactivo definido, ao utilizador e concedido acesso. Se pelo menos um GPO avaliado conter definicoes de direito de logon de rede interactivo, ao utilizador e concedido acesso apenas, se ele ou pelo menos um dos seus grupos fizer parte das definicoes de politica. Nota: Usando o Editor de Gestao de Politica de Grupo este valor e chamado "Access this computer from the network" e "Deny access to this computer from the network". E possivel adicionar outro nome de servico PAM ao conjunto predefinido ao usar "+service_name" ou removendo explicitamente um nome de servico PAM do conjunto predefinido ao usar "-service_name". Por exemplo, de modo a substituir um nome de servico PAM predefinido por este direito de login (ex. "ftp") por um nome de servico pam personalizado (ex. "my_pam_service"), voce devera usar a seguinte configuracao: ad_gpo_map_network = +my_pam_service, -ftp Predefinicao: o conjunto predefinido de nomes de servicos do PAM inclui: o ftp o samba ad_gpo_map_batch (string) Uma lista separada por virgulas de nomes de servico PAM para os quais o controle de acesso baseado em GPO e avaliado com base nas definicoes de politica BatchLogonRight e DenyBatchLogonRight. Apenas esses GPOs sao avaliados para os quais o utilizador tem permissao Read e Apply Group Policy (veja a opcao "ad_gpo_access_control"). Se um GPO avaliado conter a definicao de logon em lote interactivo deny para o utilizador ou para um dos seus grupos, ao utilizador e negado acesso em lote. Se nenhum dos GPOs avaliados tiver um direito de logon em lote interactivo definido, ao utilizador e concedido acesso. Se pelo menos um GPO avaliado conter definicoes de direito de logon em lote interactivo, ao utilizador e concedido acesso apenas, se ele ou pelo menos um dos seus grupos fizer parte das definicoes de politica. Nota: Usando o Editor de Gestao de Politica de Grupo este valor e chamado "Allow log on as a batch job" e "Deny log on as a batch job". E possivel adicionar outro nome de servico PAM ao conjunto predefinido ao usar "+service_name" ou removendo explicitamente um nome de servico PAM do conjunto predefinido ao usar "-service_name". Por exemplo, de modo a substituir um nome de servico PAM predefinido por este direito de login (ex. "crond") por um nome de servico pam personalizado (ex. "my_pam_service"), voce devera usar a seguinte configuracao: ad_gpo_map_batch = +my_pam_service, -crond Nota: O nome do servico Cron pode diferir dependendo da distribuicao Linux usada. Predefinicao: o conjunto predefinido de nomes de servicos do PAM inclui: o crond ad_gpo_map_service (string) Uma lista separada por virgulas de nomes de servico PAM para os quais o controle de acesso baseado em GPO e avaliado com base nas definicoes de politica ServiceLogonRight e DenyServiceLogonRight. Apenas esses GPOs sao avaliados para os quais o utilizador tem permissao Read e Apply Group Policy (veja a opcao "ad_gpo_access_control"). Se um GPO avaliado conter a definicao de logon de servico deny para o utilizador ou para um dos seus grupos, ao utilizador e negado acesso de servico. Se nenhum dos GPOs avaliados tiver um direito de logon de servico definido, ao utilizador e concedido acesso. Se pelo menos um GPO avaliado conter definicoes de direito de logon de servico, ao utilizador e concedido acesso apenas, se ele ou pelo menos um dos seus grupos fizer parte das definicoes de politica. Nota: Usando o Editor de Gestao de Politica de Grupo este valor e chamado "Allow log on as a service" e "Deny log on as a service". E possivel adicionar um nome de servico PAM ao conjunto predefinido ao usar "+service_name". Como o conjunto predefinido esta vazio, nao e possivel remover um nome de servico PAM do conjunto predefinido. Por exemplo, de modo a adicionar um servico pam personalizado (ex. "my_pam_service"), voce deve usar a seguinte configuracao: ad_gpo_map_service = +my_pam_service Predefinicao: nao definida ad_gpo_map_permit (string) Uma lista separada por virgulas de nomes de servico PAM para os quais o acesso baseado em GPO e sempre concedido, independentemente de quaisquer Direitos de Logon GPO. E possivel adicionar outro nome de servico PAM ao conjunto predefinido ao usar "+service_name" ou removendo explicitamente um nome de servico PAM do conjunto predefinido ao usar "-service_name". Por exemplo, de modo a substituir um nome de servico PAM predefinido por um de acesso permitido incondicionalmente (ex. "sudo") por um nome de servico pam personalizado (ex. "my_pam_service"), voce devera usar a seguinte configuracao: ad_gpo_map_permit = +my_pam_service, -sudo Predefinicao: o conjunto predefinido de nomes de servicos do PAM inclui: o polkit-1 o sudo o sudo-i o systemd-user ad_gpo_map_deny (string) Uma lista separada por virgulas de nomes de servico PAM para os quais o acesso baseado em GPO e sempre negado, independentemente de quaisquer Direitos de Logon GPO. E possivel adicionar um nome de servico PAM ao conjunto predefinido ao usar "+service_name". Como o conjunto predefinido esta vazio, nao e possivel remover um nome de servico PAM do conjunto predefinido. Por exemplo, de modo a adicionar um servico pam personalizado (ex. "my_pam_service"), voce deve usar a seguinte configuracao: ad_gpo_map_deny = +my_pam_service Predefinicao: nao definida ad_gpo_default_right (string) Esta opcao define como o controle de acesso e avaliado para nomes de servico PAM que nao estao listados explicitamente em uma das opcoes ad_gpo_map_*. Esta opcao pode ser definida de duas maneiras diferentes. Primeiro, esta opcao pode ser definida para se usar um direito de login predefinido. Por exemplo, se esta opcao for definida para 'interactive', significa que os nomes de servicos PAM nao mapeados irao ser processados com base nas definicoes de politica InteractiveLogonRight e DenyInteractiveLogonRight. Em alternativa, esta opcao pode ser definida para ou permitir sempre ou negar sempre o acesso a nomes de servicos PAM nao mapeados. Os valores suportados para esta opcao incluem: o interactive o remote_interactive o network o batch o service o permit o deny Predefinicao: deny ad_maximum_machine_account_password_age (inteiro) O SSSD ira verificar uma vez por dia se a palavra passe da conta da maquina e mais antiga que a idade dada em dias e tentar renova-la. Um valor de 0 ira desactivar a tentativa de renovacao. Predefinicao: 30 dias ad_machine_account_password_renewal_opts (string) Esta opcao so deve ser usada para testar a tarefa de renovacao de conta da maquina. A opcao espera 3 inteiros separados por dois pontos (':'). O primeiro inteiro define o intervalo em segundos da frequencia que a tarefa ira correr. O segundo especifica o tempo limite inicial em segundos antes da tarefa correr pela primeira vez apos o arranque. O terceiro valor opcional especifica um desvio aleatorio maximo aos dois valores anteriores para evitar atualizacoes de muitas maquinas ao mesmo tempo ("problema estranho trovejante"). Se este valor estiver em falta ou vazio sera usado o valor string '0'. O quarto valor string opcional identifica o binario ajudante que deve ser usado para a renovacao. Atualmente sao suportados adcli e realm. Se este valor estiver em falta ou vazio na string de valor sera usado realm . Como o ajudante e arrancado como o utilizador do SSSD que o corre pode haver uma hipotese que a renovacao va falhar se este utilizador nao tiver permissao para modificar o ficheiro keytab onde estao guardadas as credenciais da conta da maquina. Este sera tipicamente o caso de adcli. realm nao esta a atualizar a keytab diretamente mas esta a chamar o processo realmd, o qual corre como utilizador root, para esta tarefa. realmd pode permitir acesso a utilizadores nao-privilegiados coma a ajuda de PolicyKit e por predefinicao o SSSD fornece regras apropriadas para o utilizador que o SSSD esta a correr como. Predefinicao: 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 maquina, sera tambem actualizada na base de dados do Samba. Isto previne que a copia do Samba da palavra passe da conta da maquina fique desactualizada quando e configurada para usar AD para autenticacao. Predefinicao: false ad_use_ldaps (booleano) Por predefinicao o SSSD usa o porto 389 do LDAP simples e o porto 3628 do Global Catalog. Se esta opcao estiver definida para True, o SSSD ira usar o porto 636 do LDAPS e o porto 3629 do Global Catalog com protecao LDAPS. Como o AD nao permite ter multiplas camadas de encriptacao numa unica ligacao, e nos ainda queremos usar SASL/GSSAPI ou SASL/GSS-SPNEGO para autenticacao a propriedade de seguranca do SASL maxssf e definida para 0 (zero) para essas ligacoes. Predefinicao: False dyndns_update (booleano) Opcional. Esta opcao diz ao SSSD para actualizar automaticamente o servidor DNS Active Directory com o endereco IP deste cliente. A actualizacao e segura usando GSS-TSIG. Como uma consequencia, o administrador do Active Directory so precisa de permitir actualizacoes seguras para a zona do DNS. O endereco IP da ligacao LDAP AD e usado para as actualizacoes, se nao for caso contrario especificado ao se usar a opcao "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 Predefinicao: true dyndns_ttl (inteiro) O TTL a aplicar ao registo de cliente DNS quando o actualiza. Se dyndns_update for false isto nao tem efeito. Isto ira sobrepor o TTL do lado servidor se definido por um administrador. Predefinicao: 3600 (segundos) dyndns_iface (string) Opcional. Aplicavel apenas quando dyndns_update e true. Escolhe a interface ou uma lista de interfaces cujos enderecos IP devem ser usados para actualizacoes de dynamic DNS. O nome da interface pode ser um padrao wildcard prefixado com ! para exclusao da interface. A primeira correspondencia para a avaliacao. Por exemplo listar !eth1, * instrui o SSSD a usar todas as interfaces excepto eth1. Veja man 7 glob para detalhes sobre padroes. NOTA: Apesar de ainda ser possivel usar a opcao antiga ipa_dyndns_iface, os utilizadores devem migrar para usar dyndns_iface no seu ficheiro de configuracao. Predefinicao: Usa o endereco IP da interface que e usada para ligacao AD LDAP Exemplo: dyndns_iface = em[12], !vnet1, vnet* dyndns_address (string) Opcional. Aplicavel apenas quando dyndns_update e verdadeiro. Uma lista de enderecos IP ou redes IP a usar para atualizacoes de DNS dinamicas. Enderecos de rede tem de estar no formato CIDR. Uma entrada pode ser prefixada com ! para indicar exclusao. O best match e usado para determinar se um endereco e incluido ou excluido (isto e, um prefixo mais longo tem precedencia). Predefinicao: Nenhuma filtragem de enderecos IP. Exemplo: dyndns_address = 10.0.0.0/16, !10.0.1.0/24 dyndns_refresh_interval (inteiro) Quao frequente deve o backend executar a actualizacao DNS periodica em adicao a actualizacao automatica executada quando o backend fica online. Esta opcao e opcional e aplicavel apenas quando dyndns_update e true. Note que o valor mais baixo possivel e 60 segundos, no caso de o valor fornecido ser inferior a 60, o parametro ira assumir apenas o menor valor. Predefinicao: 86400 (24 horas) dyndns_update_ptr (booleano) Se o registo PTR tambem deve ser explicitamente actualizado quando se actualiza os registos de DNS dos clientes. Aplicavel apenas quando dyndns_update e true. Note que o parametro dyndns_update_per_family nao se aplica para atualizacoes de registo PTR Essas atualizacoes sao sempre enviadas em separado. Predefinicao: True dyndns_force_tcp (booleano) Se o utilitario nsupdate deve por predefinicao usar TCP para comunicar com o servidor DNS. Predefinicao: False (deixa o nsupdate escolher o protocolo) dyndns_auth (string) Se o utilitario nsupdate deve usar autenticacao GSS-TSIG para actualizacoes de seguranca com o servidor DNS, actualizacoes nao seguras podem ser enviadas ao definir esta opcao para 'none'. Predefinicao: GSS-TSIG dyndns_auth_ptr (string) Se o utilitario nsupdate deve usar autenticacao GSS-TSIG para actualizacoes PTR de seguranca com o servidor DNS, actualizacoes nao seguras podem ser enviadas ao definir esta opcao para 'none'. Predefinicao: O mesmo que dyndns_auth dyndns_server (string) O servidor DNS a usar quando executa uma actualizacao de DNS. Na maioria das configuracoes, e recomendado deixar esta opcao por definir. Definir esta opcao faz sentido em ambientes onde o servidor DNS e diferente do servidor de identidade ou quando usamos DNS encriptado. O parametro ode ser uma string simples que contem um nome DNS ou um endereco IP. Tambem 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 atualizacoes de DNS. O utilitario nsupdate tem de suportar DoT - verifique o manual do nsupdate antes de o ativar no SSSD. Por favor note que esta opcao so sera usada em tentativas de recurso quando a tentativa anterior que usa definicoes se auto-deteccao falhe ou quando DNS-sobre-TLS estiver ativo. Predefinicao: None (deixa o nsupdate escolher o servidor) dyndns_update_per_family (booleano) A actualizacao DNS e por predefinicao feita em dois passos - actualizacao IPv4 e depois actualizacao IPv6. Nalguns casos pode ser desejavel executar a actualizacao IPv4 e IPv6 num unico passo. Predefinicao: true dyndns_dot_cacert (string) Esta opcao 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. Predefinicao: Nenhum (usa o armazem de certificados global) dyndns_dot_cert (string) Esta opcao define o ficheiro de certificado(s) para autenticacao para o transporte DoT para o servidor remoto. E esperado que o ficheiro de cadeia de certificados esteja em formato PEM. As opcoes dyndns_dot_cert e dyndns_dot_key tem de ser ambas definidas para se conseguir autenticacao TLS mutua. Predefinicao: Nenhuma (Nao usa autenticacao TLS) dyndns_dot_key (string) Esta opcao define o ficheiro chave para encriptacao autenticada para o transporte DoT ao servidor remoto. E esperado que o ficheiro da chave privada esteja em formato PEM. Predefinicao: Nenhuma (Nao usa autenticacao TLS) override_homedir (string) Sobrepoe o directorio home do utilizador. Voce pode ou fornecer um valor absoluto ou um modelo. No modelo, as seguintes sequencias sao substituidas: %u nome de login %U Numero UID %d nome de dominio %f nome do utilizador totalmente qualificado (utilizador@dominio) %l A primeira letra do nome de login. %P UPN - Nome Principal de Utilizador (nome@REINO) %o O valor homedir que e definido no directorio do provedor de identidade. Esta substituicao foi desenhada para ser usada num cenario de confianca IPA-AD. Se esta substituicao for usada para a opcao subdomain_homedir, vai propagar o valor do directorio home do dominio AD para os clientes IPA. Neste cenario, a opcao tem de ser definida na configuracao SSSD no servidor IPA onde o SSSD esta a correr em modo servidor. %h O caminho definido para o atributo de directorio homedir do provedor de identidade, mas em minusculas. Para detalhes do uso, veja %o. %H O valor da opcao de configuracao homedir_substring. %% um literal '%' Esta opcao tambem pode ser definida por-dominio. exemplo: override_homedir = /home/%u Predefinicao: Nao definida (o SSSD ira usar o valor obtido de LDAP) Por favor note, o directorio home duma sobreposicao especifica para o utilizador, seja localmente (veja sss_override(8)) ou centralmente gerida por id-overrides de IPA , tem uma precedencia mais alta e sera usada em vez do valor dado por override_homedir. homedir_substring (string) O valor desta opcao sera usado na expansao da opcao override_homedir se o modelo conter a string de formato %H. Uma entrada de directorio LDAP pode conter directamente este modelo para que esta opcao possa ser usada para expandir o caminho do directorio home para cada maquina cliente (ou sistema operativo). Pode ser definida por-dominio ou globalmente na seccao [nss]. Um valor especificado numa seccao domain ira sobrepor aquele definido na seccao [nss]. Predefinicao: /home krb5_confd_path (string) Caminho absoluto de um directorio onde o SSSD deve colocar trechos de configuracao do Kerberos. Para desactivar a criacao de trechos de configuracao defina o parametro para 'none'. Predefinicao: nao definida (sub-directorio krb5.include.d do directorio pubconf do SSSD) OPCOES PREDEFINIDAS MODIFICADAS Certas predefinicoes de opcoes nao correspondem as suas predefinicoes de backend respectivos, estes nomes de opcao e predefinicoes especificas de provedor AD estao listadas em baixo: Provedor KRB5 o krb5_validate = true o krb5_use_enterprise_principal = true Provedor LDAP o ldap_schema = ad o ldap_force_upper_case_realm = true o ldap_id_mapping = true o ldap_sasl_mech = GSS-SPNEGO o ldap_referrals = false o ldap_account_expire_policy = ad o ldap_use_tokengroups = true o ldap_sasl_authid = sAMAccountName@REALM (typically SHORTNAME$@REALM) Por predefinicao um provedor AD procura um principal diferente que o provedor LDAP, porque num ambiente Active Directory os principais sao divididos em dois grupos - Principais de Utilizador e Principais de Servico. Apenas o Principal de Utilizador pode ser usado para obter um TGT e por predefinicao, o principal de objecto de computador e constituido pelo seu sAMAccountName e o reino AD, O principal host/hostname@REALM well-known e um Principal de Servico e assim nao pode ser usado para se obter TGT com ele. Configuracao do NSS o fallback_homedir = /home/%d/%u O provedor AD define automaticamente "fallback_homedir = /home/%d/%u" para fornecer directorios home pessoais para utilizadores sem o atributo homeDirectory. Se o seu Dominio AD esta povoado apropriadamente com atributos Posix, e voce quer evitar este comportamento de recurso, voce pode explicitamente definir "fallback_homedir = %o". Note que o sistema tipicamente espera um directorio home na pasta /home/%u: Se voce decidir usar uma estrutura diferente de directorios, outras partes do seu sistema podem precisar de ser ajustadas. Como exemplo a criacao automatica de directorios home em combinacao com selinux requer afinacao do selinux, caso contrario o directorio home sera criado com contexto selinux errado. 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 e dada como uma lista separada por virgulas; e permitido qualquer numero de espacos em volta das virgulas. Os servidores sao listados pela ordem de preferencia. A lista pode conter qualquer numero de servidores. Para cada opcao de configuracao activa-failover, existem duas variantes: primary e backup. A ideia e que os servidores na lista primaria sao preferidos e os servidores backup sao apenas procurados se os servidores primarios nao puderem ser alcancados. Se um servidor backup for selecionado, e definido um tempo limite de 31 segundos. Apos este tempo limite o SSSD ira periodicamente tentar re-ligar a um dos servidores primarios. Se tiver sucesso, ira substituir o servidor actualmente activo (backup). O Mecanismo Failover O mecanismo failover distingue entre uma maquina e um servico. O backend primeiro tenta resolver o nome de maquina de uma dada maquina; se esta tentativa de resolucao falhar, a maquina e considerada offline. Nao sao feitas mais tentativas de ligar a esta maquina para qualquer outro servico. Se a tentativa de resolucao tiver sucesso, o backend tenta ligar a um servico nesta maquina. Se a tentativa de ligacao a servico falhar, entao este servico particular e considerado offline e o backend automaticamente muda para o proximo servico. A maquina continua a ser considerada online e pode ainda ser tentada para outro servico. Sao feitas mais tentativas de ligacao a maquinas ou servicos marcados como offline apos um periodo de tempo especificado; isto e actualmente duramente codificado a 30 segundos. Se nao existirem mais maquinas para tentar, o backend muda todos para modo offline, e depois tenta re-ligar a cada 30 segundos. Tempo limite e afinacao do Failover Resolver um servidor a onde ligar pode ser tao simples como correr uma unica consulta DNS ou pode invocar varios passos, tais como encontrar o sitio correto ou tentar multiplos nomes de maquinas no caso de alguns dos servidores configurados nao estarem alcancaveis. Os cenarios mais complexos podem durar algum tempo e o SSSD precisa de equilibrar entre disponibilizar tempo suficiente para terminar o processo de resolucao mas por outro lado, nao demorar muito tempo antes de regressar ao modo offline. Se os registos de depuracao do SSSD mostrarem que a resolucao do servidor atingiu o tempo limite antes de ser contactado um servidor vivo, voce pode considerar mudar os tempos limite. Esta seccao lista as afinacoes disponiveis. Por favor consulte as suas descricoes no manual sssd.conf(5). dns_resolver_server_timeout Tempo em milissegundos que define quanto tempo deve o SSSD falar com um unico servidor DNS antes de tentar o proximo. Predefinicao: 1000 dns_resolver_op_timeout Tempo em segundos que diz quanto tempo deve o SSSD tentar resolver uma unica consulta DNS (ex. resolucao de um nome de maquina ou dum registo SRV) antes de tentar o proximo nome de maquina ou dominio de descoberta. Predefinicao: 3 dns_resolver_timeout Quanto tempo deve o SSSD tentar resolver um servico failover. Esta resolucao de servico internamente pode incluir varios passos, tal como resolver consultas SRV de DNS ou localizar o sitio. Predefinicao: 6 Para provedores baseados em LDAP, a operacao de resolucao e executada como parte de uma operacao de ligacao LDAP. Assim, tambem 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 SERVICOS A funcionalidade de descoberta de servicos permite aos backends encontrarem automaticamente os servidores apropriados para ligarem para usarem uma consulta DNS especial. Esta funcionalidade nao e suportada para servidores de salvaguarda (backup). Configuracao Se nenhum servidor for especificado, o backend automaticamente usa a descoberta de servicos para tentar encontrar um servidor. Opcionalmente, o utilizador pode escolher usar ambos enderecos de servidor fixos e a descoberta de servicos ao inserir uma palavra chave especial "_srv_", na lista de servidores. A ordem de preferencia e mantida. Esta funcionalidade e util se, por exemplo, o utilizador prefere usar descoberta de servicos sempre que possivel, e regressar a um servidor especifico quando nao se descobrem servidores usando DNS. O nome de dominio Por favor consulte o parametro "dns_discovery_domain" no manual sssd.conf(5) para mais detalhes. O protocolo As consultas geralmente especificam _tcp como o protocolo. As excepcoes estao documentadas na descricao da opcao respectiva. Veja tambem Para mais informacao sobre o mecanismo de descoberta de servicos, consulte RFC 2782. MAPEAMENTO DE ID 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 esta activo, os atributos uidNumber e gidNumber sao ignorados. Isto e para evitar a possibilidade de conflitos entre valores designados automaticamente e designados manualmente. Se voce precisa usar valores designados manualmente, TODOS os valores tem de ser atribuidos manualmente. Por favor note que alterar as opcoes de configuracao relacionadas com mapeamento de ID ira fazer com que os IDs de utilizador e grupo mudem. De momento, o SSSD nao suporta alterar os IDs, assim a base de dados do SSSD tem de ser removida. Porque as palavras passe em cache sao tambem guardadas na base de dados, remover a base de dados so deve ser feito enquanto os servidores de autenticacao estao alcancaveis, caso contrario os utilizadores podem ficar bloqueados de fora. De modo a palavra passe em cache, tem de ser executada uma autenticacao. Nao e suficiente usar sss_cache(8) para remover a base de dados, em vez disso o processo consiste de: o Certificar que os servidores remotos sao alcancaveis o Parar servico SSSD o Remover a base de dados o Arrancar o servico SSSD Mais ainda, como a mudanca de IDs pode necessitar de ajustes noutras propriedades do sistema tais como o dono de ficheiros e directorios, e recomendado planear com antecedencia e testar a configuracao do mapeamento de ID meticulosamente. Algoritmo de Mapeamento Active Directory fornece um objectSID para cada objecto utilizador e grupo no directorio. Este objectSID pode ser partido em componentes que representam a identidade de dominio 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 disponiveis e divide-a em seccoes de componente de tamanho igual - chamadas fatias ou "slices"-. Cada fatia representa o espaco disponivel para um dominio Active Directory. Quando uma entrada de utilizador ou grupo para um dominio particular e encontrada pela primeira vez, o SSSD aloca uma das fatias disponiveis para esse dominio. De modo a tornar esta atribuicao de fatia repetivel em diferentes maquinas cliente, nos selecionamos a fatia com base no seguinte algoritmo: A string SID e passada atraves do algoritmo murmurhash3 para a converter num valor cinza de 32-bit. Depois nos pegamos no modulus deste valor com o numero total de fatias disponiveis para escolher a fatia. NOTA: E possivel de se encontrar colisoes na cinza e modulus subsequentes. Nestas situacoes, iremos selecionar a proxima fatia disponivel, mas pode nao ser possivel de reproduzir o mesmo conjunto exacto de fatias em outras maquinas (pois a ordem com que sao encontradas ira determinar a sua fatia). Nesta situacao, e recomendado ou mudar para usar atributos POSIX explicitos em Active Directory (desactivando o mapeamento de ID) ou configurar um dominio predefinido para garantir que pelo menos um e sempre consistente. Veja "Configuracao" para detalhes. Configuracao Configuracao minima (na seccao "[domain/DOMAINNAME]"): ldap_id_mapping = True ldap_schema = ad A configuracao predefinida consiste em configurar 10,000 fatias, cada uma capaz de conter ate 200,000 IDs, a comecar de 200,000 e ir ate a 2,000,200,000. Isto deve ser suficiente para a maioria dos desenvolvimentos. Configuracao Avancada 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. E o primeiro ID POSIX que pode ser usado para o mapeamento. NOTA: Esta opcao e diferente de "min_id" em que "min_id" actua para filtrar o resultado de pedidos a este dominio, ao passo que esta opcao controla a gama de atribuicao de ID. Esta e uma distincao subtil, mas o bom conselho geral sera que "min_id" seja menor ou igual a "ldap_idmap_range_min" Predefinicao: 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. E o primeiro ID POSIX que nao pode mais ser usado para o mapeamento, isto e, um maior que o ultimo que pode ser usado para o mapeamento. NOTA: Esta opcao e diferente de "max_id" em que "max_id" actua para filtrar o resultado de pedidos a este dominio, ao passo que esta opcao controla a gama de atribuicao de ID. Esta e uma distincao subtil, mas o bom conselho geral sera que "max_id" seja maior ou igual a "ldap_idmap_range_max" Predefinicao: 2000200000 ldap_idmap_range_size (inteiro) Especifica o numero de IDs disponivel para cada fatia. Se o tamanho do alcance nao se dividir uniforme nos valores minimo e maximo, ira criar o maximo de fatias completas que conseguir. NOTA: O valor desta opcao tem de ser pelo menos tao grande quando o RID planeado do mais alto utilizador para usar no servidor Active Directory. As procuras e login de utilizador irao 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 e igual ao RID maximo menos o RID minimo mais um (ex. 1108 = 1107 - 0 + 1). E importante planear com antecedencia para futura expansao, 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. Predefinicao: 200000 ldap_idmap_default_domain_sid (string) Especifica o SID de dominio do dominio predefinido. Isto ira garantir que este dominio ira sempre ser atribuido a fatia zero no mapa de ID, contornando o algoritmo murmurhash descrito em cima. Predefinicao: nao definida ldap_idmap_default_domain (string) Especifica o nome do dominio predefinido. Predefinicao: nao 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 opcao esta configurada, os dominios serao alocados comecando da fatia zero e aumentando monotonicamente com cada dominio adicional. NOTA: Este algoritmo e nao-deterministico (depende da ordem em que os utilizadores e grupos sao requisitados). Se este modo for requerido para compatibilidade com maquinas que correm winbind, e recomendado que se tambem use a opcao "ldap_idmap_default_domain_sid" para garantir que pelo menos um dominio e consistentemente alocado para a fatia zero. Predefinicao: False ldap_idmap_helper_table_size (inteiro) Numero maximo de fatias secundarias que e tentado quando se executa mapeamento de id UNIX para SID. Nota: Podem ser geradas fatias secundarias adicionais quando o SID esta a ser mapeado para id de UNIX e RID parte do SID esta fora de alcance para as fatias secundarias geradas ate ao momento. Se o valor de ldap_idmap_helper_table_size for igual a 0 entao nenhuma fatia secundaria adicional sera gerada. Predefinido: 10 SIDs Well-Known SSSD suporta procurar nomes de SIDs Well-Known, isto e, SIDs com um significado especial codificado. Como os utilizadores e grupos genericos relacionados a esses SIDs Well-Known nao tem equivalente num ambiente Linux/UNIX, nenhuns IDs de POSIX estao disponiveis para esses objectos. O espaco de nome SID esta organizado em autoridades que podem ser vistas como diferentes dominios. As autoridades para os SIDs Well-Known sao o Null Authority o World Authority o Local Authority o Creator Authority o Mandatory Label Authority o Authentication Authority o NT Authority o Built-in As versoes capitalizada desses nomes sao usadas como nomes de dominio quando se retorna o nome totalmente qualificado de um SID Well-Known. Como alguns utilitarios permitem modificar informacao 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 tambem. Para evitar colisoes apenas os nomes totalmente qualificados podem ser usados para procurar SIDs Well-Known. Como resultado os nomes de dominio "NULL AUTHORITY", "WORLD AUTHORITY", "LOCAL AUTHORITY", "CREATOR AUTHORITY", "MANDATORY LABEL AUTHORITY", "AUTHENTICATION AUTHORITY", "NT AUTHORITY" e "BUILTIN" nao devem ser usados como nomes de dominio no sssd.conf. EXEMPLO O seguinte exemplo assume que o SSSD esta actualmente configurado e example.com e um dos dominios na seccao [sssd]. Este exemplo mostra apenas as opcoes especificas 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 NOTAS O provedor de controle de acesso AD verifica se a conta expirou. Tem o mesmo efeito que a seguinte configuracao 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 e "permit". Por favor note que se voce configurar um provedor de acesso diferente do "ad", voce tem de definir todos os parametros da ligacao (tal como URIs do LDAP e detalhes de encriptacao) manualmente. Quando o provedor autofs e definido para "ad", e usado o mapeamento de atributos esquema RFC2307 (nisMap, nisObject, ...), porque estes atributos estao incluidos no esquema Active Directory predefinido. VEJA TAMBEM 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/ NOTES 1. Grupos de seguranca Active Directory https://docs.microsoft.com/en-us/windows-server/identity/ad- ds/manage/understand-security-groups 2. seccao [MS-ADTS] extensoes do LDAP https://msdn.microsoft.com/en-us/library/cc223367.aspx SSSD 06/09/2026 SSSD-AD(5)