tb1's questions

[movido do StackOverflow]

Usamos PSFTP, junto com um arquivo ppk e um arquivo de comando em lote, para carregar um CSV para um host SFTP remoto. Isso tem funcionado por muitos (muitos) meses e só recentemente o parâmetro -b falhou com "Fatal: unable to open"

Detalhes:
Executamos PSFTP.exe no Windows usando um arquivo em lote ou prompt de comando.

O arquivo de comando em lote que passamos com o parâmetro -b é chamado "sftpcommands.txt" e tem as seguintes linhas:

put "D:\batch\Upload.csv"
quit

Aqui está o que executamos a partir de um arquivo em lote ou prompt de comando:

psftp.exe -v -P 22 -i D:\batch\keyfile.ppk -b D:\batch\sftpcommands.txt [email protected]

Aqui está o resultado:

Looking up host "SFTPHost.domain.com" for SSH connection
Connecting to hostIP port 22
We claim version: SSH-2.0-PuTTY_Release_0.82
Connected to hostIP (from localIP:35022)
Remote version: SSH-2.0-AWS_SFTP_1.1
Using SSH protocol version 2
No GSSAPI security context available
Doing ECDH key exchange with curve nistp256, using hash SHA-256 (SHA-NI accelerated)
Host key fingerprint is:
ssh-rsa 4096 SHA256:ajIF+morestuffhere
Initialised AES-256 SDCTR (AES-NI accelerated) outbound encryption
Initialised HMAC-SHA-256 (SHA-NI accelerated) outbound MAC algorithm
Initialised AES-256 SDCTR (AES-NI accelerated) inbound encryption
Initialised HMAC-SHA-256 (SHA-NI accelerated) inbound MAC algorithm
Reading key file "D:\batch\keyfile.ppk"
Using username "OurUser".
Offered public key
Offer of public key accepted
Authenticating with public key "keynameinformation here"
Sent public key signature
Access granted
Opening main session channel
Remote debug message: SFTP: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
Remote debug message: SFTP: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
Opened main channel
Started a shell/command
Connected to some-host.server.transfer.us-east-1.amazonaws.com
Remote working directory is /
Fatal: unable to open
Session sent command exit status 0
Main session channel closed
All channels closed

Agora a parte estranha: podemos nos livrar da sintaxe do script -b e inserir manualmente os mesmos comandos encontrados no sftpcommands.txtarquivo quando o psftp>prompt aparecer (por exemplo):

psftp.exe -v -P 22 -i D:\batch\keyfile.ppk [email protected]

Looking up host "SFTPHost.domain.com" for SSH connection
Connecting to hostIP port 22
We claim version: SSH-2.0-PuTTY_Release_0.82
Connected to hostIP (from localIP:35022)
Remote version: SSH-2.0-AWS_SFTP_1.1
Using SSH protocol version 2
No GSSAPI security context available
Doing ECDH key exchange with curve nistp256, using hash SHA-256 (SHA-NI accelerated)
Host key fingerprint is:
ssh-rsa 4096 SHA256:ajIF+morestuffhere
Initialised AES-256 SDCTR (AES-NI accelerated) outbound encryption
Initialised HMAC-SHA-256 (SHA-NI accelerated) outbound MAC algorithm
Initialised AES-256 SDCTR (AES-NI accelerated) inbound encryption
Initialised HMAC-SHA-256 (SHA-NI accelerated) inbound MAC algorithm
Reading key file "D:\batch\keyfile.ppk"
Using username "OurUser".
Offered public key
Offer of public key accepted
Authenticating with public key "keynameinformation here"
Sent public key signature
Access granted
Opening main session channel
Remote debug message: SFTP: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
Remote debug message: SFTP: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
Opened main channel
Started a shell/command
Connected to some-host.server.transfer.us-east-1.amazonaws.com
Remote working directory is /
psftp> put "D:\batch\Upload.csv"
local:D:\batch\Upload.csv => remote:/Upload.csv
psftp> quit
Session sent command exit status 0
Main session channel closed
All channels closed

