john zuh's questions

Como parte de garantir uma comunicação segura em nossa empresa, estamos tentando exportar o certificado SMIME emitido pela Digicert para nossos clientes, mas encontramos alguns problemas com relação a chaves privadas não incluídas ou exportáveis ​​durante o processo de exportação por meio do console certmgr.

Abaixo está uma breve descrição do erro e as várias tentativas de solução de problemas.

Durante a exportação, notei que a opção para selecionar Troca de informações pessoais - PKCS #12 (.PFX) estava esmaecida no assistente de exportação de certificados, conforme visto na captura de tela abaixo Assistente de exportação de certificados

Tentei solucionar o problema inspecionando primeiro se há uma chave privada correspondente presente para o certificado importado, mas, conforme visto na captura de tela abaixo, não havia nenhuma disponível. Certificado em Certmgr

Fui além para tentar um trabalho de reparo no armazenamento de certificados executando o comando certutil -repairstore my "serial" para corrigir o pedido caso o certificado estivesse corrompido, mas recebi o erro abaixo do erro certutil repairstore

Conforme recomendado neste artigo da Digicert https://knowledge.digicert.com/solution/SO1335.html , tentei verificar as permissões abrindo cada arquivo no caminho do contêiner de chave C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys com o bloco de notas nas pastas que corresponde aos respectivos contêineres de chave. O acesso foi negado, como você pode ver na mensagem na captura de tela abaixo da permissão Machinekeys

Eu verifiquei as permissões na pasta C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys e obtive os seguintes resultados abaixo icacls na pasta Machinekeys Interessante o suficiente, as permissões na pasta estão em conformidade com a permissão padrão necessária recomendada pela Microsoft conforme documentado aqui https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/default-permissions-machinekeys-folders

Neste ponto, estou um pouco inseguro sobre quais ações tomar. Seria possível que o certificado tenha sido importado sem uma chave de acompanhamento? Acredito que não, pois exportar o mesmo certificado depois de copiá-lo para outro cliente produziu os resultados esperados. É concebível que o certificado tenha sido corrompido ou que o acesso continue a ser negado às subpastas dentro dos contêineres de chave? Curiosamente, esse cenário parece ser bastante esporádico, pois funciona corretamente em determinados clientes em locais distintos. Pode ser plausível que o grupo funcional sejam usuários ou clientes específicos pertencentes a um determinado grupo que possua as permissões necessárias localmente no cliente, na rede ou no domínio? Eu apreciaria qualquer dica ou sugestão.

Nossa organização está definindo o Ecosia como o provedor de pesquisa padrão para todos os navegadores e gostaríamos de conseguir isso usando o modelo GPO por meio do seu link aqui https://ecosia.zendesk.com/hc/en-us/articles/ 214140705-The-Ecosia-Group-Policy-Modelo-para-Chrome . Quando baixei e extraí o modelo, recebi um erro dizendo

"O namespace 'Google.Policies.Chrome' já está definido como o namespace de destino para outro arquivo na loja."

Eu até entrei no arquivo de modelo chrome.admx para modificar esta linha para evitar conflitos

    <policyNamespaces>
    <target namespace="Google.Policies.Chrome" prefix="chrome"/>
    <using namespace="Google.Policies" prefix="Google"/>
    <using namespace="Microsoft.Policies.Windows" prefix="windows"/>
  </policyNamespaces>

como percebi que o arquivo de modelo ChromSearchProdviderEcosia.admx também tem esse namespace definido, renomeei o namespace para outra coisa e tentei novamente após vários erros, mas não funcionou.

<policyNamespaces>
    <target namespace="Google.Policies.Chrome" prefix="chrome"/>
    <using namespace="Microsoft.Policies.Windows" prefix="windows"/>
  </policyNamespaces>

Estou suspeitando de um namespace conflitante, pois já baixei alguns modelos de política do Google Chrome no mesmo local -> loja ADMX/ADM. Existe uma maneira de substituir essa parte do modelo para evitar esse conflito? Ou uma possibilidade de redefinir o espaço de nomes para não gerar um conflito depois de perceber que o do google já existe?

Não consegui adicionar o modelo Ecosia para armazenar devido a esse erro. Já entrei em contato com o Suporte da Ecosia, mas algumas sugestões gerais serão bem-vindas.

Usei a Política de Grupo para desabilitar o botão Responder a Todos no Outlook 2010 e no Outlook 2016. Fiz isso usando a configuração nos modelos ADM/ADMX para as respectivas versões do Office para desabilitar uma ID da barra de comandos.

Quando uso os modelos de administração do Office 2016 e desabilito o ID da barra de comandos 355 (Responder a todos), ele desativa o botão conforme o esperado; no entanto, os mesmos modelos de administração que deveriam ser compatíveis com 2010 com base na documentação não funcionam conforme o esperado. O botão (Responder a todos) ainda estava ativo após a configuração para desativar.

Em seguida, verifiquei a versão do Outlook 2010 e percebi que eram principalmente versões de 32 bits, pode ser esse o motivo, existe uma abordagem diferente para desabilitar esses botões.

Decidi então tentar desabilitar via Reg path porque alguém teve sucesso com essa abordagem e a recomendou Computer\HKEY_CURRENT_USER\Software\Policies\Microsoft\office\14.0\outlook\disabledcmdbaritemscheckboxes

Nome: TCID1, Tipo: REG_SZ, Valor: 355

Essa chave não existia nos clientes afetados após uma verificação completa. Adicioná-lo também não desativou o botão de resposta.

