Active Directory

Auditing Active Directory Password Quality

Posted by robd on April 24, 2018
Active Directory, powershell / No Comments

Hi All,

A chap called Michael Grafnetter has created a brilliant PowerShell script to check password hashes in Active Directory against a list of simple or common passwords.

This is great to encourage users not to use obvious passwords, for example if a company is called Contoso then you’d want to encourage users not to use Contoso1 etc.

Here’s how:

Download the software:

Copy the DSInternals directory to your PowerShell modules directory, e.g.

Launch Windows PowerShell.
(Optional) If you copied the module to a different directory than advised in step 4, you have to manually import it using the Import-Module .\DSInternals\DSInternals.psd1 command.

Next create a text file called passwords.txt and fill it with passwords you’d like to scan for, example:

Then here’s an example script:

First set the password txt file.

Then set the Domain Contoller, in this case DC1

Then set the distinguished name of the OU and sub OUs you can to scan:

Note ” and ‘ are not showing up properly,

$dictionary = Get-Content passwords.txt | ConvertTo-NTHashDictionary Get-ADReplAccount -All -Server DC1 -NamingContext ‘dc=adatum,dc=com’ | Test-PasswordQuality -WeakPasswordHashes $dictionary -ShowPlainTextPasswords -IncludeDisabledAccounts

Here’s an output:

Tags: , ,

Exchange 2010 – View Entire Forest

Posted by robd on December 11, 2015
Active Directory, exchange 2010, powershell / No Comments

So today I was trying to running some cross domain PowerShell commands on Exchange but kept getting the following error:

Which basically means the Domain Controller your referencing can only see your sub domain and nothing higher.  So to resolve run this before the command:

Tags: , , ,

Exchange store failes due to AD topography changes

So today I was working at a site that has a single Exchange 2010 server that forfills all the Exchange roles (I know….) which happened to fall on its ass.

First thing I did was check the Exchnage services which were in a state of “starting” which is never good and then I went to the registry and found:

MSExchange ADAccess, EventID 2141
Process STORE.EXE (PID=2996). Topology discovery failed, error 0x8007077f

MSExchange ADAccess, EventID 2142

Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1760). Topology discovery failed, error 0x8007077f

Here’s a few screen shots:

exchange error1exchange error2exchange error3exchange error4

As well as a few more related to AD.

After some investigation I found out that a new DC in a new site had been created for some DFS replication amongst other things.

As the system could start the Microsoft Exchange Active Directory Topology service (until it failed and is restarted by dependent services), Exchange’s other services were also triggered, leading to almost indefinitely restarting services as configured in their corresponding service recovery actions sections.

So next up is to look at Active Directory Sites and Services:

exchange error5

And as you can see from the screen shot the subnets are missing, which is going to cause issues as the new DC is on a different subnet.

When Exchange can’t determine in which site a computer belongs, the function DSGetSiteName, used to retrieve the current site, returns an error 1919 0x77f (ERROR_NO_SITENAME) which in turn kills off Exchange.  You can test this by running nltest /dsgetsite in a command prompt or by having a look at  HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName.

To solve the issue you can do any of the following:

  1. Making the site association static using a registry key, which isn’t a best practice. If you must, set registry key HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SiteName(REG_SZ) to the desired site name;exchange fix1
  2. Adding proper subnet definitions;exchange fix2
  3. Remove the new site.


Finally give Exchange a  bounce and BOOM.


Note that the NetLogon service determines site association membership at startup and every 15 minutes. The Microsoft Exchange Discovery Topology service maintains this information by caching the information in the msExchServerSite attribute of the Exchange server object, in order to reduce load on active directory and DNS. Therefore, you might need to wait or restart Microsoft Exchange Discovery Topology if you want to renew site association membership.



Copy Protected by Chetan's WP-Copyprotect.