This is default featured slide 1 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 2 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 3 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 4 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 5 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

segunda-feira, 28 de outubro de 2019

terça-feira, 15 de outubro de 2019

Windows - Automate Changing The Local Administrator Password

How To Automate Changing The Local Administrator Password


Hello again, Tom Ausburne with another post we think you’ll enjoy. With all of the security breaches we keep reading about on the Internet these days, I keep getting asked how to make servers and workstations less vulnerable to attack. The list of things you can do are extensive and more than I could ever cover in a single blog post. Today I decided to focus on one that is simple to implement, changing the local administrator’s password on a regular basis. If you only have one computer then this is an easy thing to do. But what about when you have thousands of servers and tens of thousands of workstations? Now we need a little bit of automation to keep things moving along smoothly.
The first thing that might come to mind is to use Group Policy Preferences. Because of the security concerns with storing passwords in Group Policy Preferences, Microsoft just released a security patch, MS14-025: Vulnerability in Group Policy Preferences could allow elevation of privilege, that removes this functionality. Once you apply this patch, this is no longer a usable option. Since some of you may be doing this already, I'll talk about this in a little detail and explain why we removed this.
1. Start the Group Policy snap-in.
2. Expand Computer Configuration
3. Expand Preferences
4. Click Control Panel
5. Right-click Local Users and Groups
6. From the menu select New – Local User.
7. Select Update as the action
8. Type Administrator into the User name text box
9. Type the new password into the Password text box, confirming the password in Confirm Password text box.
10. Press OK.
That was pretty simple right. It is, but it is not all that secure. You see the stored password is obfuscated. That’s is a fancy way of saying that the password is converted to an unreadable format. Unreadable doesn’t mean secure however. And all machines that get this policy will have the same password. The other problem with this solution is that although the password is encrypted using AES 256, the private key for the encryption is located on MSDN.
The passwords are stored in the XML file that Group Policy Preferences uses to store its data. When you set this up you are even warned about this:
Let’s take a look at that file. You can see that while the information shown below in yellow isn’t the password I used (which was Password1), it is still readable by any authenticated user as they all have read access to Sysvol.
Let’s take this a step further. Using a simple PowerShell script (more info found at the link)  that utilizes the encryption key that was easily available on MSDN, I was able to get the password with a few keystrokes.
I’m not sure I could ever in good conscious recommend this to anyone who is serious about security. Once this password is discovered I am opening myself up to a Pass-the-Hash (PtH) attack. So what else can you do?
If you are a Microsoft Premier customer you have the option to get a Proactive Operations Program – Securing Lateral Account Movement (SLAM) delivery (we typically call it POP-SLAM). This course is an advanced course for implementing mitigation lateral movement mitigations from Microsoft’s Pass the HashWhitepaper. It covers an overview of Pass-the-Hash (PtH) and ways to mitigate it, understanding the breadth of related credential theft risks, risks of using shared passwords, the enforcement of local account restrictions, randomized local Administrator account passwords, recovery procedures for privileged account passwords as well as real world capabilities that you can implement into your environment  to compartmentalize and defend against lateral traversal attacks using built in Administrative credentials. (Updated 11-4-14 to reflect new name and add clarity)
Note: If you are a Microsoft Premier customer and would like more information on this delivery, please contact your Technical Account manager. If you aren’t a Microsoft Premier customer, contact us and we can get you talking to the right people.
I know what many of you are saying. I’m too small to be a Microsoft Premier customer but I still want to be do something to protect myself. What can I do? Glad you asked. One of our Microsoft Consulting Services (MCS) engineers wrote a solution to this problem that anyone can download and implement with ease. It works with Windows 2003 SP1/XP and above so as long as you have an Active Directory environment you should be good to go. You do have to be running domain controllers that are running Windows Server 2003 SP1 or a later because this solution uses confidential attributes which were introduced in 2003 SP1. This feature does not depend on whether a domain or a forest functional level is enabled.
So if you want to follow along with my installation instructions, you might want to go ahead and download the files. You will need the Installers and Documentation files.
Solution for management of built-in Administrator account's password via GPO
While you are downloading these let’s talk about what this solution is designed to do:
• Password must be unique and random on each computer
• Password must not be guessable from name of workstation, MAC addresses, etc.
• There must be a way for eligible people (IT support staff) to easily know the password when necessary
• Password management solution must scale to support thousands of computers
• Password management solution must be easily deployable and manageable
• Password management mechanism must be resistant against tampering with
• Password management solution must support renaming of built-in Administrator account
• Password management solution must offer the mechanism for bulk password change when necessary
• Solution must be able to correctly handle the situation when computer is disconnected from corporate network, i.e. not to change the password when it is not possible to report it to the password repository
• Solution must support OS Windows XP/2003 and above
• Solution must support x86 and amd64 hardware platforms
There is a lot more that this solution can do but those are the highlights. The documentation provided with the solution is very detailed and can answer most any question you might have. The developer of the solution is also very responsive if your questions aren’t answered either here or on the Q/A section of the solutions page. What I wanted to do in this blog is to show you just how easy this is to install and configure.
Here is my little Disclaimer: You should test all of this out in a lab first as the first step requires that you modify the Active Directory Schema which as you probably know is non-reversible. As you are also aware, Microsoft no longer supports XP. If you continue to use Windows XP now that support has ended, your computer will still work but it might become more vulnerable to security risks and viruses. If you are reading this article on how to help increase security I'm assuming you are either already off of XP or well on your way. If you aren't, what are you waiting on!
As in the previous articles I am going to assume you know how to set up a basic Active Directory domain with servers and clients and won’t be covering that. So let’s get started.

