All perguntas(server)

Sou o autor do checkdmarc, uma ferramenta CLI de código aberto para verificar DMARC e outros padrões de segurança de e-mail. Uma dessas verificações envolve testar se os servidores de e-mail listados nos MXregistros de um domínio oferecem suporte a TLS. Estou descobrindo que, em muitas situações, os nomes de host listados no registro MX de um domínio não correspondem aos CNvalores de nomes alternativos do certificado usado por esse servidor. Isso faz com que as conexões TLS com esses hosts falhem devido à incompatibilidade do nome do host.

Por exemplo, os registros MX para gmail.comsão:

gmail.com.              1550    IN      MX      20 alt2.gmail-smtp-in.l.google.com.
gmail.com.              1550    IN      MX      40 alt4.gmail-smtp-in.l.google.com.
gmail.com.              1550    IN      MX      10 alt1.gmail-smtp-in.l.google.com.
gmail.com.              1550    IN      MX      5 gmail-smtp-in.l.google.com.
gmail.com.              1550    IN      MX      30 alt3.gmail-smtp-in.l.google.com.

No entanto, uma rápida inspeção do certificado gmail-smtp-in.l.google.commostra que o CN do certificado oferecido por esse host é mx.google.com. Como posso explicar isso? Os clientes de e-mail estão simplesmente ignorando a correspondência de nomes de host nos servidores MX? Isso parece loucura!

openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp
CONNECTED(00000003)
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify return:1
depth=1 C = US, O = Google Trust Services, CN = WR2
verify return:1
depth=0 CN = mx.google.com
verify return:1
---
Certificate chain
 0 s:CN = mx.google.com
   i:C = US, O = Google Trust Services, CN = WR2
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jun 24 07:37:53 2024 GMT; NotAfter: Sep 16 07:37:52 2024 GMT
 1 s:C = US, O = Google Trust Services, CN = WR2
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Dec 13 09:00:00 2023 GMT; NotAfter: Feb 20 14:00:00 2029 GMT
 2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jun 19 00:00:42 2020 GMT; NotAfter: Jan 28 00:00:42 2028 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGwjCCBaqgAwIBAgIQZZLFVIncLgcKOAT21sXTxzANBgkqhkiG9w0BAQsFADA7
