We will see in this post some steps of a pentest against an ADDS domain. This pentest focuses only on the Microsoft System and does not take into account Antivirus, Firewall, IDS and IPS protections. The parts we describe in detail are scanning, exploitation and maintaining access. The pentest is performed with BackTrack 5 R3, you can download it here. The tools we use are Nmap, Nessus, Metasploit (the hacker’s framework, exploits are written in ruby), John the Ripper and Powershell. The pentest’s goal is to retrieve domain administrator credentials and maintain the access on the ADDS domain discretly.
Read more »

When demoting a domain controller the following error message appeared:

The operation failed because: Managing the network session with dc-srv2.ldap389.local failed.
“The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.”

Read more »

You can’t wait to install Windows server 8 developer preview in order to test it in the event of a future deployment… But you might want to finish your migration to ADDS 2008R2 before thinking about all that 😉 Bellow is a tab showing some client compatibility issues and the important steps when migrating your domain controllers to Windows server 2008R2:

Read more »

We will describe in this post how to secure your autologon workstations. Those PCs are accessed by everyone inside your company because no account and password are required to login.This is why you need to work out how to secure them.

The autologon workstation uses a service user account to open a windows session, the most obvious way to set up an autologon on a workstation is to edit registry keys. This method is not secure because the account credentials appear in clear text in the registry, meaning that the account can easily be used for other purpose.
Read more »

The title of this post seems a bit contradictory, the use of generic accounts in your domain should be limited to the minimum. Access to your domain ressources should be done with nominative accounts when possible, that’s why you want to avoid generic accouns use. However for political or historical reasons a department of your company might use this type of accounts to access some applications or log on some computers. This account is used by several persons, accordingly the password does not remain secret and across many departments, non-authorized persons might know it and use it for other purposes. If you set up a classic change password policy for this account, then when the password expires, a single person will change it and will probably not notify other users that are entitled to use the account of the new password. That’s why generic accounts are generally flagged “the password never expires”, which is an obvious lack of security. We will demonstrate in this post how to set up an automatic system that will change the password and notify users entitled to use the account.
Read more »