Christos Polydorou

The adoption of cloud technologies has introduced a new way of managing resources, whether they are related to infrastructure, security, applications, etc. In the past, code repositories such as Git were just used manage application code, but now we use them to manage pretty much everything. However, not everyone is familiar with repositories and their principals and that sometimes leads to issues. A very common practice I've come across many times lately is having too many commits related to a single feature or request. I'm not suggesting commiting only big chunks of code that contain many changes at once, but instead getting rid of multiple commits that each one may overlap with the previous one or just contains minor changes. At least when pushing to a remote source that other people my be watching.  The three most common ways to clean up commits are reset , merge and rebase . For demonstration purposes we'll be working with a repository that contains Azure ARM template...

On my lab environment, I've configured two Active Directory sites since most enterprises have offices in more that one places. My lab however is not running 24/7 and the domain controllers in the second site are rarely turned on in order to save resources. This leads to issues with the Active Directory replication such as the "The target principal name is incorrect" error when I execute:  repadmin /syncall /AdeP. To remedy the issue, we have to reset the machine password of the domain controller that has been offline. First off, we are going to stop and disable the Kerberos Key Distribution Center (kdc) service on the problematic domain controller, in our case DC4. There may be some tickets in the cache so we should also clear them using klist purge Now it's time to change the machine password of the domain controller using the command netdom resetpwd /s:dc3 /ud:lab\administrator /pd:* Replace the "lab\administrator" with an account on your...

I run across a very strange issue a few days ago and I feel that I should share it with you since it took me some time to figure it out! Some Exchange servers had stopped recording events in the Security log. The first thing that crossed my mind was to check the latest event in the Security log that would probably be the event regarding the audit policy change. I was correct, there were many events with id 4719 that showed that the policy had been changed. The next step would be to update the policy in order to enable auditing. There were servers that had auditing configured according the security baseline so I backed up the auditing configuration from one of them using the command: auditpol /backup /file:C:\Temp\Audit.txt Next I copied the file to the server with the issue and used the command: auditpol /restore /file:C:\Temp\Audit.txt to restore the settings. The command completed successfully and it was time to check the new auditing settings. For this I used the com...