MQswCQYDVQQGEwJVUzEeMBwGA1UEChMVR29vZ2xlIFRydXN0IFNlcnZpY2VzMQww
CgYDVQQDEwNXUjIwHhcNMjQwNjI0MDczNzUzWhcNMjQwOTE2MDczNzUyWjAYMRYw
FAYDVQQDEw1teC5nb29nbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE
EPY8iG+t2yuh+G2C7yURtlapDVtP5VYg0EifYWjDqqP0wUDTG82xOglMV1f5KGEy
B2L1MQVnrBxS7jgN72+tS6OCBK4wggSqMA4GA1UdDwEB/wQEAwIHgDATBgNVHSUE
DDAKBggrBgEFBQcDATAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBRiyEisYHpKSLmB
lAKrUL9Fess8uDAfBgNVHSMEGDAWgBTeGx7teRXUPjckwyG77DQ5bUKyMDBYBggr
BgEFBQcBAQRMMEowIQYIKwYBBQUHMAGGFWh0dHA6Ly9vLnBraS5nb29nL3dyMjAl
BggrBgEFBQcwAoYZaHR0cDovL2kucGtpLmdvb2cvd3IyLmNydDCCAoYGA1UdEQSC
An0wggJ5gg1teC5nb29nbGUuY29tgg9zbXRwLmdvb2dsZS5jb22CEmFzcG14Lmwu
Z29vZ2xlLmNvbYIXYWx0MS5hc3BteC5sLmdvb2dsZS5jb22CF2FsdDIuYXNwbXgu
bC5nb29nbGUuY29tghdhbHQzLmFzcG14LmwuZ29vZ2xlLmNvbYIXYWx0NC5hc3Bt
eC5sLmdvb2dsZS5jb22CGmdtYWlsLXNtdHAtaW4ubC5nb29nbGUuY29tgh9hbHQx
LmdtYWlsLXNtdHAtaW4ubC5nb29nbGUuY29tgh9hbHQyLmdtYWlsLXNtdHAtaW4u
bC5nb29nbGUuY29tgh9hbHQzLmdtYWlsLXNtdHAtaW4ubC5nb29nbGUuY29tgh9h
bHQ0LmdtYWlsLXNtdHAtaW4ubC5nb29nbGUuY29tghhnbXItc210cC1pbi5sLmdv
b2dsZS5jb22CHWFsdDEuZ21yLXNtdHAtaW4ubC5nb29nbGUuY29tgh1hbHQyLmdt
ci1zbXRwLWluLmwuZ29vZ2xlLmNvbYIdYWx0My5nbXItc210cC1pbi5sLmdvb2ds
ZS5jb22CHWFsdDQuZ21yLXNtdHAtaW4ubC5nb29nbGUuY29tgg1teDEuc210cC5n
b29ngg1teDIuc210cC5nb29ngg1teDMuc210cC5nb29ngg1teDQuc210cC5nb29n
ghVhc3BteDIuZ29vZ2xlbWFpbC5jb22CFWFzcG14My5nb29nbGVtYWlsLmNvbYIV
YXNwbXg0Lmdvb2dsZW1haWwuY29tghVhc3BteDUuZ29vZ2xlbWFpbC5jb22CEWdt
ci1teC5nb29nbGUuY29tMBMGA1UdIAQMMAowCAYGZ4EMAQIBMDYGA1UdHwQvMC0w
K6ApoCeGJWh0dHA6Ly9jLnBraS5nb29nL3dyMi85VVZiTjB3NUU2WS5jcmwwggEC
BgorBgEEAdZ5AgQCBIHzBIHwAO4AdQDuzdBk1dsazsVct520zROiModGfLzs3sNR
SFlGcR+1mwAAAZBJZQCtAAAEAwBGMEQCIEpVY7zgwrSNfBuWwgIeM0tTPxSQ6Swm
9x8o0wspJLNUAiA+16PpwOPDzPyvS1hBoRfFLD+11s2cKbxY3OXAma3wWQB1ANq2
v2s/tbYin5vCu1xr6HCRcWy7UYSFNL2kPTBI1/urAAABkEllANgAAAQDAEYwRAIg
bUppm6ugUYNlSakwgDF9/iV4yLTfd1gL53XsQOtEfewCIFNMdgwPXxIozNmwgEvT
TDbyFlh6OHe6mTmivcTzICK3MA0GCSqGSIb3DQEBCwUAA4IBAQBMvON+VaXWy4yH
ruDpCBvW2EO9sdVvefqPJHgda2yGqyRq1BQmnhLaIQhaJpEsdhrl/spLykOkZo8o
3R4W1dq24zXwNq0Qv1ThuH+WA8wr8tiZwd4yIDSqahsAtJm2K31logFAuDX771LB
MmtOZbkiDk9Ist2pmGRTP0Z7VpJy12aG/hUoeqcN1FmrWCNKG7ycMIVrairGrI4A
8wa5dUpDwezKaP3V3U8o9btRcuRD8doKFTPhzas+d1EZ1mtS/m9nKR1ssGfjtKFX
7zyNb+OoZOES1JpEjke3vc1iwkri+PkG+KuREsvFvb0sK6X6Gq0xE8EF25765UGz
vuIwywDO
-----END CERTIFICATE-----
subject=CN = mx.google.com
issuer=C = US, O = Google Trust Services, CN = WR2
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 5003 bytes and written 441 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

Iniciamos o sshd usando xinetd em nosso gateway. Aqui está o arquivo de configuração do xinetd:

service ssh
{
    instances       = 10
    socket_type     = stream
    wait            = no
    user            = root
    protocol        = tcp
    server          = /usr/local/sbin/sshd
    server_args     = -i
    disable         = no
}

Aqui está a versão do OpenSSH do comando ssh -V no gateway:

OpenSSH_9.8p1, OpenSSL 3.0.14 4 Jun 2024

