Appleoddity's questions

# Build a list of Adtran AP mac addresses found on directly connected switch ports
- name: PARSE AND FILTER MAC ADDRESS-TABLE
  ansible.builtin.set_fact:
    macs: "{{ macs + [item] }}"
  loop: "{{ macs_raw.stdout[0] | ansible.netcommon.parse_cli_textfsm('templates/cisco_ios_show_mac-address-table.textfsm') }}"
  when:
    - item.DESTINATION_PORT[0] not in neighbors.keys()   # Ignore macs found on neighboring switches
    - item.DESTINATION_ADDRESS is search('^0019\.92.*$')   # Ignore macs that aren't Adtran APs

Recebo o seguinte aviso de descontinuação:

[DEPRECATION WARNING]: Use 'ansible.utils.hwaddr' module instead. This feature will be removed from ansible.netcommon in a release after 2024-01-01. Deprecation warnings can be disabled by
 setting deprecation_warnings=False in ansible.cfg.

ansible --version

ansible [core 2.16.6]
  config file = /workspaces/git/my-repo/ansible/ansible.cfg
  configured module search path = ['/home/vscode/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/local/python/3.11.6/lib/python3.11/site-packages/ansible
  ansible collection location = /home/vscode/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/local/python/current/bin/ansible
  python version = 3.11.6 (main, Dec 19 2023, 21:21:06) [GCC 11.4.0] (/usr/local/python/3.11.6/bin/python)
  jinja version = 3.1.4
  libyaml = True

Por que?

Para fazer com que um computador atualize suas associações de grupo sem reinicializá-lo, você pode limpar tickets Kerberos com o comando klist -li 0x3e7 purge. Um gpupdateou subsequente gpresultrefletirá as novas associações ao grupo.

No entanto, isso parece não funcionar em um controlador de domínio. Por que?

Os tickets foram eliminados com sucesso, mas os subsequentes gpresult /rnão refletem as alterações.

Eu tenho a configuração abaixo, simplificada:

Essencialmente, tenho um host ESXi com dois adaptadores de rede físicos. Cada adaptador se conecta a um switch diferente. Cada switch é conectado através de uma porta de tronco. Um PC está conectado a um dos switches. Um vSwitch com uma porta VMKernel e portas VM é configurado para usar ambas as NICs físicas em uma configuração ativa/ativa:

Eu esxtopexecutei e posso ver que o host ESXi escolheu a NIC física conectada ao Switch 2 para a porta VMKernel. No PC, se eu fizer ping no endereço IP de gerenciamento do host ESXi, os pings serão intermitentes. Eles sobem e descem.

Se eu mostrar a tabela de endereços mac em cada switch, vejo que o Switch 2 sempre tem o endereço MAC do VMKernel atribuído à porta do switch conectada ao host ESXi. Mas, o Switch 1 adiciona e remove continuamente o endereço MAC do VMKernel em sua respectiva porta física. Sempre que o Switch 1 tem o MAC do VMKernel atribuído à sua porta física, os pings falham.

A razão do fracasso é óbvia. A razão pela qual o Switch 1 está coletando rotineiramente o endereço MAC da porta ESXi VMKernel é a questão. O host ESXi escolheu a interface conectada ao Switch 2 para ser a porta ativa. A interface conectada ao Switch 1 deve estar inativa. Mas, parece que possivelmente está respondendo a solicitações ARP?

Vale a pena notar que nenhuma das VMs neste host tem esse problema. Eles são todos alcançáveis ​​e estão presentes em apenas uma tabela MAC por vez. Esse problema afeta especificamente a porta VMKernel.

O que esta configuração está errada? Estou procurando algum tipo de documentação ou explicação em cima de uma solução para esse problema. Eu sei que configurar a porta VMKernel para o modo Ativo/Standby provavelmente resolverá o problema. Mas não consigo encontrar nada documentado por que essa configuração atual é um problema.

ATUALIZAÇÕES:

• Desativei o CDP no vSwitch pensando que poderia estar causando comunicação pela NIC inativa.
• Eu substituí as configurações do vSwitch para a porta VMKernel e a configurei para usar failover explícito e Ativo/Standby. Também coloquei a NIC em espera no pool não utilizado. Nada disso ajudou. O que resolveu o problema foi alterar a ordem das portas. Portanto, quando a porta conectada ao Switch 1 fica ativa, não vejo o problema. O endereço MAC não se torna ativo no Switch 2. Estas são duas placas NIC significativamente diferentes, e eu estou querendo saber se isso não é algum tipo de problema de driver.

Algo deve estar fazendo com que o endereço MAC do VMKernel seja visto na porta do Switch 1, mas ele vem e vai a cada vários segundos.

Configurações de switch para STP e portas: Switch 1

!
spanning-tree mode rapid-pvst
spanning-tree portfast edge default
spanning-tree extend system-id
!
interface Port-channel1
 switchport access vlan 11
 switchport trunk encapsulation dot1q
 switchport mode trunk
!
interface GigabitEthernet1/0/7
 switchport access vlan 11
 switchport mode access
!
interface GigabitEthernet1/0/23
 switchport access vlan 11
 switchport trunk encapsulation dot1q
 switchport mode trunk
 channel-group 1 mode desirable
!
interface GigabitEthernet1/0/24
 switchport access vlan 11
 switchport trunk encapsulation dot1q
 switchport mode trunk
 channel-group 1 mode desirable

Interruptor 2

!
spanning-tree mode rapid-pvst
spanning-tree portfast edge default
spanning-tree extend system-id
!
interface Port-channel1
 switchport access vlan 11
 switchport trunk encapsulation dot1q
 switchport mode trunk
!
interface GigabitEthernet1/0/3
 switchport access vlan 11
 switchport mode access
!
interface GigabitEthernet1/0/23
 switchport access vlan 11
 switchport trunk encapsulation dot1q
 switchport mode trunk
 channel-group 1 mode desirable
!
interface GigabitEthernet1/0/24
 switchport access vlan 11
 switchport trunk encapsulation dot1q
 switchport mode trunk
 channel-group 1 mode desirable

Estamos utilizando servidores DNS do Windows 2016+. Contamos com LocalNetPriority em nossos servidores DNS. Temos vários servidores DNS do Active Directory em vários sites. O comportamento esperado é que quando uma consulta específica é feita ao servidor DNS, ela retornará um endereço IP que está na mesma sub-rede que a consulta originada, se existirem vários registros A para o mesmo host. Isso funciona bem na maioria dos casos.

No entanto, para solicitações originadas do próprio servidor DNS, ele não funciona. Primeiro, o servidor DNS (ou Active Directory), por padrão, configura sua interface de rede para usar a si mesmo como o servidor DNS de sua escolha via localhost (127.0.0.1 e ::1). Isso faz com que a seleção LocalNetPriority falhe, pois o endereço IP de origem não está em uma de nossas sub-redes.

Em segundo lugar, o servidor está preferindo IPv6 em vez de IPv4. Não usamos IPv6, mas também não queremos desativá-lo, pois claramente causou problemas no passado em diferentes cenários, e a Microsoft afirma que é obrigatório e não oferece suporte ou recomenda desativá-lo. Usar IPv6 está fora de questão.

Finalmente, isso deve funcionar quando houver interrupções na rede. Esse requisito específico exige que o localnetpriority funcione corretamente quando a localização do satélite for separada do restante da rede. Portanto, o uso de resolvedores de DNS de mesmo nível como servidor principal não atende a esse requisito sozinho.

Parece que configurar o IPv4 para ser a prioridade sobre o IPv6 e configurar o endereço IP real do servidor como o servidor DNS de escolha pode ser a única solução. No entanto, aprendi há muito tempo que usar 127.0.0.1 é a melhor escolha porque durante uma reinicialização ou se um cabo de rede for desconectado, o diretório ativo pode desmoronar completamente.

o que estou perdendo? Existe uma maneira mais direta de resolver esse problema? Talvez eu deva apenas adicionar uma entrada de arquivo HOSTS para o host específico com o qual estamos tendo problemas.

Estou seguindo as instruções para NXLog aqui: https://nxlog.co/documentation/nxlog-user-guide/linux-logs.html#linux_logs_forwarding_socket_example em 80.2 sobre o encaminhamento de mensagens syslog para NXLog.

Ele indica especificamente para reiniciar o NXLog e, em seguida, o rsyslog para que o NXlog possa criar o soquete antes que o rsyslog tente gravar nele.

Minha pergunta é que, durante uma reinicialização e em diferentes versões do Linux, é ambíguo qual serviço será iniciado primeiro, e meu palpite é que o syslog pode ser iniciado primeiro. O que acontecerá se o rsyslog iniciar antes do nxlog? O rsyslog recuperará e começará a gravar no soquete após o nxlog iniciar e criá-lo?

EDIT: Acho que vem de HKEY_USERS\.DEFAULT\Printers\ConvertUserDevModesCount. Eu vejo todas as conexões de impressora originais e novas listadas aqui, bem como uma tonelada de \\CSR|<ServerName>\{<long GUID>}entradas repetidas. Encontrei este artigo de uma forma redonda o que me levou a procurar nesta área.

Eu tenho um conjunto de impressoras que implantam em computadores via GPO. Hoje, tentei mudar esse mapeamento de impressora. Os novos mapeamentos de impressora aparecem na estação de trabalho, mas os antigos ainda estão sendo exibidos.

No entanto, antes do login, o perfil do usuário não existe no computador. Nada em C:\Users, nada em Advanced System Settings. Sim, eu tenho um monte de computadores para testar. Mesmo se eu remover o GPO que implanta as impressoras, as impressoras originais continuam aparecendo na janela "Dispositivos e Impressoras".

Se eu excluir o usuário do AD e adicionar novamente um novo usuário com o mesmo nome de usuário e senha, as impressoras originais/antigas não serão mais exibidas.

Além disso, se eu usar powershells get-printerou wmic printer list briefessas impressoras originais/antigas NÃO aparecerão. Eles também NÃO aparecem no registro, HKCU\Printers\Connectionsmas TODOS os mapeamentos de impressora apropriados/novos aparecem. No entanto, essas conexões antigas continuam sendo exibidas na janela 'Dispositivos e Impressoras'. E, eles continuam a funcionar corretamente.

Esses são computadores híbridos ingressados ​​no Azure AD. Mas não temos AD premium e não há roaming de estado corporativo configurado. Não estamos usando perfis de roaming. Não estamos redirecionando pastas para nenhum compartilhamento de rede. Nenhuma outra configuração parece estar em roaming ou aparecer. Os arquivos salvos sumiram. Isso parece afetar todos ou vários usuários nas mesmas máquinas, incluindo um usuário 'convidado' cujo perfil é 'temporário' e excluído em cada logoff.

COMO essas impressoras continuam a aparecer em computadores nos quais o usuário não possui um perfil e nenhum GPO ou script está sendo implantado. Por que eles aparecem apenas em 'Dispositivos e Impressoras', mas não em wmic, powershell ou registro? O usuário fez logon neste computador e em outros no passado em nossa organização.

Usando as preferências de política de grupo no escopo do usuário, estamos criando uma pasta pessoal para novos usuários no servidor. Esta pasta base herda as permissões "CREATOR OWNER" do compartilhamento inicial raiz. Agora, queremos criar uma segunda pasta na pasta Home chamada Scans. Mas, queremos alterar as permissões dessa pasta para que o usuário tenha controle total sobre as subpastas e arquivos - não queremos apenas herdar as permissões de "PROPRIETÁRIO CRIADOR". O problema é que o scanner coloca arquivos nessa pasta e se torna o proprietário do arquivo, fazendo com que o usuário perca o acesso a ele.

Estou curioso para saber quais idéias estão por aí sobre como fazer isso?

Acho que sei quais opções tenho, e nenhuma delas é a ideal. Em primeiro lugar, não estou ciente de um item de preferência de política de grupo para usuários que podem definir permissões de arquivo/pasta - todos eles têm escopo de computador, o que não funciona neste caso. Além disso, a ordem de execução do script de login vem antes dos itens da pasta de preferência de política de grupo que exigiriam pelo menos 2 GPOs para contornar e eu odeio scripts de login nos dias de hoje.

Portanto, o objetivo seria NÃO usar scripts de login, usar um único item de GPO e tê-lo totalmente configurado durante o primeiro logon (sem ter que fazer logon duas vezes ou aguardar a atualização do gp, etc.)

Por enquanto, a única solução que posso encontrar usaria um único GPO com um script de logon para definir permissões no nível do usuário. Então, em última análise, parece que a melhor maneira é apenas criar um script de login que cria a pasta inicial, cria a pasta de varreduras e define as permissões. Mas isso é TÃO feio e também é uma dor porque nossos GPOs estão usando o direcionamento de nível de item por vários motivos diferentes e os scripts de login não suportam o direcionamento de nível de item.

Eu sei que este provavelmente não é o melhor lugar para fazer essa pergunta. Mas, depois de dias trabalhando nisso e postando no Fórum da Microsoft , estou sem juízo.

Estamos utilizando uma configuração híbrida do ADFS 4.0 (Server 2016) / Azure AD / Office 365 com registro de dispositivo e SSO funcionando.

Estamos tentando habilitar a autenticação multifator com políticas de acesso baseadas em dispositivos. Não queremos que dispositivos "reconhecidos" vejam prompts de MFA adicionais. Estamos avaliando as declarações devolvidas pelo ADFS usando o Microsoft Claims Xray .

Habilitamos o MFA com êxito e configuramos o ADFS para solicitar apenas o MFA se um dispositivo não for reconhecido. Isso funciona porque os dispositivos que são reconhecidos têm propriedades adicionais no diretório ativo (isRegisteredUser; isManaged; isKnown; trustType; etc) e podemos agir nessas propriedades. Testamos com IE, Firefox, Chrome e Safari em um iPad. No entanto, as declarações "DeviceContext" só aparecem quando a autenticação é feita no IE ou Safari no iPad.

Por algum motivo, parece que nenhuma autenticação do dispositivo ocorre quando a solicitação é feita no Chrome ou no Firefox. A autenticação funciona, apenas não podemos ver nenhuma das declarações devicecontext que nos permitem tomar uma decisão com base se o dispositivo está registrado ou não. Portanto, esses navegadores recebem um prompt de MFA adicional.

Simplesmente não consigo encontrar nenhuma postagem on-line que corresponda exatamente ao meu problema. Existem alguns tópicos semelhantes, mas acabam sendo problemas diferentes ou acabam em um beco sem saída. Espero que alguém tenha essa configuração semelhante e saiba por que o Chrome e o Firefox não executariam a autenticação baseada em dispositivo adicional, mas o safari em um iPad sim. Todos os dispositivos possuem certificados válidos para realizar a autenticação.

Não recebo nenhum erro para continuar em nenhum log de eventos. O navegador simplesmente não faz uma solicitação de autenticação de dispositivo e nenhuma declaração de contexto de dispositivo é emitida. É possível que isso não seja suportado, mas não consigo encontrar nenhuma informação indicando uma forma ou outra.

Vários meses atrás, experimentei importar arquivos PST do Outlook usando a ferramenta AZCopy e o Azure Storage Explorer. Criei uma URL SAS no centro de administração do Office 365 que já expirou.

Instruções vistas aqui: https://support.office.com/en-us/article/Use-network-upload-to-import-your-organization-s-PST-files-to-Office-365-103f940c-0468- 4e1a-b527-cc8ad13a5ea6#step4

Agora voltei a fazer uma importação de produção de arquivos PST em toda a organização e passei pelo processo novamente. Criei uma nova URL SAS e, depois de carregar alguns dados de teste com o AZCopy, estou tentando adicionar o ponto de extremidade de armazenamento ao Gerenciador de Armazenamento do Azure.

Infelizmente, continuo recebendo esta mensagem de erro quando tento adicionar o novo SAS URI: Já existe uma conexão de serviço com o rótulo 'ingestãodata'.

Todos os URIs de SAS de importação criados no centro de administração do Office 365 usam "inestiondata" como o rótulo do recurso. Então, meu novo SAS URI tem o mesmo rótulo que o antigo. Eu suspeito fortemente que o Storage Explorer esteja lembrando do antigo. No entanto, como acontece com muitos dos produtos incompletos que a Microsoft está enviando na história recente, não há uma única opção em qualquer lugar no Gerenciador de Armazenamento do Azure para REMOVER pontos de extremidade SAS antigos.

Desinstalar e reinstalar o Gerenciador de Armazenamento do Azure não resolve o problema.