Tínhamos a internet, as flores, os cofres, a nuvem, mas será que ainda ficará por cá alguém para usar isso tudo?
http://gizmodo.com/5863078/engineered-avian-flu-could-kill-half-the-worlds-humans?popular=true
Os artigos originais ;)
http://news.sciencemag.org/scienceinsider/2011/11/scientists-brace-for-media-storm.html
http://rt.com/news/bird-flu-killer-strain-119/
Afinal que somos nós?
Sat, 2010-12-11 23:57 — Christopher
Recently I ran across a scenario where the Microsoft Sysinternals tool PsExec would not work against a Windows 7 domain-joined computer. The command was failing with an "Access Denied" error. On Vista and newer, User Access Control (UAC) issues a restricted token to processes, but PsExec requires an elevated token. On the local system's Microsoft-Windows-UAC\Operational log the following event appeared: The process failed to handle ERROR_ELEVATION_REQUIRED during the creation of a child process.
Further research found that newer versions of PsExec have a command argument (-h) to specify elevated rights.
However, even with specifying -h PsExec was still failing with "Access Denied". After some digging, I discovered that it's all about how the authentication credentials are presented to the remote system. UAC has an exception for remote connections using domain credentials, so that machines can still be administrated remotely (otherwise, there would be no way to respond to UAC prompts). When connecting remotely and authenticating with NTLM using a domain account, Windows 7 issues an elevated token.
With PsExec when you specify the username on the command line it causes an explicit (local) authentication to occur on the remote system, and Windows issues a limited rights token, causing PsExec to fail. However, if you authenticate as the target user on the local computer (using RunAs or logging in directly), and then use PsExec with implicit (NTLM) authentication to the remote computer, the process gets the elevated token on the remote system and it works.
This behavior becomes more obvious when using telnet. The built-in Windows telnet client automatically authenticates using NTLM (top window in the screen shot below), and the user is given an elevated token. However, logging in with the same user from a third-party telnet client results in a restricted token (bottom window).
I hope this information is helpful to someone else wondering why their PsExec might be failing on Windows 7 due to UAC.
TECHNOTES:
Sysinternals: http://technet.microsoft.com/en-us/sysinternals
Technorati Tags: TECH PSEXEC UAC Elevation
a. Faz uma consulta DNS pelo MX Record do domínio destino da mensagem (neste caso por ex: @gmail.com)
b. Da resposta escolhe o registo que tiver menor preferência (neste caso será gmail-smtp-in.l.google.com )
c. Como neste caso não obtêm uma resposta IPv6, o MS Exchange 2010 volta a fazer a pergunta mas agora para IPv4
d. Sabendo o endereço IP onde se ligar, o sistema continua o processo ligando-se directamente ao IP em questão.
e. Podem perguntar, e se o MS Exchange 2010 estiver configurado apenas para ter IPv4 no seu sistema operativo? O procedimento é o mesmo a não ser que receba um MX com um registo que retorne um IPv6 que nesse caso tenta usar esse endereço (directo ou túnel IPv4 dependendo como está configurada a FW do sistema)
a. Os resultados do mesmo processo é o seguinte:
b. O sistema MS Exchange 2010 ao receber um DNS “timed out” vai abortar o processo e informar o operador de sistemas (Logs & Queue Viewer) que não consegue entregar a mensagem por problemas de DNS.
c. Mesmo que o passo seguinte (que o sistema não vai fazer) de consulta IPv4 do registo associado ao MX mais baixo retorne com sucesso ():
a. Criar conectores directos, para os domínios com este problema de DNS, por ex:
b. Este WORKAROUND têm o problema adicional que sendo uma configuração manual do lado da empresa responsável pela origem das mensagens, não reflecte futuras alterações DNS (MX) ao sistema destinatário de correio electrónico feito pelos administradores de sistemas do mesmo.
c. Se alguém tiver informação da causa técnica (Microsoft, DNS Servers por ex: bind, porque com o MS DNS 2003 ou superior não temos este problema (as únicas versões MS que testei)) por favor comentem, que eu não tive paciência para validar quem é o culpado.
![clip_image003[1]](http://lh5.ggpht.com/-XC2HEZXG-sE/TosrUWtcMpI/AAAAAAAAAKM/rFI5MLymlHc/s1600-h/clip_image003%25255B1%25255D%25255B3%25255D.png "clip_image003[1]")
![clip_image004[1]](http://lh6.ggpht.com/-SKt7c9ftzGw/TosrVbBZOII/AAAAAAAAAKU/Iqj52lGM2Yc/s1600-h/clip_image004%25255B1%25255D%25255B5%25255D.png "clip_image004[1]")
![clip_image005[1]](http://lh6.ggpht.com/-Jxupm2vzQZs/TosrWx1L1eI/AAAAAAAAAKg/s1uxE_1-sY0/s1600-h/clip_image005%25255B1%25255D%25255B3%25255D.png "clip_image005[1]")
![clip_image006[1]](http://lh6.ggpht.com/-jmEQhRLOSxg/TosrYTkZu7I/AAAAAAAAAKo/vUunW2wSclM/s1600-h/clip_image006%25255B1%25255D%25255B4%25255D.png "clip_image006[1]")