Aqui está a versão em execução na minha VM Fedora 37:

OpenSSH_8.8p1, OpenSSL 3.0.9 30 May 2023

Se eu tentar fazer ssh no gateway a partir da minha VM Fedora 37, recebo o erro "sshd requer execução com um caminho absoluto":

$ ssh -vvv foo@g5-5
OpenSSH_8.8p1, OpenSSL 3.0.9 30 May 2023
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 58: Including file /etc/ssh/ssh_config.d/50-redhat.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug2: checking match for 'final all' host g5-5 originally g5-5
debug3: /etc/ssh/ssh_config.d/50-redhat.conf line 3: not matched 'final'
debug2: match not found
debug3: /etc/ssh/ssh_config.d/50-redhat.conf line 5: Including file /etc/crypto-policies/back-ends/openssh.config depth 1 (parse only)
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug3: gss kex names ok: [gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group14-sha256-,gss-group16-sha512-]
debug3: kex names ok: [curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512]
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 58: Including file /etc/ssh/ssh_config.d/50-redhat.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug2: checking match for 'final all' host g5-5 originally g5-5
debug3: /etc/ssh/ssh_config.d/50-redhat.conf line 3: matched 'final'
debug2: match found
debug3: /etc/ssh/ssh_config.d/50-redhat.conf line 5: Including file /etc/crypto-policies/back-ends/openssh.config depth 1
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug3: gss kex names ok: [gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group14-sha256-,gss-group16-sha512-]
debug3: kex names ok: [curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512]
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/xxxx/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/xxxx/.ssh/known_hosts2'
debug2: resolving "g5-5" port 22
debug3: resolve_host: lookup g5-5:22
debug3: ssh_connect_direct: entering
debug1: Connecting to g5-5 [x.x.x.x] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug1: Connection established.
debug1: identity file /home/xxxx/.ssh/id_rsa type -1
debug1: identity file /home/xxxx/.ssh/id_rsa-cert type -1
debug1: identity file /home/xxxx/.ssh/id_dsa type -1
debug1: identity file /home/xxxx/.ssh/id_dsa-cert type -1
debug1: identity file /home/xxxx/.ssh/id_ecdsa type -1
debug1: identity file /home/xxxx/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/xxxx/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/xxxx/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/xxxx/.ssh/id_ed25519 type -1
debug1: identity file /home/xxxx/.ssh/id_ed25519-cert type -1
debug1: identity file /home/xxxx/.ssh/id_ed25519_sk type -1
debug1: identity file /home/xxxx/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/xxxx/.ssh/id_xmss type -1
debug1: identity file /home/xxxx/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.8
debug1: kex_exchange_identification: banner line 0: sshd requires execution with an absolute path
kex_exchange_identification: read: Connection reset by peer
Connection reset by x.x.x.x port 22

Não recebo esse erro se o OpenSSH 9.7p1 estiver em execução no gateway e eu conseguir fazer login com sucesso.

Dei uma olhada no código em sshd.c no github: https://github.com/openssh/openssh-portable

É possível que o erro que estou recebendo seja devido à não verificação do inetd_flag na linha 1344? O código sshd.c em 9.7.p1 parece verificar o inetd_flag indiretamente.

Ou é alguma configuração nova ou adicional com relação à inicialização do 9.8p1 ​​sshd a partir do xinetd?

Portanto, tenho um servidor RHEL que pretendo usar para monitoramento de instalações. Possui 2 interfaces de rede em sub-redes diferentes. Por uma questão de brevidade, estes seriam o resultado de um 'ifconfig' e vou chamá-los:

• eno2: 11.11.11.11/24 (DHCP, sub-rede da Internet)
• eno3: 22.22.22.22/24 (STATIC, sub-rede de infraestrutura)

Agora meu problema é o seguinte: No próprio servidor eu posso fazer ping na internet (8.8.8.8) e posso fazer ping em dispositivos na sub-rede de infraestrutura (22.22.22.201) com a interface correta sendo usada para ambos (eno2 para 8.8.8.8 e eno3 para 22.22.22.201). por exemplo

