Hagen von Eitzen's questions

Eu tenho um servidor Windows e até agora compartilhei uma pasta D:\AAAcomo "ShareRW" com permissões de compartilhamento completas ("Todos - Completo") e algumas permissões NTFS mais rígidas conforme necessário e abaixo dessa pasta; por exemplo, UserX tem acesso total a D:\AAA\BBB, acesso de leitura D:\AAA\CCCe não pode nem ver D:\AAA\DDD(porque tem herança desabilitada e direitos explícitos apenas para outros usuários). Verifiquei no servidor se os direitos efetivos do UserX são de fato os desejados.

Agora eu queria adicionar a opção de "montar -r" o mesmo conteúdo e, portanto, criei um segundo compartilhamento com um nome diferente "ShareRO" na mesma pasta e com apenas as permissões "Todos - Ler" (e claro com o mesmo antigo permissões NTFS).

Agora meu UserX faz ambos NET USE W: \\server\ShareRWe NET USE R: \\server\ShareRO. Eu esperava que R: fosse igual a W:, exceto que escrever/alterar não é permitido. Mas a realidade implorou para ser diferente:

• O usuário pode alterar coisas W:\BBB, pode ler coisas W:\CCCe nem vê que W:\DDDexiste
• O usuário pode ler coisas em R:\BBB, pode ler coisas em R:\CCC, mas vê que R:\DDDexiste e alguns metadados (tamanho, data de criação) , embora não possa abri-lo.

O que eu estou fazendo errado aqui?

Eu gerencio vários servidores DHCP baseados em Windows 2012 e em um deles me deparei com uma peculiaridade que não consigo explicar e não sei onde corrigir:

No gerenciador de DHCP*, expanda [nome do servidor], depois IPv4, policies(ou [rede], depois policies). Crie uma nova ou edite uma política existente e na conditionsguia, adicione ou edite uma condição.

O comportamento esperado é que você seja apresentado a uma caixa de diálogo onde você pode escolher

• um critério ( vendor class, user class, MAC address, etc.)
• um operador ( equals, not equals)
• um valuecampo**
• uma prepend wildcardcaixa de seleção**
• uma append wildcardcaixa de seleção**

Pelo menos este é o caso da maioria dos meus servidores. Em um único servidor, no entanto, a caixa de seleção "prepend wildcard" está sempre desabilitada:

P: Como assim? O que isso significa? Existe algum problema ou configuração incorreta? Claro, que eu saiba, todos os servidores são (ou deveriam ser) praticamente idênticos no que diz respeito a atualizações e configurações ...

* Todas as opções, rótulos de diálogo etc. são traduzidos de volta da versão em alemão, portanto, desculpe se não houver uma correspondência perfeita com a versão em inglês

** O formulário tem campos diferentes ao escolher relay agent infocomo critério, mas isso é irrelevante para esta questão

