Por meio da interface de gerenciamento atendida na porta 5480 por padrão, você pode habilitar o acesso SSH a um vCenter Server Appliance. Como isso pode ser feito programaticamente usando PowerCLI?
stackprotector's questions
Em um ambiente de desenvolvimento, quero modificar a data de 'último conjunto de senha' de minhas contas do AD para que elas não comecem a expirar durante a fase de desenvolvimento, mas assim que o ambiente se tornar um ambiente de produção.
Como posso alterar essa data?
No DC de uma floresta de AD único, estou conectado como administrador de domínio padrão Administrator
(neste caso, também o administrador corporativo). Em um PowerShell elevado, tento obter os tipos de criptografia Kerberos com o seguinte comando (conforme documentado aqui ):
ksetup /getenctypeattr my.example.com
Mas recebo uma mensagem de erro em vez disso:
Query of attributes on MY.EXAMPLE.COM failed with 0xc0000034
Failed /GetEncTypeAttr : 0xc0000034
Em consequência (muito provavelmente), também recebo esse erro ao tentar definir os tipos de criptografia, conforme descrito nesta pergunta , que atualmente não possui uma resposta séria, infelizmente.
Isso acontece no Windows Server 2016 e também no Windows Server 2019, que foram configurados usando principalmente as configurações padrão. Como um simples get pode falhar? O código de erro não parece estar documentado. Alguém sabe como solucionar ou resolver esse problema?
Na GUI ( Snap-in MMC de domínios e relações de confiança do Active Directorydomain.msc
( )), você pode definir a configuração "O outro domínio oferece suporte à criptografia Kerberos AES" para uma relação de confiança:
Estou procurando uma maneira de definir essa configuração programaticamente. Já revisei o Install-ADDSDomain
cmdlet do PowerShell e também a netdom TRUST
ferramenta, mas ambos não parecem incluir uma opção para definir a configuração de criptografia Kerberos AES .
Alguém pode me dizer, como posso definir essa configuração programaticamente?
Eu tenho uma configuração de floresta multidomínio MS ADDS simples com um domínio pai e um subdomínio. Juntei um servidor RHEL 8 com sucesso ao subdomínio usando esta documentação oficial . Todos os SOs foram configurados usando o máximo possível de padrões. Eu posso SSH com sucesso no servidor RHEL usando uma conta AD do subdomínio. Mas quando tento usar uma conta do domínio pai, o login falha. Assim que envio o nome de usuário do domínio pai, journalctl
relata o seguinte erro:
sssd_be[...]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC has no support for encryption type)
Verifiquei os DCs de cada domínio e posso confirmar que todos os DCs suportam os mesmos três tipos de criptografia padrão (que são armazenados no msDS-SupportedEncryptionTypes
atributo de cada conta de computador DC):
- RC4_HMAC_MD5
- AES128_CTS_HMAC_SHA1_96
- AES256_CTS_HMAC_SHA1_96
Também confirmei que o RHEL 8 oferece tipos de criptografia adequados ( /etc/crypto-policies/back-ends/krb5.config
):
[libdefaults]
permitted_enctypes = aes256-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 camellia256-cts-cmac aes128-cts-hmac-sha1-96 aes128-cts-hmac-sha256-128 camellia128-cts-cmac
Portanto, deve haver duas correspondências: aes128-cts-hmac-sha1-96
e aes256-cts-hmac-sha1-96
. Como já disse, está funcionando bem para o subdomínio. Então, por que não há um tipo de criptografia adequado para o domínio pai?
A partir do HPE ProLiant System Utilities (BIOS), inicializei no HPE Smart Storage Administrator (SSA) para migrar uma unidade lógica com RAID6 (e dados existentes) para RAID5. Depois de iniciar a tarefa de migração, que levaria várias horas para ser concluída, a única coisa que pude fazer foi clicar no X
canto superior direito. Depois disso, fiquei preso em uma tela dizendo:
Depois de concluir a configuração - reinicie o sistema.
O que isso significa? Posso reinicializar o servidor por meio do iLO ( Reset ou Cold boot ) ou preciso esperar até que a migração seja concluída para finalmente inicializar no meu sistema operacional?
Na minha infraestrutura, tenho dois servidores com Windows Server 2019 e Hyper-V instalados. Uma SAN é conectada diretamente a ambos os servidores via FC. A SAN fornece três volumes para ambos os servidores: um volume para o quorum, um volume para VMs e um volume para dados.
Planejo implantar um serviço de arquivos com a maior disponibilidade possível para minha infraestrutura. Portanto - como tenho dois nós - quero implantar dois servidores de arquivos. Dessa forma, posso tolerar a falha de um servidor inteiro (host) ou a falha de um servidor de arquivos virtual. Com apenas um servidor de arquivos virtual (com HA habilitado), eu toleraria apenas a falha de um host, mas não uma falha da própria VM.
Pretendo usar o volume de dados da minha SAN para implantar um disco rígido virtual compartilhado, que ambos os servidores de arquivos virtuais usarão para fornecer os compartilhamentos de arquivos.
Além disso, quero que os usuários não precisem se preocupar com qual servidor de arquivos eles acessam para acessar seus arquivos. \\FileSrv1\Data\README.md
deve ser o mesmo que \\FileSrv2\Data\README.md
, mas os usuários devem poder acessá-lo como \\FS\Data\README.md
. Tanto quanto eu sei, este é um caso de uso típico para DFS. Mas não quero dois servidores de arquivos que repliquem seus dados, pois tenho um armazenamento compartilhado.
Então, minha pergunta é, posso usar ambos - um armazenamento compartilhado para servidores de arquivos virtuais E DFS para abstrair o acesso ao arquivo - no meu cenário?
Infelizmente, o snap-in MMC de domínios e relações de confiança do Active Directory (domain.msc) permite criar uma relação de confiança de saída para um controlador de domínio (em outras palavras: especificar o nome de um controlador de domínio como o nome do domínio a ser confiável). Ainda mais infelizmente, você não pode reverter essa alteração pela GUI. Se você tentar remover essa confiança, receberá um pop-up de aviso com a seguinte mensagem:
Ocorreu um erro interno.
Tentando deletar via netdom
:
netdom trust my.domain.local /domain:dc1 /oneside:trusting /remove /force
também falha com a mesma mensagem:
Ocorreu um erro interno.
Então, como posso excluir esse objeto de confiança?