Installation Procedures

Much of this work involves modifying the Schema, Group Policies and Organization Units (OU) so I am doing all of this work on my Domain Controller. I’m using Windows Server 2012 R2 and Windows 8.1 on the client so that’s where the screenshots are taken from.
The first thing to do is to extract the files from the to a folder. There will be two files, AdmPwd.Setup.x64.msi and AdmPwd.Setup.x86.msi. Copy these files to a working directory. Double click on the appropriate file to get started.
Click Next.
For this first machine you should enable all the installation choices. You will use these same files later to install the Client Side Extensions (CSE) on all the computers and the PowerShell module and/or Fat client on the management computers.
Click Next.
Click Install.

Modifying the Schema

The Schema needs to be updated to add two new attributes:
ms-MCS-AdmPwd – Stores the password in clear text
ms-MCS-AdmPwdExpirationTime – Stores the time to reset the password
I can already hear the wheels turning on the clear text part. When the password is changed the communication is encrypted with Kerberos encryption. We will cover restricting its viewing it in Active Directory in a just a minute.
** Just to make sure you didn’t just skim over the first part to get to the “meat” of the article, let me just say one more time that you should be testing this in a LAB environment first**
Okay, back to the good stuff. To update the Schema you first need to import the PowerShell module. Open up an Administrative PowerShell window and use this command:
Import-module AdmPwd.PS
Now you can update the Schema with this command:

Delegation of permissions on computer accounts

The next step is to remove all extended rights/permissions from users and groups that are not allowed to read the value of attribute ms-MCS-AdmPwd. This is required because the All Extended rights/permissions permission also gives permission to read confidential attributes. If you want to do this for all computers you will need to repeat the next steps on each OU that contains those computers. You do not need to do this on subcontainers of already processed OUs.
1. Open ADSIEdit
2. Right Click on the OU that contains the computer accounts that you are installing this solution on and select Properties.
3. Click the Security tab
4. Click Advanced
5. Select the Group(s) or User(s) that you don’t want to be able to read the password and then click Edit.
6. Uncheck All extended rights
Important: This will remove ALL extended rights, not only CONTROL_ACCESS right, so be sure that all roles will retain all necessary permissions required for their regular work.
Next we need to add the Write permission on ms-MCS-AdmPwdExpirationTime and ms-MCS-AdmPwd attributes of all computer accounts to the SELF built-in account. This is required so the machine can update the password and expiration timestamp of its own built-in Administrator password. We can use PowerShell to do this.
Set-AdmPwdComputerSelfPermission -OrgUnit
In my case the OU name was Servers. Repeat this for any additional OUs that contain computer accounts you want this solution to apply to.
Now add the CONTROL_ACCESS permission on ms-MCS-AdmPwd attribute of the computer accounts to group(s) or user(s) that will be allowed to read the stored password of the built-in Administrator account on managed computers.
Set-AdmPwdReadPasswordPermission -OrgUnit -AllowedPrincipals
Use the same –OrgUnit name(s) as in the previous command.
Note: You can use multiple groups and users in the same command separated by comma.
Ex: Set-AdmPwdReadPasswordPermission -OrgUnit Servers -AllowedPrincipals domain2\Administrator,domain2\HelpDesk,domain2\Group3
Lastly we need to add the Write permission on ms-MCS-AdmPwdExpirationTime attribute of computer accounts to group(s) or user(s) that will be allowed to force password resets for the built-in Administrator account on managed computers.
Set-AdmPwdResetPasswordPermission -OrgUnit -AllowedPrincipals
Again, use the same –OrgUnit name(s) as in the previous commands. You can still use multiple groups and users in the same command separated by comma.