$ip route get 8.8.8.8
> 8.8.8.8 via 11.11.11.0 dev eno2 src 11.11.11.11 uid 0

$ip route get 22.22.22.201
> 22.22.22.201 dev eno3 src 22.22.22.22 uid 0

Do meu computador do escritório (ou seja, remoto), também posso acessar dispositivos em ambas as sub-redes, mas não consigo acessar o servidor em seu próprio endereço IP (nem 11.11.11.11 nem 22.22.22.22), a menos que eu desligue uma ou outra interface.

Então, do meu controle remoto (PC do escritório), meu ping para o servidor é o seguinte:

# Both eno2 and eno3 active on server
ping 11.11.11.11 -t              ping 22.22.22.22 -t
Request timed out                Request timed out
Request timed out                Request timed out
Request timed out                Request timed out
...
# Turn off eno3
Reply from 11.11.11.11: bytes=32 Request timed out
Reply from 11.11.11.11: bytes=32 Request timed out  
Reply from 11.11.11.11: bytes=32 Request timed out  
Reply from 11.11.11.11: bytes=32 Request timed out  
Reply from 11.11.11.11: bytes=32 Request timed out
...
# Turn on eno3 (both on again)
Request timed out                Request timed out
Request timed out                Request timed out
Request timed out                Request timed out
Request timed out                Request timed out    
...
# Turn off eno2 
Request timed out                Reply from 22.22.22.22: bytes=32
Request timed out                Reply from 22.22.22.22: bytes=32
Request timed out                Reply from 22.22.22.22: bytes=32
Request timed out                Reply from 22.22.22.22: bytes=32
Request timed out                Reply from 22.22.22.22: bytes=32

Este NÃO é um problema de firewall, pois o mesmo acontece com meu firewall desativado:

$firewall-cmd --state
>not running

Os mesmos sintomas foram relatados aqui em um fórum RHEL Quando o RHEL tem vários IPs configurados, apenas um é acessível a partir de uma rede remota, então implementei a solução definindo rp_filter como 2 e as interfaces individuais como 0 (sem segurança) . O resultado do meu rp_filter para cada interface é o seguinte:

#sysctl -a 2>/dev/null | grep "\.rp_filter"
>
net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.eno2.rp_filter = 0
net.ipv4.conf.eno3.rp_filter = 0

A saída das minhas regras e tabela de interface é a seguinte:

# ip -4 -br a ls
>
lo               UNKNOWN        127.0.0.1/8 
eno3             UP             22.22.22.22/24 
eno2             UP             11.11.11.11/24 

Regras de IP

# ip ru ls
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

Tabela IP

# ip -4 r ls table all
default via 11.11.11.1 dev eno2 proto dhcp src 11.11.11.11 metric 100 
default via 22.22.22.1 dev eno3 proto static metric 101 
22.22.22.0/24 dev eno3 proto kernel scope link src 22.22.22.22 metric 101 
11.11.11.0/24 dev eno2 proto kernel scope link src 11.11.11.11 metric 100 
169.254.0.0/16 dev eno3 scope link metric 1000 
local 22.22.22.22 dev eno3 table local proto kernel scope host src 22.22.22.22 
broadcast 22.22.22.255 dev eno3 table local proto kernel scope link src 22.22.22.22 
local 11.11.11.11 dev eno2 table local proto kernel scope host src 11.11.11.11 
broadcast 11.11.11.255 dev eno2 table local proto kernel scope link src 11.11.11.11 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1

E route -n para um resumo da saída acima:

root@APPSVR:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         11.11.11.1      0.0.0.0         UG    100    0        0 eno2
0.0.0.0         22.22.22.1      0.0.0.0         UG    101    0        0 eno3
22.22.22.0      0.0.0.0         255.255.255.0   U     101    0        0 eno3
11.11.11.0      0.0.0.0         255.255.255.0   U     100    0        0 eno2
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eno3

No entanto, o mesmo problema persiste e não consigo acessar nenhuma das interfaces se ambas estiverem ativas.

