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.
Caros amigos e leitores,
Sou especialista em sistemas Microsoft Server e segurança, como tal sempre fui um fervoroso da utilização de “Windows Integrated Authentication” no acesso a recursos Microsoft, porque só assim temos uma maneira fiável e segura de auditar, filtrar e nos ligar-mos a esses sistemas.
Sempre aconselhei (leia-se obriguei) o uso deste tipo de acesso a consultores externos de sistemas Microsoft que estão sobre a minha gestão quer directa quer indirectamente (infelizmente nem sempre com sucesso). E para tal eu usava e ensinava o procedimento de criar um utilizador local com o mesmo nome e credenciais que o utilizador a utilizar no domínio do recurso e depois abrir a aplicação pretendida em modo RunAS (a partir do Windows XP+) ou usando a extensão do explorer “Run as different user”, desse modo as credenciais impersonalizadas eram passadas para o sistema que estava nesse outro domínio e sem que o sistema de onde era feita essa chamada tivesse que estar no mesmo domínio do recurso a aceder.
Procedimento este que era, do meu ponto de vista, fulcral para tentar minimizar (por exemplo) o tão usado acesso SQL em “Mixed Mode“ que a Microsoft desde a versão SQL 2000 SP3 (+-) tão fervorosamente indica ser DESACONSELHADO e futuramente descontinuado.
“usar um utilizador e pwd local com as mesmas credenciais que o user de domínio funcionava (ex: aceder ao SQL 2000 usando um utilizador dominioA\userA onde depois poderia ser feito um runas /user:UserA que existia na máquina local fora do domínio)” mas neste caso não:
YEP no luck, e do lado do recurso tenho o evento 4625 que me reporta que o sistema está também a validar o domínio da conta de origem:
Comecei então na demanda de actualizar esta boa prática… tcham tcham tcham
Connecting To A Database Using Windows Authentication With Different Credentials Using SQL Server Management Studio
Quantos de vocês lêem o manual de instruções / help? RTFM :D
AAAAAAaaahhhhhh, OOOOOoooooohhhhh, viram a luz? então considerem-se a partir deste momento iluminados :D
Esperem só um momento que eu estou em acto de auto-flagelação por não ter tomado atenção a tão simples procedimento…
Bom e melhor do que tudo isto, uma vez mais Mark Russinovich (um verdadeiro GURU desta era tecnológica) e seus colegas nos apresentam mais um maravilhoso utilitário que nos facilita a vida. Apresento-vos (para quem não conhece):
ShellRunas v1.01 By Mark Russinovich and Jon Schwartz
Agora sim ficaram verdadeiramente ofuscados com tanta iluminação!!!! (ou será dos meus olhos?)
Para os incrédulos e agnósticos aqui vai um mero exercicio de POC :)
Nada na manga:
O mesmo se pode fazer com outros tipos de acessos, como gerir uma AD a partir de uma máquina que não está no domínio e sem recurso ao login interactivo no servidor usando Terminal Services / RDS (outra prática a evitar porque expõe um perfil com direitos elevados num servidor), etc…
E voilá, posto isto podem ter a certeza que o meu nível de “compliance” subiu consideravelmente :D
TECHNOTES:
Runas:
http://technet.microsoft.com/en-us/library/cc771525(WS.10).aspxConnecting To A Database Using Windows Authentication With Different Credentials Using SQL Server Management Studio:
http://msmvps.com/blogs/paulomorgado/archive/2009/05/04/tip-connecting-to-a-database-using-windows-authentication-with-different-credentials-using-sql-server-management-studio.aspxShellRunas:
http://technet.microsoft.com/en-us/sysinternals/cc300361.aspx
Caros Amigos e leitores,
Como muitos de nós, fiquei habituado a ter o ícone do IE no meu desktop e aceder ás propriedades da internet a partir dai (outra possibilidade é ir pelo painel de controlo ou dentro do Browser depois de aberto).
Mas novos sistemas trazem novas maneiras de fazer as coisas (umas boas, outras nem por isso).
Por isso aqui vai para quem não sabe: no Windows 7 / Windows 2008 R2 server o ícone do IE deixou de ter a possibilidade de estar no Desktop (não pensem que o hack do registry resolve, porque não resolve)
Passo a palavra à Microsoft http://support.microsoft.com/kb/945402:
Important Windows 7 no longer supports the ability to modify the registry to get the special Internet Explorer icon to appear on your desktop. This change was made to ensure Internet Explorer could be removed easily for compliance reasons. The only way to add the Internet Explorer icon to the desktop in Windows 7 is to create a shortcut as shown in Method 1.
COMPLIANCE REASONS == os vários processos que a MSFT têm levado e perdido.
Passo a palavra aos foruns do Windows 7 http://www.sevenforums.com/tutorials/24072-internet-options-shortcut-create.html:
Information
This will show you how to create or download a Internet Options shortcut that opens directly to the Internet Properties page in Windows 7. You can also Pin to Taskbar or Pin to Start Menu this shortcut, or move where you like for easy use.
A frase mágica: “C:\Windows\System32\rundll32.exe shell32.dll,Control_RunDLL inetcpl.cpl,,4”
Resumindo e concluindo, está a funcionar como pretendido é o que interessa ;)
Divirtam-se
PS: Peço desculpa pelo atraso nos meus POSTS mas tenho tido muito pouco tempo.
![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]")