Registration of CSE with chosen Group Policy Object

What makes all of this work is a Group Policy client side extension that runs on each server whenever Group Policy is refreshed. We need to register it with a PowerShell command.
Register-AdmPwdWithGPO -GpoIdentity: "General Server GPO"
The –GPOIdentity can be either the displayName, GUID or distinguishedName. My example uses the displayName.
If you are wondering what this command does, it adds its client side extension value to the gPCMachineExtensionNames attribute for the Group Policy you selected. I my policy it looked like this:

Run the client install on the local servers

The final step in the setup process is to run the client install on the local computers. These are the same install files, AdmPwd.Setup.x64.msi and AdmPwd.Setup.x86.msi, that we used earlier. I chose to do mine using the Software Installation feature of Group Policy but you can do this any way you like. If you just want to test this quickly a manual install like we did in the beginning works just fine. On the client you don’t need to choose any additional options.
Once this is installed you can see it in Programs and Features.
If you want to script this you can use this command line to do a silent install:
msiexec /i \AdmPwd.Setup.x64.msi /quiet or msiexec /i \AdmPwd.Setup.x86.msi
Just change the to a local or network path. Example: msiexec /i \\dc3\share\AdmPwd.Setup.x64.msi /quiet
I’m sure there are other ways but this should get you started.

Changing the Basic Configuration

By default this solution uses a password with password complexity, 12 characters and changes the password every 30 days. If you decide you want to change that just modify the settings as seen below.
Choose the settings that fits your needs.

So what does this look like?

Once everything is configured, and Group Policy has refreshed on the clients, you can look at the properties of the computer object and see the new settings.
The password is stored in plain text. The Expiration date is a little more complex. Active Directory stores date/time values as the number of 100-nanosecond intervals that have elapsed since the 0 hour on January 1, 1601 till the date/time that is being stored. The time is always stored in Greenwich Mean Time (GMT) in the Active Directory. If you want to convert it yourself try this command:
w32tm /ntte
I know you don’t want everybody poking around in Active Directory so wouldn’t it be nice if there was a graphical interface available. Well there is. When you install the program on a computer where you want the ability to easily retrieve the password just select the Fat client UI option.
The program you want to run is C:\Program Files\AdmPwd\ AdmPwd.UI.exe. It will be in the menu and looks like this:
When you launch the interface all you have to do is enter the client name and click Search.
If you want to manually reset the password just click the Set button. When a Group Policy refresh runs it will be updated.
If you don’t want to deal with a GUI you can also get the password using PowerShell. All the same security you set still applies. You still need the rights to read this attribute!
Get-AdmPwdPassword -ComputerName
You can also reset the password using PowerShell.
Reset-AdmPwdPassword -ComputerName -WhenEffective
Just in case you are wondering, let’s see what happens when a user who hasn’t been granted rights to see the local Administrators password tries to access it. If they were to gain access to the GUI interface the password won’t be displayed.
Likewise if they run Active Directory Users and Computers (ADUC) and try to view the password it will show as Not set.
Compare that screenshot with someone who has been granted rights to view the password.
Now you can see why earlier we removed the extended rights and granted only certain individuals and groups the rights to see this. It doesn’t take a lot of effort for someone to browse through Active Directory and see most any information. If you don’t restrict who can see this then why are you bothering to implement this in the first place?

Final Thoughts

