New answers tagged active-directory
Firstly as per @EricG most of the administration should be handled using a network administrator account, using group policies and the like. If you need access to a users logged-in session the best way to approach this is to have the user login to their machine and then hand you the keyboard. That way you never learn there password, and the user can observe ...
The alternate solution could be to use a host-based intrusion detection system (HIDS) that can be set with detection rules around the resources and logs used/created by the domain controller (Active Directory). Most HIDS solutions can allow you to setup alerts that are trigger based on specific thresholds (i.e. after 10 failed attempts generate an email ...
Depending on where the pentest is being launched, one should be able to determine the DC by querying the SRV records for LDAP, Kerberos, GC, etc. This Microsoft TechNet link has some examples.
Jumping on the NMAP bandwagon: also look for machines that have TCP port 389 (LDAP), 636 (LDAPS), 3268 (LDAP Global Catalog), or 3269 (LDAPS Global Catalog). The last two are particularly juicy, since only a DC can be a Global Catalog server.
Using only a BIND isn't guaranteed to restrict access to desired users. For example, you'll also want to check if the user is locked, e.g. the userAccountControl attribute. If you are really concerned about storing credentials in memory and want rapid suspention of user rights via LDAP, then you can keep the session open with periodic queries of the ...
From what could perceive, your problem is not Active Directory-specific. You would still have this issue if it were SQL-based or any other kind of authentication backend. What we have to solve is: how do we keep awareness about the logged-in user account status without remembering the account credentials or asking for re-authenticating AND not forsaking ...
Top 50 recent answers are included