Também tornei essas alterações persistentes, gravando-as nos arquivos de configuração relevantes (não me lembro exatamente onde) e sim, reiniciei o servidor.

Qualquer ajuda ou sugestão alternativa seria muito apreciada. Passei cerca de 3 dias preso neste problema agora. Desde já, obrigado!

Temos servidor1 e servidor2

• no servidor2, um servidor proxy Socks5 está instalado e escuta na porta TCP 1080

• no server2 está instalado um servidor openvpn que escuta na porta TCP 1194

• server1 está conectado ao proxy Socks5 (no server2) e escuta na porta local 1070.

É possível fazer isso usando socat?:

Queremos encaminhar qualquer pacote enviado da porta 9090 do servidor1 para a porta 1194 do servidor2 usando o túnel meias5. ou seja, se alterarmos nosso arquivo de configuração openvpn e substituirmos o IP do servidor2 pelo IP do servidor1 e a porta 1194 por 9090. a conexão será encaminhada.

Se o tipo de proxy no server2 for HTTP quando esta resposta do chatgpt funcionar bem (precisamos executar apt install corkscrewprimeiro):

basta executar isso no server1:

socat TCP4-LISTEN:9090,reuseaddr,fork EXEC:'corkscrew 127.0.0.1 1070

Mas qual é a resposta para o proxy Socks5?

Estou usando o certbot, no Ubuntu 22, para gerar certificado SSL. Tudo funciona bem, mas todos os certificados são gerados na seguinte pasta

/etc/letsencrypt/live/domain/cert.pem

O problema é que o usuário e o grupo são root. Se eu tentar usar um certificado para configurar o postgres para usar SSL, recebo um erro de permissão negada.

Eu evitaria copiar o certificado em outro diretório toda vez que fosse gerado. Existe uma maneira de alterar o grupo para gerar o certificado?

Atenciosamente

Estou testando o Keycloak e queria integrá-lo ao OpenShift. Estou seguindo estas instruções

Cheguei onde você configura o escopo do cliente e o keycloak morre imediatamente com:

Instalação padrão, isso é tudo que fiz. Atualizar não faz nada. Para reproduzir basta ir em:

Clientes -> openshift (o nome do meu cliente) -> Escopos do cliente. Quando verifico os logs, vejo:

2024-07-15 19:32:02,456 ERROR [org.keycloak.storage.ldap.idm.store.ldap.LDAPOperationManager] (executor-thread-27) Could not query server using DN [OU=Users,DC=openshift,DC=lan] and filter [(&(objectclass=person)(objectclass=organizationalPerson)(objectclass=user))]: javax.naming.NameNotFoundException: [LDAP: error code 32 - 0000208D: NameErr: DSID-0310028D, problem 2001 (NO_OBJECT), data 0, best match of:
        'DC=openshift,DC=lan'
]; remaining name 'OU=Users,DC=openshift,DC=lan'
        at java.naming/com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3285)
        at java.naming/com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3206)
        at java.naming/com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2997)
        at java.naming/com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1876)
        at java.naming/com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1799)
        at java.naming/com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392)
        at java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358)
        at java.naming/javax.naming.directory.InitialDirContext.search(InitialDirContext.java:359)
        at org.keycloak.storage.ldap.idm.store.ldap.LDAPOperationManager$3.execute(LDAPOperationManager.java:258)
        at org.keycloak.storage.ldap.idm.store.ldap.LDAPOperationManager$3.execute(LDAPOperationManager.java:255)
        at org.keycloak.storage.ldap.idm.store.ldap.LDAPOperationManager.execute(LDAPOperationManager.java:729)
        at org.keycloak.storage.ldap.idm.store.ldap.LDAPOperationManager.execute(LDAPOperationManager.java:709)
        at org.keycloak.storage.ldap.idm.store.ldap.LDAPOperationManager.execute(LDAPOperationManager.java:704)
        at org.keycloak.storage.ldap.idm.store.ldap.LDAPOperationManager.search(LDAPOperationManager.java:255)
        at org.keycloak.storage.ldap.idm.store.ldap.LDAPIdentityStore.fetchQueryResults(LDAPIdentityStore.java:278)
        at org.keycloak.storage.ldap.idm.query.internal.LDAPQuery.getResultList(LDAPQuery.java:174)
        at org.keycloak.storage.ldap.LDAPStorageProvider.paginatedSearchLDAP(LDAPStorageProvider.java:1123)
        at org.keycloak.storage.ldap.LDAPStorageProvider.searchLDAPByAttributes(LDAPStorageProvider.java:564)
        at org.keycloak.storage.ldap.LDAPStorageProvider.searchForUserStream(LDAPStorageProvider.java:379)
        at org.keycloak.storage.UserStorageManager.lambda$searchForUserStream$29(UserStorageManager.java:537)
        at org.keycloak.storage.UserStorageManager.lambda$query$13(UserStorageManager.java:331)
        at java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:273)
        at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
        at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
        at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
        at java.base/java.util.stream.SortedOps$RefSortingSink.end(SortedOps.java:395)
        at java.base/java.util.stream.Sink$ChainedReference.end(Sink.java:261)
        at java.base/java.util.stream.Sink$ChainedReference.end(Sink.java:261)
        at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:510)
        at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
        at java.base/java.util.stream.StreamSpliterators$WrappingSpliterator.forEachRemaining(StreamSpliterators.java:310)
        at java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:735)
        at java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734)
        at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
        at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
        at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
        at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
        at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
        at java.base/java.util.stream.ReferencePipeline.forEachOrdered(ReferencePipeline.java:601)
        at com.fasterxml.jackson.datatype.jdk8.StreamSerializer.serialize(StreamSerializer.java:71)
        at com.fasterxml.jackson.datatype.jdk8.StreamSerializer.serialize(StreamSerializer.java:15)
        at com.fasterxml.jackson.databind.ser.DefaultSerializerProvider._serialize(DefaultSerializerProvider.java:502)
        at com.fasterxml.jackson.databind.ser.DefaultSerializerProvider.serializeValue(DefaultSerializerProvider.java:341)
        at com.fasterxml.jackson.databind.ObjectWriter$Prefetch.serialize(ObjectWriter.java:1574)
        at com.fasterxml.jackson.databind.ObjectWriter._writeValueAndClose(ObjectWriter.java:1275)
        at com.fasterxml.jackson.databind.ObjectWriter.writeValue(ObjectWriter.java:1098)
        at io.quarkus.resteasy.reactive.jackson.runtime.serialisers.FullyFeaturedServerJacksonMessageBodyWriter.writeResponse(FullyFeaturedServerJacksonMessageBodyWriter.java:79)
        at org.jboss.resteasy.reactive.server.core.ServerSerialisers.invokeWriter(ServerSerialisers.java:216)
        at org.jboss.resteasy.reactive.server.core.ServerSerialisers.invokeWriter(ServerSerialisers.java:184)
        at org.jboss.resteasy.reactive.server.core.serialization.FixedEntityWriter.write(FixedEntityWriter.java:28)
        at org.jboss.resteasy.reactive.server.handlers.ResponseWriterHandler.handle(ResponseWriterHandler.java:34)
        at io.quarkus.resteasy.reactive.server.runtime.QuarkusResteasyReactiveRequestContext.invokeHandler(QuarkusResteasyReactiveRequestContext.java:147)
        at org.jboss.resteasy.reactive.common.core.AbstractResteasyReactiveContext.run(AbstractResteasyReactiveContext.java:147)
        at io.quarkus.vertx.core.runtime.VertxCoreRecorder$14.runWith(VertxCoreRecorder.java:582)
        at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2513)
        at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1538)
        at org.jboss.threads.DelegatingRunnable.run(DelegatingRunnable.java:29)
        at org.jboss.threads.ThreadLocalResettingRunnable.run(ThreadLocalResettingRunnable.java:29)
        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.base/java.lang.Thread.run(Thread.java:1583)

mas até onde eu sei, isso está correto com base na configuração do AD do meu laboratório:

Em seguida, uma verificação final de integridade na configuração do LDAP:

Não tenho certeza do que o Keycloak está procurando aqui. Tudo está configurado corretamente.