As I mentioned earlier, security is at the top of many people’s list these days and sometimes the implementation of solutions can be costly and/or time consuming. I wanted to show that there are still things that can be done quickly and easily to lessen the impact of security threats. Speaking of that, don’t forget about the Premier offering I talked about towards the beginning. It covers a wider range of security issues. If you want someone onsite to help you with this and a whole lot more, tell your TAM you want SLAM. You can send them a link to this post if you want. If you aren’t a Premier customer and want to find out all the benefits of being one just let us know.
So your mission, should you decide to accept it, is to quickly and easily increase security in your environment by changing your local administrator passwords and make them unique on every machine. This password will self-destruct in 3…2…1….
Tom Ausburne

Windows - Horário de verão 2019 | Como preparar os servidores e estações para NÃO alterarem o horário?


Como muitos sabem, o governo determinou que este ano não haverá horário de verão.
Sendo assim, os relógios não serão adiantados em 1 hora no dia 3 de Novembro conforme previsto.
Bom para alguns, ruim para outros, mas para os administradores de TI esse tipo de alteração sempre gera uma certa preocupação...
O problema entorno do assunto é que os Sistemas Operacionais (Windows) já estão pré-configurados para adiantarem automaticamente seus relógios e para que isso não ocorra é necessário alterar essa configuração.
Reuni a seguir as informações mais importantes e o que você deve fazer para que as máquinas permaneçam com o mesmo horário e tudo continue funcionando.

Updates do Windows

A Microsoft incluiu em seus updates desde Julho deste ano (2019) a desativação do horário de verão.
Se você mantém as máquinas com os últimos updates instalados, os sistemas operacionais já estão preparados e não mudarão o horário.
Abaixo está a lista dos updates por sistema operacional e o link caso você queira baixar e instalar manualmente ou distribuí-los via WSUS e System Center.
Versão do Sistema Operacional: Windows Server 2008, 2008 R2, 2012, 2012 R2, Windows 7, 8, 8.1
Atualização: kb4507704
Link para download:
Exige reinicialização?: Não
 Versão do Sistema Operacional: Windows Server 2016, Windows 10
Atualização: kb4507459
Link para download:
Exige reinicialização?: Sim

Pontos de Atenção

  • As atualizações até o Windows Server 2012 R2 e 8.1 não exigem reinicialização e são pequenas, menores que 700 kb. Já as atualizações para Windows 10 e Server 2016 exigem a reinicialização e chegam a 1.4 gb.
  • Se as máquinas não se atualizam há muito tempo pode ser que ainda estão com a configuração de 2017 e ao invés de adiantarem o relógio dia 3 de Novembro, a alteração ocorrerá dia 20 de Outubro.

Desativando através de GPO (Group Policy Object)

Se por algum motivo você não pode atualizar as máquinas (o que é altamente recomendável), siga os passos a seguir e efetue o ajuste sem grandes esforços.
1º Passo: Abra o Group Policy Management (gpmc.msc no executar) através de um Domain Controller (Servidor AD) ou de um computador que possua o RSAT instalado, clique com o botão direito na OU que deseja aplicar a GPO e selecione a primeira opção "Create a GPO...".
Insira um nome e clique em ok.
2º Passo: Clique com o botão direito na GPO e selecione Edit...
3º Passo: Navegue até "Computer Configuration > Preferences > Control Panel Setings", clique com o botão direito em "Scheduled Tasks", vá em New e selecione a opção Immediate Task (At least Windows 7).
Observação: Caso você ainda possua máquinas com o Windows XP ou Server 2003, após criar a task conforme abaixo, crie também uma task com a opção Immediate Task (Windows XP).
4º Passo: Insira um nome para a Task, clique no botão "Change User or Group...", altere para a conta system e mantenha as demais opções conforme o exemplo abaixo. Ao terminar vá para a guia Actions.
5º Passo: Clique em New..., insira no campo Program/Script: %SystemRoot%\System32\cmd.exe e no campo Add arguments(optional): /c TZUTIL /s "E. South America Standard Time_dstoff" .
6º Passo: Clique em ok duas vezes para concluir as configurações e pronto, a GPO está configurada e basta aguardar que as máquinas da OU que você aplicou recebam as alterações.
Atenção: Caso o fuso horário seja diferente de (UTC-03:00) Brasília, o mesmo será alterado para essa opção ao aplicar a GPO.

segunda-feira, 14 de outubro de 2019

Windows - Net time privilegios (usar ou não usar?)