O terceiro moveu os servidores SFTP alguns meses atrás, mas, até onde sei, o parâmetro -b ainda estava funcionando no novo host (no entanto, posso estar errado).

Até onde sei, nada mudou do nosso lado e, como indicado, estamos fazendo testes A/B com o mesmo usuário local do Windows conectado, os mesmos arquivos locais, etc. Não deve haver problemas de direitos locais, pois, novamente, estamos usando o Windows, e a conta conectada é o que está abrindo/editando/acessando todos os arquivos envolvidos. Também tentei mover o parâmetro -b para posições diferentes na linha de comando.

Esse erro pode ser uma configuração de segurança, formato ou configuração no servidor SFTP remoto que está causando confusão com o arquivo de comando -b?

Observação: tenho um tíquete aberto com o pessoal que opera o host SFTP remoto para triangular o problema e, se eu puder resolver isso, postarei a resposta aqui, caso ajude outra pessoa a ver o "Fatal: não é possível abrir" na opção -b.

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!

Temos um servidor híbrido Exchange 2019 para habilitar remotamente nossos usuários de AD para email e enviar para nossas caixas de correio a partir de determinados aplicativos legados. Embora nossos usuários sejam todos vinculados ao AD, criamos algumas caixas de correio (por exemplo, compartilhadas) diretamente no EOL/M365 (também conhecido como nenhum objeto AD).

O servidor híbrido envia mensagens de forma confiável para todas as nossas caixas de correio remotas vinculadas ao AD, mas assim que alteramos o destinatário para uma caixa de correio compartilhada criada diretamente no EOL (sem objeto AD), obtemos algo assim:

<550 4.4.7 QUEUE.Expired; message expired in unreachable destination queue. Reason: A matching connector cannot be found to route the external recipient>

Além disso, pelo que vale a pena, notei nos logs de rastreamento de mensagens que quando endereçamos para " [email protected] " as entregas bem-sucedidas fazem uma fonte de roteamento resolver para " [email protected] ". Nossas caixas de correio compartilhadas são criadas diretamente no EOL e teriam apenas " [email protected] " por padrão.

Enquanto escrevia isso, tentei adicionar um SMTP secundário de " [email protected] " por meio do EOL e enviar outra mensagem de teste, mas o host híbrido ainda considera a caixa de correio compartilhada como um destinatário externo.

Se alguém já passou por isso e tiver alguma sugestão, ficarei grato. Obrigado!

Estamos executando o modo híbrido do Exchange com caixa de correio remota e arquivo morto no M365. Um de nossos funcionários saiu há muitos meses e sua caixa de correio foi para exclusão/retenção reversível. Seu objeto AD foi apenas desativado (nunca excluído), portanto, quando foi restaurado e sincronizado novamente por meio do Entra Connect, um novo usuário M365 com o mesmo alias, mas com caixa de correio (vazia) foi criado (o que foi bom).

Nosso problema é que o usuário AD ainda tem o msExchArchiveGUID anterior para o usuário, e esse arquivo ainda é excluído de forma reversível no EOL, mas, novamente, o usuário no M365 é uma versão diferente do usuário. Preciso descobrir como dizer ao AD para criar um novo arquivo (vazio) para o usuário M365 agora ativo.

Detalhes:

Na EAC:

Se eu executar: Get-RemoteMailbox returningUser | fl displayname, ArchiveGuidele reporta da propriedade msExchArchiveGUID no AD.:

ArchiveGuid : some-legit-archive-guid-number

Em EOL:

Se eu correr: Get-Mailbox returningUser | fl archiveguideu recebo:

ArchiveGuid : 00000000-0000-0000-0000-000000000000

No entanto, se eu executar:Get-EXOMailbox -SoftDeletedMailbox -Archive | where { $_.alias -eq 'returningUser' } | select Guid

Eu recebo:

Guid 
---
some-legit-archive-guid-number

O que tentei: excluir o arquivo baseado em híbrido, sincronizar e adicionar novamente:

No EAC:, Disable-RemoteMailbox returningUser -Archiveexecute o Entra Connect, tudo parece bem. msExchArchiveGUID no AD está vazio. Quando executo Enable-RemoteMailbox returningUser -Archiveo incômodo anterior msExchArchiveGUID retorna.

Eu li muitos exemplos de incompatibilidades em que a solução está dizendo ao EAC para usar a versão EOL do GUID de arquivo, mas neste caso parece que o EOL não pode usar a versão EAC do GUID porque é excluído de forma reversível e vinculado a um usuário anterior do artefato.

Se alguém souber como dizer ao EAC para parar de procurar (onde quer que esteja procurando) aquele ArchiveGUID anterior e apenas emitir um novo arquivo, ficarei grato!

Obrigado!

Última observação: se eu executar isso:

Get-MsolUser -HasErrorsOnly | fl DisplayName,UserPrincipalName,@{Name="Error";Expression={($_.errors[0].ErrorDetail.objecterrors.errorrecord.ErrorDescription)}}

O erro é:

{The value "some-legit-archive-guid-number" of 
property "ArchiveGuid" is used by another recipient object. 
Please specify a unique value.}

(também conhecido como mesmo GUID excluído de forma reversível)

Somos um locatário M365 em modo Híbrido, apenas com caixas de correio Exchange Online, sincronizando atributos de caixa de correio através do Entra Connect. Adquirimos outra empresa (não um inquilino M365). Assumimos o controle de seu DNS e copiamos suas antigas caixas de correio firmes para caixas de correio EOL em nosso locatário, que já usa nosso próprio domínio personalizado como endereço principal.

Neste ponto, queremos apenas adicionar seus endereços de e-mail de domínio antigos como um smtp secundário para que eles possam receber respostas de e-mail para threads antigos diretamente em nosso locatário.

Teste inicial: se adicionarmos seus endereços antigos agora e sincronizarmos o EntraConnect, não veremos esse alias extra no painel de administração do M365 (mas não é surpresa, vemos no Exchange Hybrid local).Set-ADUser userMailbox -add @{ProxyAddresses='smtp:[email protected]'}

Obviamente, ainda precisamos adicionar seu domínio personalizado ao nosso locatário M365 para que o painel de administração "veja" esse domínio, mas a questão é se, após esse ponto, adicionar esses proxyAddresses por meio de Set-ADUser sincronizará no EOL ou se nós temos que fazer outra coisa com o EntraConnect, ou podemos simplesmente executar um separado para combiná-lo?Set-Mailbox userMailbox -EmailAddresses @{add="[email protected]"}

Observação separada: sei que podemos adicionar sufixos UPN em domínios e relações de confiança do AD e sincronizar o sufixo de domínio dessa maneira, mas isso é apenas para um alias de caixa de correio, não para identidade; ninguém fará login no AD ou M365 com esse domínio como UPN... https://learn.microsoft.com/en-us/answers/questions/781907/add-new-email-domain-to-office- 365-híbrido

Agradecemos antecipadamente a qualquer um que tenha feito isso!

Ao importar um certificado de dispositivo/chave privada por meio do CERTLM, a GUI parece escolher um provedor de serviços de criptografia (CSP) obsoleto chamado "Microsoft Strong Cryptographic Provider"; Gostaria de saber se existe uma maneira de alterar isso para "Provedor de armazenamento de chaves de software da Microsoft" por meio do assistente ou da política de grupo ou (outros meios).

Mais detalhes: Um fornecedor me pediu para importar um PFX para um armazenamento de certificados de máquina local do Windows 11 por meio da seguinte sintaxe de comando de linha:

certutil -csp "Microsoft Software Key Storage Provider" -importpfx MyPathToCertificate.pfx NoExport

Isso funcionou muito bem com o software deles, porém quando tentei importar o mesmo PFX anteriormente, usei CERTLM (GUI) para importar o certificado para o mesmo local (máquina local/loja pessoal). Isso pareceu funcionar na época (o certificado apareceu lá), mas causou erros de descriptografia conforme indicado nos registros do fornecedor.

Veja como importei através do CERTLM:

1. Iniciei o Prompt de Comando via UAC/Escolher Certificados (máquina local)
2. Importei o PFX usando as opções padrão para a loja Pessoal

Depois de executar o seguinte comando: Certutil -store My

Notei que o certificado tinha a seguinte linha: Provider = Microsoft Strong Cryptographic Provider

enquanto o comando certutil escolheu explicitamente "Microsoft Software Key Storage Provider"

De acordo com https://www.pkisolutions.com/understanding-microsoft-crypto-providers/ "Microsoft Strong Cryptographic Provider" é um provedor legado obsoleto, enquanto "Microsoft Software Key Storage Provider" é uma escolha moderna e preferida para trabalhar com novas chaves .

O CSP diferente explica por que o aplicativo do fornecedor não estava funcionando após a importação original e entendo por que a MS escolheria um provedor "antigo" como padrão para compatibilidade com versões anteriores, mas estou curioso para saber se existem maneiras de especificar o CSP ao executar a importação através do CERTLM daqui para frente.

Se você usa o Exchange 2016 Hybrid, mas apenas para gerenciamento de caixa de correio em nuvem e retransmissão de saída, vale a pena trocar em um host híbrido do Exchange 2019?

Mais detalhes: Algum tempo atrás, alguém nos ajudou inicialmente a configurar o Azure AD Connect e um Exchange 2016 Hybrid, usado para configuração de caixa de correio na nuvem e saída de retransmissão de copiadoras e aplicativos herdados. Nenhum cliente ou serviço jamais acessou o host híbrido, exceto para Autenticação SMTP (e, novamente, é tudo de saída interna para EXO). Não temos pastas públicas ou qualquer outra coisa que alguém proveniente de hospedagem anterior no local do Exchange possa ter. (Gerenciamos listas de distribuição internamente, mas isso é sincronizado por meio do AADConnect). Essa pessoa se foi e tenho mantido as atualizações cumulativas e mantido o AADConnect e o EX2016 híbrido funcionando sem problemas, como estão.

O suporte estendido do Exchange 2016 termina em outubro de 2025. Agora que o Exchange 2019 CU12 tem uma licença híbrida gratuita e oferece suporte ao Windows 2022 Server, não sei dizer se vale a pena arriscar trocá-lo por proteção à prova de futuro.

Como não configurei diretamente o ambiente inicial, estou preocupado em simplificar demais o que seria necessário. Meu entendimento do processo é o seguinte:

1. Deixe EX2016 sozinho: em um host separado, instale o Windows 2022 e o Exchange 2019 CU12 - esse processo obviamente envolve estender o esquema AD para EX2019
2. Execute o Assistente de configuração híbrida online mais recente ("HCW") apenas o tempo suficiente para obter a licença gratuita
3. Configurar certificado SSL de terceiros, (re)criar conectores de recebimento, testar retransmissão de aplicativos internos
4. Execute novamente o HCW, continue para transferir a conexão para este novo host EX2019 versus EX2016

Coisas que não sei:

• Se devemos exportar o(s) certificado(s) de 2016 e importar para 2019 manualmente ou o HCW manipula usando o certificado atual na caixa de 2019
• Se o HCW puxa o conector de recepção anterior ou qualquer outra configuração útil de EX2016 para EX2019
• Se precisamos executar novamente a configuração separada do AADConnect novamente após as alterações do host híbrido
• Qual entidade MS lida com o suporte? O suporte do Exchange Online não inclui perguntas híbridas (mesmo que estejamos usando apenas uma caixa híbrida para retransmissão EXO e conectividade de caixa de correio em nuvem). Como não hospedamos o Exchange local, essa equipe também não lida com o suporte.

Se alguém realizou "a troca" de 2016 a 2019, informe-me o quão longe da base estou.

Eu sei que tenho tempo - e o outro plano óbvio é reduzir qualquer necessidade de retransmissão interna nos próximos dois anos, enquanto mais e mais aplicativos e dispositivos legados começam a acompanhar as alterações no SMTP Auth (por exemplo, OAuth). Obrigado!