Alguém teve sucesso ao desabilitar um ID de barra de comando para o Outlook 2010 e especificamente versões de 32 bits? Em caso afirmativo, como você fez isso?

Estou me deparando com uma situação em que o aplicativo padrão para abrir PDFs foi alterado para PDF-Xchange em vez de Adobe e Mail para Outlook 2010, 2016 em vez do aplicativo Microsoft Mail padrão integrado. Essas alterações foram feitas depois de recuperar os hashes válidos para ambos os aplicativos por meio de consultas de registro e, em seguida, referenciar as respectivas entradas no arquivo de especificações App-assoc.xml. Isso funcionou em todos os computadores de destino, com exceção de um que ainda redefine o pdf para o adobe acrobat sempre que os usuários fazem logon novamente. Isso significa que ele sempre deve definir manualmente seus aplicativos padrão de pdf e mailto preferidos, o que o torna muito complicado, pois ele sempre redefine para o aplicativo padrão preferido após cada logon.

Alguém já passou por isso e gostaria de compartilhar algumas possíveis dicas de solução de problemas? Li em algum lugar que poderia ser um aplicativo desonesto nos bastidores, forçando esse comportamento.

Alguém experimentou problemas do Microsoft Sync Center após a mudança de um NAS para um NAS baseado em EMC isilon (no processo de alteração do nome do servidor e endereço IP), resultando no impacto nos compartilhamentos de rede Nome do caminho UNC? Temos alguns usuários que ainda têm seu caminho de unidade inicial referenciando o caminho antigo, ou seja, ( \\server\oldshareem vez de \\server\newshareainda serem referenciados). Garantimos que o antigo UNC para o novo UNC foi definido corretamente e efetuado via GPO para redirecionamento de pasta. Esta política foi aplicada completamente em clientes e testada após várias atualizações e reinicializações.

Excluir manualmente as referências antigas no cliente pelo suporte de TI ainda resulta em conflitos e, eventualmente, reverte depois de um tempo para referenciar o caminho antigo. Nossa conclusão foi que isso não funciona corretamente no Windows 10.

O cliente não tem controle sobre isso, pois a opção também foi desabilitada devido a uma restrição de política global que torna impossível efetuar essa alteração no lado do cliente. Existe alguma maneira de resolver isso por meio da política de grupo por meio de uma configuração de atualização de registro global? Precisamos reiniciar o cache offline em clientes ou via GPO? Também notei que isso afetou a maioria dos clientes migrando do Windows 7 -> 10, a maioria dos clientes trabalhando offline ou remotamente via WiFi/VPN fora da rede corporativa ou não estão online há vários dias devido a viagens de negócios.

Também aderimos a todas as práticas recomendadas aqui .

Estou pensando em cenários possíveis por meio de políticas globais - atualização de registro de caminhos de cache offline de 7 -> 10 via GPO ou manualmente por meio de clientes?

Acione o processo de cache de sincronização offline manual uma etapa antes ou durante o processo de migração para que os arquivos estejam onde deveriam estar quando a migração for concluída.

Também encontramos um script aqui que pode acionar esse cache manualmente, mas exigirá um privilégio de sistema que o usuário não possui e queremos evitar que o usuário faça isso. Provavelmente podemos incluir isso em nosso processo de migração.

As informações deste artigo são relevantes?

Estamos no processo de integração de um MDM de terceiros (no local) com piloto automático no portal AAD para habilitar o Windows 10 OOBE. Queremos conseguir isso aproveitando um servidor de aplicativos corporativos centrais no local no Azure. Até agora, configuramos o seguinte, que não está funcionando conforme o esperado. Também não é possível encontrar nenhum log de evento relevante em "User Device Registration" ou "DeviceManagement-Enterprise-Diagnostics-Provider":

1. O perfil do dispositivo do piloto automático foi criado importando o ID para o piloto automático.
2. Grupo de segurança com usuários autorizados incl. Autenticação habilitada para MFA
3. Os URIs de redirecionamento também foram configurados no aplicativo MDM usado pelo Azure AD para ingressar no aplicativo Web por meio do client_id correspondente, que mapeia um dos DRS do Azure.
4. URLs de termos de uso e chaves secretas também foram criados. O URL de DESCOBERTA do MDM e o URL dos TERMOS DE USO do MDM estão definidos corretamente, mas não foram verificados se podem ser acessados ​​pela Internet

NB: Todos os itens acima e uma série de outros requisitos foram verificados e testados várias vezes. O dispositivo pode se registrar quando o InTune é usado como o servidor MDM (adicionando o aplicativo InTune ao meu Azure AD)

Um dispositivo de teste pronto para uso foi usado para executar os seguintes cenários de teste no Azure com um E5 incl. mdm + assinatura de segurança.

Durante nossos testes, obtivemos o seguinte erro:

****> we are not able to enroll Azure AD due to : Redirect UI
> [https://login.microsoftonline.com/WebApp/CloudDomainJoin/10] is not
> formed correctly****

Depois de pesquisar no Google, li que isso pode ser causado por problemas de DNS, problemas de proxy de saída ou vários outros motivos.

Também li que isso pode acontecer se o aplicativo não tiver sido instalado pelo administrador do locatário ou consentido por qualquer usuário no locatário. Podemos ter enviado a solicitação de autenticação para o locatário errado, mas verificamos isso com um colega hoje e concedemos todas as permissões necessárias conforme exigido. não deu certo

Também li que isso pode ser simplesmente devido a uma falha geral de autenticação, que ainda parece muito genérica para mim.

Alguém tem alguma pista sobre como solucionar esses tipos de problemas com base no erro relatado. Dicas serão muito apreciadas.