Erro do Sistema 1314

Olá a todos
Aqui eu vou lhes explicar uma maneira de resolver o problema do erro de sistema 1314.
Esse erro de sistema ocorre quando uma usuário tenta sincronizar o horário do seu micro usando o serviço de tempo da rede (net time) com o horário do domínio. Isso é um erro de privilégio. Vê a imagem

um jeito para resolver isso é clicar com o mouse direito no ícone da linha de comando e escolher o opção “Executar como Administrador”

e depois executar o comando net time /domain:NOMEDODOMÍNIO /set
se tudo deu certo voce pode digitar somente o comando net time e o sistema retorna o horário e a data atual no AD.

Usando W32tm – o serviço de tempo de Windows

Vamos ver como resolver o problema de uma outra maneira; com o w32tm que resolve o problema de sincronismo.
A Microsoft não recomenda que sincronizamos os nossos micros com o horário da rede, ou seja usando o comando net time enquanto o serviço de tempo está rodando

então não é recomendado usar o comando net user /domain:NOMEDODOMÌNIO /set
vê o artigo

Devemos sincronizar o serviço de tempo nos micros com o horário do AD. O serviço de tempo é o W32TM. Para fazermos o sincronismo iremos precisar de privilégio administrativo. Para que um usuário normal que não é membro do grupo administradores possa executar o comando de sincronismo ele irá precisar da senha do administrador.
Primeiro vamos executar a linha de comando “CMD” como administrador;
runas /user:administrador cmd isso irá pedir a senha do administrador, digite a senha correta
agora que abriu a janela de linha de comando, digite
w32tm /configure /syncfromflags:domhier /update isso irá nos sincronizar com o horário do AD.
Para ver o resultado da sincronização use os comando
w32tm /query /computer:NOMEDOSEUMICRO /status ou para ver mais configurações w32tm /query /computer:NOMEDOSEUMICRO /configuration É possivel também por os comandos de configuração juntos, como
runas /user:administrador "w32tm /configure /syncfromflags:domhier /update" Eu prefiro ver o resultado do comando para saber se funcionou ou não, e com os dois comandos juntos , o comando executa e fecha muito rápido (imagina  digitar ipconfig no iniciar, executar).
--- não usar, caiu em desuso?!
Have a look at this GPO Setting,

Computer Configuration\Windows Settings\Local Policies\User Rights

Assignment\Change the system time 
--- link util 

domingo, 13 de outubro de 2019

Windows - Script de horário de verão

Segue um script o qual você pode salvar com a extensão .vbs e executar nas estações para desmarcar a opção de horário de verão no Windows. Atente para a penúltima linha que contém um comando de sincronização de horário com o PDC emulator. Você deve alterar para o nome do seu servidor.

Const HKEY_LOCAL_MACHINE = &H80000002
strComputer = "."
Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & _
strComputer & "\root\defaultTongue TiedtdRegProv")
strKeyPath = "System\CurrentControlSet\Control\TimeZoneInformation"
strValueName = "ActiveTimeBias"
dwValue = 180
oReg.SetDWORDValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,dwValue
strValueName = "DaylightBias"
dwValue = 0
oReg.SetDWORDValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,dwValue
strValueName = "DaylightName"
strValue= "Hora oficial do Brasil"
oReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strValue
strValueName = "DisableAutoDaylightTimeSet"
dwValue = 1
oReg.SetDWORDValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,dwValue
'Net time
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")
Set objShell = CreateObject("")
strCmd = "net time \\servidor_pdcemulator /set /yes"
set objexec = objshell.exec(strcmd)

----- erro windows 7 sp1:

whoami /priv
1. Edit windows registry
  • Start Registry Editor.
  • Locate and then right-click the following registry subkey:
  • Click Permissions, click Administrators, click to select the Allow check box for Full Control,  then click OK.
  • In the details pane, double-click the RequiredPrivileges entry.
  • In the Value data list, type SeTimeZonePrivilege, and then click OK. This adds SeTimeZonePrivilege to the list.
  • Exit Registry Editor, and then restart the computer.
and export privilege key in .reg file.
2. Add reg file to GPO  startup script. The Local System have full access right on this registry  key.
3. In next reboot a SeTimeZonePrivilege adding in the registry and tzutil run success.
Good Look!