Em meu locatário do Azure AD que possui uma licença ativa do Azure AD Premium 2 , habilitei o gerenciamento de grupo de autoatendimento .
Os usuários podem criar grupos de segurança e configurar a política de associação com uma das opções disponíveis:
Isso também pode ser configurado no portal do Azure AD? Se sim, onde?
Temos uma CA Enterprise dos Serviços de Certificados do Microsoft Active Directory .
Depois de instalar o serviço, um contêiner AD é criado dentroCN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=ad,DC=example,DC=com
Nosso CDP é somente http. Não há caminho LDAP adicionado. Devo manter ou remover este recipiente?
Temos duas CAs corporativas intermediárias (Windows AD CS) em nosso domínio AD. Ambas as CAs têm apenas a função de Autoridade de Certificação habilitada.
CA1 é responsável pela emissão de certificados para estações de trabalho e usuários e possui um modelo Workstation Auth .
O CA2 é responsável por emitir certificados para servidores e possui um modelo Server Auth .
A inscrição automática está habilitada em todas as estações de trabalho e servidores em nosso domínio e em funcionamento.
Problema:
As estações de trabalho devem direcionar apenas o CA1 para registro automático
e os servidores devem direcionar apenas o CA2 para registro automático.
Eu quero conseguir isso usando políticas de grupo.
Eu sei que posso permitir a inscrição automática em um modelo apenas para membros de grupos de segurança, e isso funcionaria.
No entanto, prefiro uma solução usando políticas de grupo, porque organizamos estações de trabalho e servidores em UOs diferentes. Posso direcionar os dois grupos com políticas de grupo em UOs. A solução de grupo de segurança exigiria que gerenciássemos dois novos grupos de segurança além disso.
É possível configurar uma estação de trabalho ou servidor para se inscrever automaticamente apenas de uma determinada CA corporativa? Estou aberto a alternativas, se elas puderem ser alcançadas usando políticas de grupo.
Eu tenho um modelo de certificado (registrado automaticamente) que deve exigir a aprovação do gerente.
Para conseguir isso, marquei a caixa de seleção de aprovação do gerenciador de certificados da CA na guia Requisitos de emissão .
O computador faz o registro automático e o certificado é colocado na fila Pendente na autoridade de certificação.
Meu desejo é que, uma vez que o certificado pendente tenha sido aprovado manualmente, os certificados sejam renovados ou atualizados se a versão principal do modelo for incrementada, sem a aprovação do gerente. Mas não consigo fazer isso funcionar.
Quando incremento a versão principal do certificado, a solicitação nunca é emitida automaticamente, mas novamente colocada na fila Pendente para emissão manual.
Tentei alterar os mesmos critérios de inscrição para Certificado existente válido, mas isso não mudou nada.
Para acelerar minha solução de problemas, costumava certutil -pulseiniciar o processo de inscrição automática no computador solicitante.
Editar:
A política de inscrição automática no servidor afetado:
Eu tenho uma base de CA raiz autônoma no Windows Server 2019 Core .
Eu sei que certutil.exe -dump certificate.reqposso inspecionar o CSR, mas as políticas da CA raiz podem substituir os atributos de extensão solicitados.
Na edição Desktop, depois de importar o CSR para a CA raiz, posso inspecionar a solicitação pendente e ver onde as políticas da CA raiz podem substituir os atributos de extensão solicitados, adicionar extensões adicionais ou removê-las.
Por exemplo, o CSR solicita que a extensão Key Usage seja crítica, mas a política de CA raiz substitui as solicitações de Key Usage e remove o sinalizador crítico, como você pode ver na imagem abaixo.
Minhas perguntas são:
Eu tenho uma CA raiz autônoma (RootCA) e uma CA subordinada corporativa (SubCA). Ambos Windows Server 2019.
O RootCA parece ignorar as definições de configuração do arquivo CAPolicy.inf, ao tentar assinar o CSR do SubCA, conforme mostrado na visualização de propriedades da solicitação pendente:
O CAPolicy.inf no RootCA ( %SystemRoot%\CAPolicy.inf) é este:
[Version]
Signature= "$Windows NT$"
[Strings]
szOID_KEY_USAGE = "2.5.29.15"
[Extensions]
%szOID_KEY_USAGE% = AwIBhg==
Critical = %szOID_KEY_USAGE%
Durante a instalação do RootCA, o CAPolicy.inf foi usado para tornar crítica a extensão KeyUsage do certificado raiz. Isso pode ser visto nas propriedades do certificado raiz, bem como no certocm.log:Opened Policy inf: C:\Windows\CAPolicy.inf
A documentação afirma
O CAPolicy.inf é um arquivo de configuração que define as extensões, restrições e outras definições de configuração que são aplicadas a um certificado de CA raiz e a todos os certificados emitidos pela CA raiz .
Então, por que o RootCA ignora o CAPolicy.inf ao emitir um certificado (SubCA), apesar dos documentos afirmarem o contrário?
Estou tentando criar manualmente uma chave e CSR para uma nova CA subordinada corporativa do Windows AD CS (Windows Server 2019).
Gostaria de armazenar a chave no moderno Microsoft Software Key Storage Provider .
Ele falha com Provider type not defined. 0x80090017 (-2146893801 NTE_PROV_TYPE_NOT_DEF).
O comando que uso é:certreq.exe -new C:\requestconfig.inf C:\certificate.req
O C:\requestconfig.infarquivo é esse:
[Version]
Signature= "$Windows NT$"
[NewRequest]
Subject = "CN=My Subordinate CA"
HashAlgorithm = sha256
KeyAlgorithm = RSA
KeyLength = 2048
ProviderName = "Microsoft Software Key Storage Provider"
KeyContainer = "My Subordinate CA"
ExportableEncrypted = true
MachineKeySet = true
RequestType = PKCS10
SuppressDefaults = true
SecurityDescriptor = "D:P(A;OICI;0xd01f01ff;;;BA)(A;OICI;0xd01f01ff;;;SY)"
[RequestAttributes]
CertificateTemplate = SubCA
[Extensions]
2.5.29.15 = "{critical}{hex}03020186" ; Key Usage (critical): Digital Signature, Certificate Signing, CRL Signing
2.5.29.19 = "{critical}{text}ca=1&pathlength=1" ; Basic Constraints (critical)
1.3.6.1.4.1.311.21.1 = "{hex}020100" ; CA Version V0.0
Verifiquei se o CSP é válido executando certutil -csplist:
[...]
Provider Name: Microsoft Strong Cryptographic Provider
Provider Type: 1 - PROV_RSA_FULL
Provider Name: Microsoft Software Key Storage Provider
Provider Name: Microsoft Passport Key Storage Provider
[...]
Ele não tem um tipo de provedor, mas mesmo assim, adicionei ProviderType = 0e ProviderType = 1à configuração, sem sucesso.
Consegui usar uma configuração muito semelhante para criar meu certificado raiz:
[Version]
Signature= "$Windows NT$"
[NewRequest]
Subject = "CN=My Root CA"
HashAlgorithm = sha256
KeyAlgorithm = RSA
KeyLength = 4096
;KeyUsage = CERT_DIGITAL_SIGNATURE_KEY_USAGE | CERT_KEY_CERT_SIGN_KEY_USAGE | CERT_CRL_SIGN_KEY_USAGE
ProviderName = "Microsoft Software Key Storage Provider"
KeyContainer = "My Root CA"
ExportableEncrypted = true
MachineKeySet = true
RequestType = Cert
SuppressDefaults = true
SecurityDescriptor = "D:P(A;OICI;0xd01f01ff;;;BA)(A;OICI;0xd01f01ff;;;SY)
[Extensions]
2.5.29.15 = {critical}{hex}03020186 ; Key Usage (critical): Digital Signature, Certificate Signing, CRL Signing
2.5.29.19 = {critical}{text}ca=1&pathlength=None ; Basic Constraints (critical)
1.3.6.1.4.1.311.21.1 = {hex}020100 ; CA Version V0.0
A principal diferença é que, com essa configuração, crio uma chave e um certificado em vez de uma chave e CSR. As diferenças são: RequestTypeé Certe não PKCS10e não tem a RequestAttributesseção. Esta configuração não falhou com o NTE_PROV_TYPE_NOT_DEF.
O que está causando a falha repentina com a configuração da minha sub CA?
Preciso desativar a tela 'Mais informações necessárias' para minha conta de administrador de vidro quebrado.
De acordo com a documentação, desabilitei os Padrões de Segurança do Azure na semana passada.
Em seguida, criei uma Política de Acesso Condicional que exige que todos os usuários entrem com o MFA, exceto a conta de administrador de segurança.
Isso não desativou o 'Mais informações necessárias', mas pelo menos agora posso clicar no botão Avançar e pular a configuração do MFA.
No entanto, eu preciso que essa tela não apareça em primeiro lugar. Como faço para conseguir isso?
Como você provavelmente sabe, se você promover um novo domínio em uma nova floresta em um sistema operacional Windows Server diferente do inglês, todos os grupos internos serão localizados. Estou tentando renomear os grupos internos de um domínio do Active Directory para inglês, em um ambiente de teste.
O problema é que os grupos internos - por exemplo, o grupo Administradores - têm alguns systemFlags como DOMAIN_DISALLOW_RENAME , me impedindo de renomear o grupo.
Tentei executar ldp.exe como SYSTEM no controlador de domínio e excluir o atributo systemFlags, mas ele falha devido a permissões.
***Call Modify...
ldap_modify_s(ld, 'CN=Administrators,CN=Builtin,DC=ad,DC=example,DC=com',[1] attrs);
Error: Modify: Constraint Violation. <19>
Server error: 000020B1: AtrErr: DSID-030F158A, #1:
0: 000020B1: DSID-030F158A, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 90177 (systemFlags)
Error 0x20B1 The attribute cannot be modified because it is owned by the system.
Encontrei um tópico aqui onde uma pessoa conseguiu isso, mas ele pulou os detalhes e não consigo acertar.
Bem, finalmente encontrei uma maneira de renomeá-lo usando ldp.exe após a ligação ao servidor alterando o atributo de esquema Obrigado
Então, como eu faria isso?
Instalei os Serviços de Implantação do Windows (WDS) em uma nova máquina Server 2012 R2. Meus clientes Hyper-V (Gen2, UEFI, Secure Boot) falham ao solicitar 'boot\x64\wdsmgfw.efi' via TFTP. O servidor responde que o arquivo não foi encontrado.
Posso confirmar que 'C:\RemoteInstall\Boot\x64\wdsmgfw.efi' está realmente ausente. Todo o resto está lá.
Tentei instalar um Server 2016 e configurar o WDS, mas o arquivo está faltando lá também.
Por que esse arquivo está ausente e o que devo fazer para que o PXE funcione?
Acabei de descobrir que 192.112.36.4( g.root-servers.net.) não responde a pedidos, nem responde a pings.
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
Verifiquei http://www.internic.net/domain/named.root , que é uma lista atualizada de servidores raiz e o endereço IP está correto. Sempre tive a impressão de que esses servidores raiz são redundantes a ponto de ser impossível que haja tempo de inatividade. De acordo com http://root-servers.org , existem seis locais em todo o mundo onde os servidores estão localizados, portanto, presumo que estou correto com essa suposição.
Minha pergunta é se g.root-servers.net.é de alguma forma diferente de todos os outros, ou especial,
e se devo não obter uma resposta de DNS por algum motivo?
Temos várias assinaturas do Office 365 Business Premium. O Office é instalado por meio do Click-2-Run e, portanto, está sujeito a atualizações e upgrades automáticos.
Esta notificação foi publicada no centro de mensagens:
Prepare-se para a atualização do Office 2016
Detalhes
A partir de 9 de fevereiro de 2016, o Office 2016 Current Branch for Business estará disponível. A primeira versão do Current Branch for Business está disponível desde setembro e agora estamos disponibilizando-a amplamente para os clientes do Office 365.
Como isso me afeta?
Current Branch for Business é o branch de atualização padrão do Office 2016, para assinaturas do Office 365 ProPlus.
O que preciso fazer para me preparar para essa mudança?
Recomendamos que você analise as orientações de atualização e desenvolva um plano para gerenciar a atualização de suas instalações existentes do Office 365 ProPlus. As atualizações automáticas para clientes do Office 365 ProPlus e Office 365 Business começarão em fevereiro de 2016. Se desejar desativar as atualizações automáticas, consulte o seguinte artigo da base de conhecimento: https://support.microsoft.com/en-us/kb/ 3097292 .
Agora, tanto a notificação quanto o artigo falam explicitamente sobre o Office 365 ProPlus . Isso é importante porque o Office 365 Business Premium não oferece suporte a diretivas de grupo e a chave de registro mencionada HKLM\SOFTWARE\Policies\Microsoft\Office\15.0\Common\OfficeUpdate\EnableAutomaticUpgradeé, na verdade, uma chave de registro relacionada à diretiva de grupo e não funcionará .
A razão pela qual estou perguntando é que tivemos um grande problema com a atualização do Outlook 2013 para o Office 2016 que deixou todos os perfis do Outlook em um estado inutilizável em nossos computadores de controle de qualidade.
Como evito que o Office 2013 Business Premium atualize automaticamente para o Office 2016 Business premium?
Para evitar qualquer confusão, há uma pergunta relacionada em serverfault , mas ela aborda apenas o Office 365 ProPlus.
Configurei um Cluster de Failover do Hyper-V com dois nós e um controlador de domínio. A atualização com reconhecimento de cluster está habilitada.
O BPA apresenta o seguinte erro:
Para participar da replicação, os servidores em clusters de failover devem ter um agente de réplica do Hyper-V configurado.
Fonte: http://social.technet.microsoft.com/wiki/contents/articles/12798.hyper-v-to-participate-in-replication-servers-in-failover-clusters-must-have-a-hyper- v-replica-broker-configured.aspx
Não entendo porque o BPA está apresentando esse erro. Não uso e não configurei a replicação.
VMName ReplicationState
------ ----------------
xxxxxxxx-xxxxxxxxx Disabled
xxxxxxxx Disabled
xxxxxx Disabled
xxxxxxxx Disabled
xxxxxxxxxx Disabled
xxxxxxxxxxxxxx Disabled
xxxxxxxxxxx Disabled
xxxx-xx Disabled
xxxx-xxx Disabled
xxxxxxxxxxxxxxxxxxxxxxx Disabled
xxxxxxxxxx Disabled
xxxxxxxxx Disabled
xxxxxxxxxx Disabled
O que há de errado e como posso corrigi-lo?
Levei várias horas para corrigir o problema porque o armazenamento de componentes local foi corrompido e os computadores estão acessando um servidor WSUS local em vez do servidor público de atualização da Microsoft (e porque eu uso o Dism muito raramente). Para referência e para ajudar outras pessoas com o mesmo problema, escreverei uma descrição do problema e fornecerei uma solução.
Desde a atualização para o Windows 10 Pro versão 1511 (Build 10586), tenho um problema com um arquivo opencl.dll corrompido em vários locais.
Eu tentei sfc.exe /scannow, mas não conseguiu resolver o problema. As mensagens de erro são, entre outras:
2015-12-08 08:50:43, Info CSI 00003c3a Hashes for file member \SystemRoot\WinSxS\wow64_microsoft-windows-r..xwddmdriver-wow64-c_31bf3856ad364e35_10.0.10586.0_none_3dae054b56911c22\opencl.dll do not match actual file [l:10]"opencl.dll" :
Found: {l:32 g2VAunZ6/2J1G3oL7kf9fjInPUA9VYeiJcl9VKgizaY=} Expected: {l:32 9rnAnuwzPjMQA7sW63oNAVhckspIngsqJXKYSUeQ5Do=}
2015-12-08 08:50:43, Info CSI 00003c3b [SR] Cannot repair member file [l:10]"opencl.dll" of microsoft-windows-RemoteFX-clientVM-RemoteFXWDDMDriver-WOW64-C, version 10.0.10586.0, arch Host= amd64 Guest= x86, nonSxS, pkt {l:8 b:31bf3856ad364e35} in the store, hash mismatch
2015-12-08 08:50:43, Info CSI 00003c3c [SR] This component was referenced by [l:125]"Microsoft-Windows-RemoteFX-VM-Setup-Package~31bf3856ad364e35~amd64~~10.0.10586.0.RemoteFX clientVM and UMTS files and regkeys"
2015-12-08 08:50:43, Info CSI 00003c3d Hashes for file member \??\C:\WINDOWS\SysWOW64\opencl.dll do not match actual file [l:10]"opencl.dll" :
Found: {l:32 g2VAunZ6/2J1G3oL7kf9fjInPUA9VYeiJcl9VKgizaY=} Expected: {l:32 9rnAnuwzPjMQA7sW63oNAVhckspIngsqJXKYSUeQ5Do=}
2015-12-08 08:50:43, Info CSI 00003c3e Hashes for file member \SystemRoot\WinSxS\wow64_microsoft-windows-r..xwddmdriver-wow64-c_31bf3856ad364e35_10.0.10586.0_none_3dae054b56911c22\opencl.dll do not match actual file [l:10]"opencl.dll" :
Found: {l:32 g2VAunZ6/2J1G3oL7kf9fjInPUA9VYeiJcl9VKgizaY=} Expected: {l:32 9rnAnuwzPjMQA7sW63oNAVhckspIngsqJXKYSUeQ5Do=}
2015-12-08 08:50:43, Info CSI 00003c3f [SR] Could not reproject corrupted file [l:23 ml:24]"\??\C:\WINDOWS\SysWOW64"\[l:10]"opencl.dll"; source file in store is also corrupted
Ok, então o problema está claro agora. Infelizmente, o SFC não consegue resolver a corrupção porque o armazenamento de componentes local também foi corrompido. Infelizmente, perdi as mensagens de erro que indicavam a corrupção do armazenamento de componentes.
Então eu tentei Dism /Online /Cleanup-Image /RestoreHealthsem sucesso. Ele falha com o erro 0x800f081f , indicando outro problema com os arquivos de origem.
2015-12-08 08:57:35, Info CBS Exec: Download qualification evaluation, business scenario: Manual Corruption Repair
2015-12-08 08:57:35, Info CBS Exec: Clients specified using Windows Update.
2015-12-08 08:57:35, Info CBS WU: Update service is not default AU service, skip. URL: https://fe2.update.microsoft.com/v6/, Name: Microsoft Update
2015-12-08 08:57:35, Info CBS WU: Update service is not default AU service, skip. URL: https://fe2.ws.microsoft.com/v6/, Name: Windows Store
2015-12-08 08:57:35, Info CBS WU: Update service is not default AU service, skip. URL: https://fe3.delivery.mp.microsoft.com/, Name: Windows Store (DCat Prod)
2015-12-08 08:57:35, Info CBS WU: WSUS service is the default, URL: (null), Name: Windows Server Update Service
2015-12-08 08:57:35, Info CBS DWLD:Search is done, set download progress to 20 percent.
2015-12-08 08:57:35, Info CBS Nothing to download, unexpected
2015-12-08 08:57:35, Info CBS Failed to collect payload and there is nothing to repair. [HRESULT = 0x800f081f - CBS_E_SOURCE_MISSING]
2015-12-08 08:57:35, Info CBS Failed to repair store. [HRESULT = 0x800f081f - CBS_E_SOURCE_MISSING]
Observando as mensagens de erro, fica claro que o Windows está configurado para usar nosso servidor WSUS local e, portanto, o Dism não consegue recuperar o arquivo válido dos repositórios. Embora eu tenha certeza de que poderia de alguma forma configurar o WSUS para fornecer os arquivos necessários, não sei como e preciso de uma solução rápida. (Se alguém souber como configurar o WSUS adequadamente, forneça informações).
Limitar o acesso ao armazenamento local adicionando o parâmetro /LimitAccessseria inútil, pois o armazenamento de componentes local também está corrompido, conforme mencionado anteriormente.
Eu experimentei esse problema em duas máquinas. Uma atualização do Windows 10 não corrigiu o problema.
Qual é a diferença entre New-DfsnFolder e New-DfsnFolderTarget?
Ambos os comandos requerem ambos os parâmetros -Pathe -TargetPath. Eles criam a mesma coisa. Uma pasta DFS com um destino.
Então, o que é diferente?
Eu preciso dar a alguns usuários ReadPermissions para algumas caixas de correio. E preciso que as caixas de correio somente leitura apareçam no Outlook dos usuários por meio do mapeamento automático.
Sei que você pode conseguir isso por meio do atributo mxExchDelegateListLink no Active Directory. No entanto, isso não está funcionando com o Office 365 e o DirSync.
Eu descobri que você pode visualizar a propriedade no PowerShell usando o seguinte comando:
(Get-MailboxPermission <mailbox> -ReadFromDomainController)[0].DelegateListLink
Ele lista todos os usuários cujo Outlook mapeará automaticamente a caixa de correio consultada.
Como posso adicionar usuários a esse atributo via PowerShell? Esta propriedade é a mesma para cada objeto MailboxPermission, então você provavelmente não pode simplesmente editar a propriedade por si só.
Lendo as recomendações de rede para um cluster Hyper-V no Windows Server 2012 , fiquei com algumas perguntas sem resposta.
Recomenda-se ter uma rede de gerenciamento e uma rede de cluster.
A rede de gerenciamento está definida como """ Permitir comunicação de rede de cluster e conectividade do cliente ",
e a rede de cluster está definida como " Permitir apenas comunicação de rede de cluster ". Mas não há outra diferença ou classificação.
Como o cluster de failover realmente sabe qual dessas duas redes usar para " comunicação de cluster entre nós, como a pulsação do cluster e o redirecionamento de Volumes Compartilhados do Cluster (CSV) "?
Eu tenho um servidor Hyper-V e três licenças 'Windows Server 2012 R2 Standard' (ROK, não VL). Estou me perguntando com quais chaves devo ativar quais servidores? O seguinte é o método correto? Se for, existe uma abordagem melhor ou mais simples?
Anfitrião: Chave 1
Convidado 1: Chave 1
Convidado 2: Chave 1
Convidado 3: Chave 2
Convidado 4: Chave 2
Convidado 5: Chave 3
Convidado 6: Chave 3
No momento, estou planejando um ambiente Windows Server 2012 R2 de alta disponibilidade em um Hyper-V-Cluster com dois nós. Não tenho certeza sobre como implantar o controlador de domínio virtual para o domínio de trabalho, para manter a floresta disponível quando um nó fica inativo.
Vejo duas opções:
Crie uma máquina virtual com os serviços de domínio e configure a vm como um recurso de cluster no cluster de failover. Deixe o cluster se preocupar com a disponibilidade da máquina virtual (controlador de domínio).
Crie uma VM no Hyper-V-Node 1. Crie uma segunda VM no Hyper-V-Node 2. As VMs não são configuradas como um recurso de cluster (sem redundância por VM). Instale serviços de domínio em ambas as VMs. Deixe que os controladores de domínio se preocupem em oferecer os serviços de domínio, se um nó e, portanto, uma VM ficar inativo.
Minhas perguntas são:
Agradeço respostas de alta qualidade, faça backup de suas respostas com fontes.
Estou tendo problemas para acessar a locationpropriedade do site do meu Active Directory via Powershell. (Windows Server 2012 R2)
O seguinte comando não retorna nenhum valor:
> (Get-ADReplicationSite "Default-First-Site-Name" | Get-ADObject).location
Este comando retorna um identificador:
> (Get-ADReplicationSite "Default-First-Site-Name" | Get-ADObject).objectGUID
Quando estou olhando para o editor de atributo gráfico do objeto no snap-in de sites e serviços do Active Directory , posso verificar pela propriedade objectGUID se consulto o objeto AD correto e se a propriedade location está preenchida .
Então, por que o Powershell não retorna nenhum valor e como consulto e edito o locationatributo?