Perguntas[active-directory](server)

Bom dia pessoal,

Estou tentando criar um filtro de usuário LDAP - para uso com o aplicativo Xen Orchestra - que verificará se o usuário que está tentando fazer login é um membro do GROUPA ou GROUPB. Eles não precisam ser membros de ambos.

Já tenho um filtro que funciona para membros do GROUPA:

(&(sAMAccountName={{name}})(memberOf=CN=GROUPA,OU=Groups,OU=folder,DC=mydomain,DC=local))

Agora estou tentando expandir esse filtro para incluir membros do GROUPA ou GROUPB (assim), mas não está funcionando:

(&(sAMAccountName={{name}})(|(memberOf=CN=GROUPA,OU=Groups,OU=folder,DC=mydomain,DC=local)(memberOf=CN=GROUPB,OU=Groups,OU=folder,DC=mydomain,DC=local)))

Qualquer dica seria muito apreciada, obrigado.

Sou novo nisso e não sei mais onde pesquisar no Google sobre esse problema. Criei um ambiente de laboratório usando VMs e criei meu próprio samba-dc 4.22 autocompilado e limpo de acordo com os manuais no samba-wiki. Tudo parece estar funcionando (ou seja, DNS, gerenciamento de usuários e computadores, compartilhamentos, criação de políticas), exceto para aplicar políticas no cliente Win10 (e Win11 no futuro, Linux ainda não testado).

Eu instalei com sucesso o admx-templates de acordo com o manual no samba-wiki para UNIX e depois para Windows 10 (22H2) no diretório sysvol/Policies.

Mas embora o gpuupdate tenha sido concluído com sucesso, ele não tem efeito. Ao executar o 'Resultant Set of Policy', posso ver a captura de tela fornecida, que de acordo com o ID se refere à captura de tela da Default Domain Policy em erro/aviso

Mas quando eu verifico o sysvol-dir, a estrutura de pastas aparentemente não está completa. Portanto, a mensagem de erro dentro da captura de tela é um pouco enganosa, pois o acesso é "negado" já que as respectivas pastas e GptTmpl.inf não estão presentes para nenhuma das políticas criadas.

tree -d

├── PolicyDefinitions
│ ├── [abreviado - somente idiomas/localidades]
├── {199F4DF0-8969-4E75-861D-F9AB6C73770B}
│ ├── Máquina
│ └── Usuário
├── {31B2F340-016D-11D2-945F-00C04FB984F9}
│ ├── MÁQUINA
│ │ └── Scripts
│ └── USUÁRIO
└── {6AC1786C-016F-11D2-945F-00C04FB984F9}
├── MÁQUINA
└── USUÁRIO\

Não sei se isso tem correlação, mas toda vez que crio ou modifico um GP, o sysvolcheck me dá um erro que não consigo entender, mas o sysvolreset parece consertar isso - pelo menos de certa forma, então não estou mais recebendo erros.

samba-tool ntacl sysvolcheck -U administrator