Em um laboratório, estou testando políticas DNS de horizonte dividido (também conhecido como cérebro dividido). As políticas definidas em um servidor DC/DNS não são replicadas para outros servidores DC/DNS.

É possível fazê-los replicar?

O laboratório possui sub-redes 192.168.72.0 e 192.168.73.0 e dois DCs executando DNS. Os dois DCs possuem endereços IP 192.168.72.100 e 192.168.73.100.

Criei um registro A no DNS do host1 em 10.0.0.2

Segui este tutorial da Microsoft the DC com IP 192.168.72.100. Os comandos específicos são colados abaixo:

Add-DnsServerZoneScope -ZoneName "deez.datz" -Name Scope73"
Add-DnsServerResourceRecord -ZoneName "deez.datz" -A -Name "host1" -IPv4Address "10.0.0.100" -ZoneScope "Scope73"
Add-DNsServerQueryResolutionPolicy -Name "Policy73" -Action ALLOW -ClientSubnet "eq,TGH-North" -ZoneScope "Scope73,1" -ZoneName "deez.datz"

Nslookup de um sistema na sub-rede 192.168.73.0:

nslookup host1 192.168.72.100
Name: host1.deez.datz
Address: 10.0.0.100
nslookup host1 192.168.73.100
Name: host1.deez.datz
Address: 10.0.0.2

A política DNS funciona corretamente no primeiro controlador de domínio onde os comandos foram executados. A política não entrou em vigor no segundo DC. A política não foi replicada.

Entendo que este é o comportamento padrão da Política DNS da Microsoft.

É possível forçar a replicação da política DNS (e evitar a execução dos comandos em cada controlador de domínio)?

Eu tenho dois HP ProLiant ML 350 GEN 10 com discos SSD Samsung RAID 10 e HPE SmartArray P408 com cache de 2 GB. Tem bom desempenho:

Ao copiar arquivos grandes, o desempenho cai após dois minutos...

De NIC de 10 GB a P408i: (de 900 MB/s a 50 MB/s):

Do disco NVME interno ao P408i: (de 900 MB/s a 40 MB/s):

Do SSD_AHCI interno ao P408i (de 550 MB/s a 36 MB/s)

Instalei SSD e NVMe PCI-E no servidor e não houve queda no desempenho.

DE NIC de 10 GB para NVME:

DE NIC de 10 GB para AHCI _SSD:

Tenho outro HP ProLiant ML350 GEN 10 com o mesmo controlador SmartArray, mesmo firmware, mesmo driver, mesma configuração de cache e não tenho esse problema.

Espero que alguém possa me ajudar!!

Sou um iniciante em PostgreSQL e estou seguindo uma introdução aos bancos de dados para configurar um banco de dados PostgreSQL local e conectar-me a ele. Estou executando o Debian 15, então faço o seguinte:

# apt update
# apt install postgresql

A instalação foi bem-sucedida. Eu então faço:

sudo -u postgres psql
psql (15.7 (Debian 15.7-0+deb12u1))
Type "help" for help.

postgres=# \l
postgres=# createdb prismatest
postgres-# \l
postgres-# \c prismatest
connection to server on socket "/var/run/postgresql/.s.PGSQL.5433" failed: FATAL:  database "prismatest" does not exist
Previous connection kept

Portanto, a lista de bancos de dados não mostra nada e não é possível conectar-se ao banco de dados - supostamente - recém-criado. Meu usuário tem os direitos:

postgres-# \du
                                   List of roles
 Role name |                         Attributes                         | Member of 
-----------+------------------------------------------------------------+-----------
 postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS | {}

Alguém pode me ajudar a descobrir o que está acontecendo? Obrigado...

Tenho a seguinte regra do iptables que encaminha todo o tráfego de entrada para um ip na rede local10.8.0.2

sudo iptables -t nat -A PREROUTING -d 172.31.44.186 -j DNAT --to-destination 10.8.0.2

existe uma maneira de excluir o 27encaminhamento da porta? (ou forçá-lo a ser "encaminhado" para 127.0.0.1)