Em um Apache 2 vhost tenho a seguinte configuração (no meu caso, na .htaccessraiz do documento (que é para simplificar o mesmo para http:80 e https:443)

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

para redirecionar quaisquer conexões http para https Além disso,

ErrorDocument 500 /error.php
ErrorDocument 404 /error.php
ErrorDocument 403 /error.php
ErrorDocument 402 /error.php
ErrorDocument 401 /error.php

para produzir mensagens de erro personalizadas. O terceiro ingrediente é uma subpasta protegida com autenticação necessária (por .htaccessnessa pasta):

AuthType Basic
AuthName "Test"
AuthUserFile  /some/path/to/passwords
Require user joe

Tudo funciona bem, exceto quando alguém tenta recuperar http://example.com/protectedfolderNa verdade, o que acontece é que o cliente recebe uma 302 Foundresposta com redirecionamento parahttps://example.com/error.php

Por outro lado,

• https://example.com/protectedfolderleva a um custom (ou seja, produzido por error.php) 401conforme o esperado.
• http://example.com/publicfolderleva a 302redirecionar para https://example.com/publicfolder, em seguida, um 301redirecionamento permanente para https://example.com/publicfolder/, e finalmente (como DirectoryIndex está desabilitado) um 403erro personalizado. Como esperado.
• Além disso, http://example.com/nonexistentcausa um 302to https://example.com/nonexistente, em seguida, um customizado 404, também conforme o esperado.
• Se eu desabilitar a ErrorDocument 401configuração, uma consulta de http://example.com/protectedfoldercausas 401imediatamente, ou seja, sem redirecionamento para https.

Não há uma entrada específica no Apache error.log, mas parece que o problema ocorre porque o requisito Auth é avaliado antes do Rewrite, assim invoca o ErrorDocument e que erroneamente ainda é http??

O que eu preciso mudar para ter o efeito desejado, ou seja, que http://example.com/protectedfoldercausa um redirecionamento para https://example.com/protectedfoldere somente essa URL redirecionada causa um (personalizado) 401?

Eu tenho um controlador de domínio somente leitura Windwos 2012 R2 em um site remoto. Embora eu suponha que tudo esteja configurado corretamente, ele continua pensando que está em uma rede pública. Eu verifiquei a questão relacionada O controlador de domínio acha que está em uma rede pública, mas isso não me ajudou.

• desconectei e reconectei o cabo - sem sucesso
• serviço NLA reiniciado - sem sucesso
• IPv6 desativado (e reiniciado o NLA novamente) - sem sucesso
• tentou IPCONFIG /RENEW - sem sucesso (o ip é corrigido de qualquer maneira)
• reiniciado - sem sucesso

Existem dois NICs fisicamente, mas um está desativado. O outro tem um endereço fixo 10.0.50.3/24, gateway 10.0.50.1, conectividade ip para o site principal é funcional. A rede 10.0.50.0/24 existe em AD Sites and Services (também ao verificar isso no próprio RODC) e está atribuída ao site correto.

A menos que eu aprenda outra ideia aqui, estou perto de assumir que isso é uma falha de design do conceito de RODC e que devo promover (em vez disso: reinstalar a função) essa caixa para um RWDC ...

Estou jogando com o servidor DHCP do Windows 2012 para IPv6. Assim como no IPv4, as interfaces de rede do cliente podem ser configuradas para obter um endereço IPv6 automaticamente ou usar um endereço configurado estaticamente.

No entanto, o que observo é que mesmo para aqueles hosts onde configurei um endereço IPv6 estático, eles adquirem adicionalmente um endereço DHCP. Este é o caso do próprio servidor DHCP!

Por quê?

Um farm de servidores de área de trabalho remota que funcionava bem parou de funcionar há dois dias. A configuração é a seguinte:

• O DNS resolve "myfarm.mydomain.local" para os IPs de todos os servidores membros do farm
• Todos os servidores membros do farm são configurados como membros do farm "myfarm" no Broker MYBROKER
• Todos os membros do farm são membros do grupo de corretores de sessão local no MYBROKER
• Os clientes são configurados para se conectar a "myfarm"

(Todos os servidores envolvidos são caixas Windows2008R2 virtuais). De repente, as pessoas começaram a receber o seguinte erro (traduzido do alemão) e não conseguiram se conectar.

Não é possível conectar ao servidor de terminal.

O farm de servidores de terminal "myfarm" ao qual você está tentando se conectar está redirecionando você para o servidor "farmmemberX.mydomain.local". A área de trabalho remota não pode verificar se este servidor pertence ao mesmo farm de servidores. Isso pode ocorrer se houver um servidor em sua rede com o mesmo nome do farm de servidores. ?Não pode ser verificado se ambos os computadores remotos pertencem ao mesmo farm de servidores de área de trabalho remota. Você deve usar o nome do farm, não o nome do computador, se quiser fazer uma conexão com um farm de servidores de área de trabalho remota.

Entre em contato com um administrador de rede para obter suporte se você usar uma conexão RDP preparada pelo administrador.

Se você deseja se conectar com um membro específico do farm, use "mstsc /admin"

Às vezes, parecia também que eles foram simplesmente rejeitados como se tivessem inserido credenciais erradas (o que eles não fizeram, a maioria salvou suas credenciais)

Questão 1. Você pode explicar o que está por trás disso, especificamente em relação ao "não pôde ser verificado": Como ocorre essa verificação se funciona? Afinal, o redirecionamento nem seria tentado se não fosse iniciado pela corretora...

O que tentamos: às vezes, ajudava substituir o nome ao qual o cliente se conecta por outra coisa (ou seja, adicionamos um nome "foo" ao DNS que resolvia para os mesmos IPs e fazia com que os usuários se conectassem a "foo"), mas isso estava longe de consistente.

Mais tarde, notamos que sempre os mesmos poucos servidores apareciam como "farmmemberX" na mensagem de erro acima. Nós os removemos experimentalmente do farm (nos próprios membros e no DNS) e assim conseguimos reduzir o farm quebrado de oito servidores para um farm funcional de dois servidores. Como isso não seria suficiente para reduzir a carga do usuário, eu queria clonar um deles; para fazer isso, primeiro desliguei e depois reiniciei - a partir do momento em que ficou tão ruim quanto os outros seis servidores. Aparentemente , reiniciar os servidores RDP foi a coisa fatal a se fazer ... De acordo com os logs, esse servidor em particular não foi reiniciado por cerca de dois meses. Portanto, praticamente qualquer mudança feita nos últimos dois meses pode ser relevante. Entre estes estão

• Adicionamos nosso primeiro servidor Win2012 AD em nossa estrutura Win2003 AD
• Lembro que houve alguns casos de problemas de segurança relacionados ao IE10/SSL/TLS que exigiriam intervenção manual (regedit e outras coisas), mas ainda estou tentando lembrar o que poderia ter sido
• Toneladas de atualizações do Windows
• Coisas como certificados invalidados vieram à minha mente, mas não encontrei nada disso

Pergunta 2. Alguma dessas coisas pode causar esse problema?

Atualmente, abandonamos completamente o farm de servidores, ou seja, temos apenas "balanceamento de carga do pobre homem" via DNS round robin (e sentimos especialmente falta do recurso de reconectar à sessão anterior, é claro)

Questão principal. Como posso colocar minha fazenda em condição de trabalho novamente?

EDIT: Eu deveria ter mencionado que alguns clientes tiveram sorte e não tiveram problemas com o farm RDP: aqueles que ainda estavam executando o Windows XP e seu cliente RDP mais antigo ...

EDITAR após o comentário: Parece que as principais atualizações culpadas KB3002657, KB3035017 não foram instaladas ou foram instaladas dias antes do início do problema nos servidores relevantes (clientes, servidores RDP, corretor, DCs), mas tentarei desinstalar eles de qualquer maneira...

ATUALIZAÇÃO Mais algumas informações:

• Melhorei o registro de eventos no corretor. De acordo com esse log, está tudo bem (sem aviso) e o redirecionamento da sessão é concluído normalmente. Acontece que, após um tempo limite, a sessão de destino é removida. Tentei (falhei) em conexões rápidas e nesse caso, a corretora até registrou que tentou reaproveitar uma sessão existente.
• Se o servidor RDP de destino estiver definido como "RDP-Sercurity" em vez de "negotiate", o redirecionamento funcionará (exceto que as mensagens de erro irritantes esperadas ocorrem no cliente)
• Eu tentei um farm completamente novo (ou seja, um corretor diferente com hosts diferentes) e o problema também pode ser reproduzido neste sistema. Isso pode sugerir que o problema está no lado do cliente.

ATUALIZAÇÃO com informações conforme solicitado por comentários

Se eu definir a segurança como "TLS 1.0" (em vez de "negociar") nos hosts RDP, o problema persistirá. Se eu definir como "RDP", o farm funcionará - mas todos terão que digitar sua senha duas vezes. Na situação de erro, por algum motivo, agora recebo simplesmente "Nenhuma conexão pôde ser estabelecida com as credenciais fornecidas" em vez do erro original. Isso é acompanhado por um evento de falha de login 4625 com status 0xc000006d, substatus 0. Antes que você pergunte: Todos os controladores de domínio têm seus relógios em boa sincronização; nenhuma configuração de compatibilidade LanMan foi definida no registro.

Os certificados nas configurações do cliente host RDP que funcionaram foram emitidos pela CA interna ainda confiável (confiável por todos de acordo com o GPO) e válidos até pelo menos quatro meses no futuro. Para testar, alterei-os para certificados "automáticos" e voltei, sem sucesso.

O texto original da mensagem de erro em alemão diz

Von Remotedesktopverbindung cann keine Verbindung mit dem Remotecomputer hergestellt werden.

Vom Remotecomputer "FARMNAME", mit dem Sie eine Verbindung herstellen möchten, werden Sie zum Remotecomputer "FARMMEMBER.DOMAIN" umgeleitet. Es kann nicht überprüft werden, ob diebeiden Remotecomputer zur gleichen Remotedesktop-Sitzungshostserverfarm gehören. Você pode usar o Farmnamen, ou o nome do computador, verificar se você deseja conectar um servidor remoto à área de trabalho remota.

Quando você for um administrador de rede, um administrador de rede, quando você tiver uma verificação RDP, o administrador será informado.

Wenn Sie eine Verbindung mit einem bestimmten Herstellen möchten, um es zu verwalten, geben Sie "mstsc.exe /admin" an der Eingabeaufforderung ein.

Para descobrir se alguma atualização recente do lado do cliente está com defeito, comecei com uma nova caixa do Windows 7 e testei após cada grupo de atualizações. Parece que a introdução do primeiro cliente melhor que o XP já causa problemas agora - mas as primeiras versões desse cliente fornecem uma mensagem de erro diferente (não que isso faça sentido):

Die Verbindung kann nicht hergestellt werden, da es sich bei dem erreichten Remotecomputer nicht um den angegebenen Computer handelt. Dies kann durch einen veralteten Eintrag im DNS-Cache verursacht werden. Verwenden Sie statt des Namens die IP-Adresse es Computers.

Um subdiretório /var/www/vhost/servername/httpdocs/subdir/de um apache (ver. 2.2.22 no Ubuntu 12.04) vhost webroot é uma partição de disco própria. Consequentemente, há também /var/www/vhost/servername/httpdocs/subdir/lost+found. Em meus logs de erro do apache, encontro erros que /var/www/vhost/servername/httpdocs/subdir/lost+found/.htaccessnão podem ser lidos, com um referenciador como /var/www/vhost/servername/httpdocs/subdir/foo/(ou seja, quando um FancyIndexingíndice de diretório desse diretório é exibido para o usuário).

[Fri Nov 28 09:14:19 2014] [crit] [client 10.0.0.1] (13) Permissão negada: /var/www/vhost/servername/httpdocs/subdir/lost+found/.htaccess pcfg_openfile: incapaz de verificar htaccess, certifique-se de que seja legível, referencie:http://servername/subdir/foo/

Eu não consigo entender isso. Por que o apache tentaria ler

• /var/www/vhost/servername/httpdocs/subdir/lost+found/.htaccess

naquela ocasião? No meu entendimento só deveria ter motivos para tentar ler

• /var/www/vhost/servername/httpdocs/subdir/foo/.htaccess
• /var/www/vhost/servername/httpdocs/subdir/.htaccess
• /var/www/vhost/servername/httpdocs/.htaccess

Curiosamente, nenhuma mensagem de erro correspondente ocorre com subdiretórios mais profundos (por exemplo http://servername/subdir/foo/bar/baz/, ).

O que causa esse erro (ou a tentativa de leitura em primeiro lugar)? E como posso me livrar disso?