ERRO(<class 'samba.provision.ProvisioningError'>): exceção não detectada - ProvisioningError: DB ACL no diretório GPO /usr/local/samba/var/locks/sysvol/ad-test.home/Policies/{199F4DF0-8969-4E75-861D-F9AB6C73770B} O:DAG:PAI:PAI(A;OICI;FA;;;DA)(A;OICI;FA;;;EA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;DA)( A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;AU)(A;OICI;0x1200a9;;;ED)(A;OICI;0x1200a9;;;DU) não corresponde ao valor esperado O:DAG:DAD:PAR(A;OICI;FA;;;DA)(A;OICI;FA;;;EA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;DA)(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;AU)(A;OICI;0x1200 a9;;;ED)(A;OICI;0x1200a9;;;DU)(OA;OICI;;edacfd8f-ffb3-11d1-b41d-00 a0c968f939;;AU)(OA;OICI;;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;DU) do
arquivo de objeto GPO "/usr/local/samba/lib64/python3.9/site-packages/samba/netcmd/ init .py", linha 356, em _run
return self.run(*args, **kwargs)
Arquivo "/usr/local/samba/lib64/python3.9/site-packages/samba/netcmd/ntacl.py", linha 484, em run
provision.checksysvolacl(samdb, netlogon, sysvol,
Arquivo "/usr/local/samba/lib64/python3.9/site-packages/samba/provision/ init .py", linha 1885, em checksysvolacl
check_gpos_acl(sysvol, dnsdomain, domainsid, domaindn, samdb, lp,
Arquivo "/usr/local/samba/lib64/python3.9/site-packages/samba/provision/ init .py", linha 1835, em check_gpos_acl
check_dir_acl(policy_path, dsacl2fsacl(acl, domainsid), lp,
Arquivo "/usr/local/samba/lib64/python3.9/site-packages/samba/provision/ init .py", linha 1778, em check_dir_acl
raise ProvisioningError('%s ACL no diretório GPO %s %s não corresponde ao valor esperado %s do objeto GPO' % (acl_type(direct_db_access), path, fsacl_sddl, acl))

Estou executando um projeto de migração de domínio (vários domínios de site único mesclados em um AD global) na minha empresa.

Migrei usuários, computadores e grupos (usando a ferramenta de migração on-demand Quest) e verifiquei se o histórico do SID está sendo gravado corretamente nas contas de usuário+grupo. Posso ver o atributo SIDHistory preenchido para usuários e grupos com valores corretos.

A conta do usuário que é migrada para o novo domínio tenta acessar um servidor de arquivos no domínio antigo, no log do old-domain-fileserver, vejo:

Um objeto de compartilhamento de rede foi verificado para ver se o cliente pode receber o acesso desejado.

Subject:
    Security ID:        NEWDOMAIN\admig2
    Account Name:       admig2
    Account Domain:     NEWDOMAIN
    Logon ID:       0x1B7Dxxxx

Network Information:    
    Object Type:        File
    Source Address:     10.ab.cd.ef
    Source Port:        49782
    
Share Information:
    Share Name:     \\*\SHARE
    Share Path:     \??\D:\SHARE
    Relative Target Name:   \

Access Request Information:
    Access Mask:        0x80
    Accesses:       ReadAttributes
                
Access Check Results:
    ReadAttributes: Not granted
                

Executei os seguintes comandos em domínios antigos e novos:

domínio antigo

netdom trust <old domain fqdn> /domain:<new domain FQDN> /enablesidhistory:yes
netdom trust <old domain fqdn> /domain:<new domain FQDN> /quarantine:no

novo domínio

netdom trust <new domain FQDN> /domain:<old domain fqdn> /enablesidhistory:yes
netdom trust <new domain FQDN> /domain:<old domain fqdn> /quarantine:no

Já se passaram algumas horas, então tudo deve ser replicado em todos os lugares. Ainda assim, estou recebendo o mesmo erro ao tentar acessar o compartilhamento de arquivos com a credencial do usuário migrado: acesso negado, pergunte ao seu administrador

Além de desligar o SIDfiltering e migrar grupos de usuários também, há alguma outra área que eu preciso verificar e que esqueci no meu post acima? Obrigado.

Resultado de um dos testes: Acredito que descartei o culpado NTLM - não é ele. Quando compartilho uma nova pasta para R/W para todos e na ACL de segurança, dou permissão ao OLDDOMAIN\admig2 para esse novo compartilhamento, o NEWDOMAIN\admig2 pode acessar esse compartilhamento. Ele ainda é o servidor de arquivos unido ao OLDDOMAIN. Estou confuso com esses sintomas. Sim, OLDDOMAIN\Domain users é um grupo local de domínio e NEWDOMAIN\admig2 não é membro dele, mas é aqui que o SidHistory deve entrar em ação e, devido ao antigo SID ser membro do OLDDOMAIN\Domain Users, acredito que isso ainda deve funcionar, mas não funciona. Ou...?

Continuarei com os testes amanhã.

Peço desculpas se esta pergunta fugir do assunto; estou tentando solucionar algo que foge da minha área de especialização.

Recentemente, migrei um aplicativo da web interno para o IIS. Também habilitei a Autenticação do Windows (IWA), que eu não estava usando antes. O problema que estou vendo é que minha conta de usuário (e, evidentemente, apenas minha conta de usuário) às vezes (não em todos os lugares) é identificada incorretamente pelo processo de autenticação.

Aqui estão os detalhes da configuração de autenticação do IIS para meu site:

• Tenho a Autenticação do Windows habilitada e todo o resto (incluindo a Autenticação Anônima) desabilitado.
• A autenticação do Windows está usando a autenticação no modo Kernel e o Negotiateprovedor.

Em relação à identificação errônea a que aludi:

• Tenho duas contas de usuário no mesmo domínio do AD. Chamo-as ​​de acct1e acct2. Normalmente, entro como acct1, alternando para acct2quando preciso de privilégios elevados.
• Fiz login na VM que está executando o IIS acct2para configurar o site.
• Quando volto ao meu PC local para acessar o site, o site me identifica como acct2, mesmo que eu esteja conectado ao meu PC como acct1.
• Todos os outros que acessaram o site foram devidamente identificados, mesmo aqueles que têm mais de uma conta, como eu.
• Se eu acessar o site de um PC diferente enquanto estiver conectado como acct1, serei identificado corretamente pelo site como acct1.
• Perversamente, se eu acessar o site da própria máquina do servidor, onde estou logado como acct2, ele me identifica como acct1.
• Pelo que vale, acct2ele tem privilégios de administrador no meu PC local, mas não no outro PC de onde acessei o site.
• Isso vem acontecendo há mais de uma semana e persiste mesmo depois de reiniciar meu PC local. Também acontece em diferentes navegadores.

Se eu mudar o provedor IWA de Negotiatepara NTLM, aqui está o que vejo:

• Sou devidamente identificado acct1quando acesso o site do meu PC local.
• Sou solicitado a inserir credenciais quando acesso o site da máquina do servidor web. No entanto, ele não aceita credenciais para acct1ou acct2.

Não estou muito preocupado em acessar o site do servidor, mas preciso ser identificado corretamente ao acessá-lo do meu PC. Gostaria de usar Negotiateem vez de NTLM.

Sou um desenvolvedor e não um administrador de sistema, mas estou tentando encontrar pistas que possam me ajudar a restringir o que está acontecendo e potencialmente apontar nossa equipe de infraestrutura na direção certa. Isso parece um problema de configuração do Active Directory ou do Kerberos?

O site é um aplicativo Python Flask rodando como um aplicativo FastCGI no IIS por meio da wfastcgibiblioteca Python. O site lê o valor da REMOTE_USERvariável request para obter o resultado do processo de autenticação IWA.

Nosso controlador de domínio travou e não temos como recuperá-lo. Nossos computadores foram autenticados e conectados ao nosso antigo controlador de domínio, e os perfis de roaming foram desabilitados. Nossos usuários salvam arquivos localmente em c:\users\mylocaluser\ e usam o controlador de domínio para autenticação na rede.

Agora, precisamos recuperar os arquivos de um usuário local, mas quando autenticamos em nosso novo controlador de domínio, os arquivos antigos desaparecem.

Tentamos instalar o disco rígido em outro PC, mas os arquivos parecem ter sumido.

Pesquisei e descobri que talvez os arquivos estejam em c:\windows\csc, mas não podemos ter acesso a essa pasta. Então estamos presos.

Você já passou por um problema semelhante?

Tenho uma rede com servidor Active Directory Windows Server 2003 e computadores Windows 11. Meu plano é substituir o Windows Server 2003 pelo Fedora Linux Server Edition - fedora 40. Eu poderia testá-lo com clientes Windows 11 e um cliente Fedora Linux 40.

O antigo reino é SONCANALS. O novo reino é SCNG.

Eu segui o guia da Revista Fedora .

Configurações

• O IP do servidor é 10.216.1.16e o domínio éscng.educaib

• O nome do host do servidor él1.scng.educaib

• samba.conf:

  cat /etc/samba/smb.conf
  # Global parameters
  [global]
          dns forwarder = 1.1.1.1
          netbios name = L1
          realm = SCNG.EDUCAIB
          server role = active directory domain controller
          workgroup = SCNG
          idmap_ldb:use rfc2307 = yes
          ldap server require strong auth = no 
  
  [sysvol]
          path = /var/lib/samba/sysvol
          read only = No
  
  [netlogon]
          path = /var/lib/samba/sysvol/scng/scripts
          read only = No
  

• Configuração do Kerberos:

  # cat /etc/krb5.conf.d/samba-dc 
  [libdefaults]
          default_realm = SCNG.EDUCAIB
          dns_lookup_realm = false
          dns_lookup_kdc = true
  
  [realms]
  SCNG.EDUCAIB = {
          default_domain = SCNG
  }
  
  [domain_realm]
          l1.scng.educaib = SCNG.EDUCAIB
  

• /etc/systemd/resolved.conf.d/custom.conf:

  [Resolve]
  DNSStubListener=no
  Domains=scng.educaib
  DNS=10.216.1.16
  

Tenho uma máquina com Fedora 40 que uso para testar o samba. Quando testo, tudo fica bem (seção "Testing" no guia do tutorial). Quando executo realm discover, só obtenho o realm antigo, não o novo:

realm discover -v
 * Resolving: _ldap._tcp.soncanals
 * Performing LDAP DSE lookup on: 10.216.1.2
 * Performing LDAP DSE lookup on: 10.216.1.10
 * Performing LDAP DSE lookup on: 10.216.1.4
 * Successfully discovered: soncanals
soncanals
  type: kerberos
  realm-name: SONCANALS
  domain-name: soncanals
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: sssd-common
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd-ad
  required-package: adcli
  required-package: samba-common-tools

No Windows, quando tento entrar SCNG, sou solicitado a fazer logon de administrador, mas quando coloco credenciais, demora muito e sai uma caixa de diálogo.

Como posso fazer a triagem do problema aqui? Por exemplo, quais logs posso ver (tenho muitos em /var/log/samba/). Minha versão do samba é 4.20.5.

Minha prioridade é ingressar em um novo domínio e fazer login no Windows como usuário regular neste domínio. Descarto, por enquanto, compartilhar diretórios.

Editar (2024-11-11): Os testes no guia da revista Fedora foram aprovados corretamente:

Testando

Teste de conectividade

$ smbclient -L localhost -N
Anonymous login successful

        Sharename       Type      Comment
        ---------       ----      -------
        sysvol          Disk      
        netlogon        Disk      
        IPC$            IPC       IPC Service (Samba 4.21.1)
SMB1 disabled -- no workgroup available

$ smbclient //localhost/netlogon -UAdministrator -c 'ls'
Password for [SCNG\Administrator]:
  .                                   D        0  Thu Oct 31 10:17:05 2024
  ..                                  D        0  Thu Oct 31 10:17:05 2024

                15663104 blocks of size 1024. 12979380 blocks available

Teste DNS

$ host -t SRV _ldap._tcp.scng.educaib.
_ldap._tcp.scng.educaib has SRV record 0 100 389 l1.scng.educaib.
$ host -t SRV _kerberos._udp.scng.educaib.
_kerberos._udp.scng.educaib has SRV record 0 100 88 l1.scng.educaib.
$ host -t A l1.scng.educaib.
l1.scng.educaib has address 10.216.1.16

Teste Kerberos

$  kinit administrator
Password for [email protected]: 
ladmin@l1:~$ klist
Ticket cache: KCM:1000
Default principal: [email protected]

Valid starting     Expires            Service principal
11/11/24 10:15:10  11/11/24 20:15:10  krbtgt/[email protected]
        renew until 18/11/24 10:15:06

Temos uma conta de usuário antiga do AD com uma senha estática que é usada em várias máquinas para uma tarefa agendada e um serviço. Sei que o gMSA é melhor e, separadamente, estou no processo de colocá-lo em prática, mas essa conta precisa ficar ativa por mais um tempo.

Voltando a esta conta: Quero alterar a senha para atender aos critérios atuais de força de senha e garantir o hash AES, mas não tenho certeza se preciso alterá-la duas vezes com uma pausa de 10 horas entre elas ou se posso alterá-la consecutivamente e enviar a atualização da senha para os endpoints afetados.

Se alguém puder esclarecer o método de redefinição de intervalo de 2x e 10 horas ou se é possível fazer isso consecutivamente para essa finalidade, eu ficaria grato.

Obrigado!

Para habilitar o LDAPS, preciso de certificados em ambos os controladores de domínio. Não posso usar o Certificate Services, pois não tenho uma máquina Windows sobressalente e instalar essa função em um DC é um grande não-não, então prefiro usar um certificado autoassinado com SANs cobrindo ambos os DCs (FQDN e nomes curtos de máquina).

Algo que eu deva prestar atenção? Por exemplo:

• o certificado deve ter uma duração máxima (ou seja: 1, 5, 10, 100 anos)?
• isso pode interromper/afetar a conexão com a máquina cliente (improvável, pois o DC não tem certificado no momento);
• EFS - não ter uma CA significa que os próprios clientes são responsáveis ​​por suas chaves. O que acontecerá com o certificado autoassinado?

Estou configurando contas de usuário para dispositivos MAB (Mac Authentication Bypass) na minha rede. No GPO, criei uma UO para que as contas do dispositivo sejam criadas com herança de bloco para que a política de senha não seja aplicada às contas do dispositivo. A política de senha se aplica ao Controlador de Domínio. Quando vou criar a conta para o dispositivo, o nome de usuário/senha deve ser o endereço mac do dispositivo. O problema é que mesmo com a herança de bloco definida na UO, quando consigo criar a conta de usuário nessa UO, ela ainda aplica a política de senha. Sem desativar a política com a política de senha, há uma maneira de criar a conta de usuário para o dispositivo MAB?

Estou configurando um GPO OU para firewall e outras configurações para recomendações do CIS SCA. Eu tive um problema com as configurações do firewall. Os PCs na OU estão recebendo todas as configurações de GPO exatamente como você esperaria, e tudo está funcionando bem; No entanto, após um período de tempo desconhecido, algumas horas ou no dia seguinte, no controlador de domínio, as configurações de GPO da OU para "Windows Defender Firewall com configurações avançadas de segurança" estão de volta aos padrões, como se eu não tivesse alterado nada - todas as outras configurações de GPO estão definidas como eu tinha e permanecem.

Então, o problema está no controlador de domínio, não no cliente incluído na UO.

Configuração do computador\Políticas\Configurações do Windows\Configurações de segurança\Firewall do Windows Defender com Segurança Avançada

Configurações: Estado:

• Ativando todos os 3 (Domínio, Privado, Firewall Público)
• Bloquear entrada (padrão)
• Permitir saída (padrão)

Configurações:

• Exibir notificação = Não
• Mesclagem de regras: aplicar regras de firewall local = Não
• Aplicar regras de segurança de conexão local = Não

Registro

• %SystemRoot%\System32\logfiles\firewall\domainfw.log (privatefw.log e publicfw.log respectivamente)
• Limite de tamanho 16.384
• Log de pacotes descartados = Sim
• Registrar conexões bem-sucedidas

Observação* O firewall está gravando com sucesso em todos os 3 arquivos.

• Windows Server 2019, os PCs são Dell Wyse ThinClients Windows 10 Enterprise LTSC
• NÃO há outros GPOs, exceto Domínio Padrão e Controladores de Domínio Padrão...

Estou travado. Alguém já viu isso antes ou tem sugestões?

Obrigado pelo seu tempo,