SOX regulations, security procedures or your boss may require you to have the password periodically changed for accounts running services, scheduled tasks or IIS application pools.
Before you go ahead and change the password, you should either have a detailed list of who (the user account) runs what (the service, task or application pool) and where (on which computer), or use a script to get this information, so after you change the account’s password in the domain, you can go to all those services, scheduled tasks or application pools on the different computers and change the password settings.

Since I needed to do just that, I’ve decided to write a PowerShell function that can scan a computer (or an array of computers) and list all those services, scheduled tasks or application pools.

Services
Getting the services information was easy, using the Get-WmiObject cmdlet and querying the Win32_Service Class, especially getting the StartName property:

Get-WmiObject -Namespace root\cimv2 -Class Win32_Service -ComputerName $Computer ...

Scheduled Tasks
Getting the Scheduled Tasks information was a different challenge. I thought about using the Schedule.Service com object, and parsing the xml property:

$sch = New-Object -ComObject Schedule.Service
$sch.Connect($Computer)
$tasks = $sch.GetFolder("\").GetTasks(0)
$tasks | Where-Object { ([xml]$_.xml).Task.Principals.Principal.UserID -eq $UserAccount }

SCHTASKS /QUERY /S $Computer ...

Filtering
This time, I needed to filter the results using the Where-Object cmdlet which accepts a scriptblock in the –FilterScript parameter. So for the specific user (“explicit” scenario) I used the –like comparison operator:

$TaskFilter = { $_.{Run As User} -like $UserAccount }

For the non-built-in accounts (“implicit” scenario), I used the –notcontains comparison operator with an array of strings to exclude:

$TaskSystemAccounts = @("INTERACTIVE", "SYSTEM", "NETWORK SERVICE", "LOCAL SERVICE",
 "Run As User", "Authenticated Users", "Users", "Administrators", "Everyone", "")
$TaskFilter = { $TaskSystemAccounts -notcontains $_.{Run As User} }

Although the MicrosoftIISv2 WMI namespace may be available on IIS 7/7.5 (if you’ve installed the IIS 6 WMI compatibility on the machine), but the correct way would be to query the WebAdministration WMI namespace (part of the IIS Management Scripts and Tools Web-Server role services)
The ProcessModel.UserName (in the ApplicationPool class) is the property that contains the ApplicationPool identity, and when the ProcessModel.IdentityType equals to 3, it means that it is a specific user and not any of the built-in accounts.

Alternate credentials (and splatting paramters)
After testing the function a few times, it occurred to me that I (or anyone else using the function) may want to use alternate credentials to connect to the remote computer(s).
Lucky me, the Get-WmiObject has a –Credential parameter that accepts a PSCredential object.
So I decided to use the splatting technique, by creating a hashtable with all parameters to be passed to the cmdlet, and add or remove parameters if needed. For example, WMI does not support connecting to the local computer using credentials. So if the user supplied alternate credentials and the computer being queried is the local machine, the –Credential needs to be removed from the parameters hashtable.

if (@("$ENV:COMPUTERNAME","localhost","127.0.0.1","::1") -contains $Computer) { 
 $ParamServices.Remove("Credential")...

For the Scheduled tasks, there are two parameters: /U and /P that accept the User and Password (respectively) for the remote connections.
IMPORTANT: Please note that the value of the password is translated into clear text before passed to the command.

Parameter Sets
Since I needed to have two options for running the function:
  A. When I know which account to look for (the exact name, or using wildcards). A.k.a. the “Explicit” scenario.
  B. When I want the function to get the Services, Scheduled Tasks and ApplicationPools that are running under any account other than the built-in accounts.  A.k.a. the “Implicit” scenario.
I created two ParameterSets accordingly, and assigned the -UserAccount parameter in the Explicit ParameterSet, and the -NonSystemAccounts in the Implicit ParameterSet.
This way, I got my two options for running the function. See the two syntax lines in the snapshot below (Click to enlarge).

Then I only had to check what ParameterSet was used, and set the relevant filters accordingly:

switch ($PsCmdlet.ParameterSetName) {
    'Explicit'  { 
        $ServiceFilter = "StartName LIKE '$(($UserAccount).Replace("\","\\").Replace("*","%"))'"
        $TaskFilter = { $_.{Run As User} -like $UserAccount }
        $IIS6Filter = "WAMUserName LIKE '$(($UserAccount).Replace("\","\\").Replace("*","%"))'"
        $IIS7Filter = "ProcessModel.UserName LIKE '$(($UserAccount).Replace("\","\\").Replace("*","%"))'"
        break
        } 
    'Implicit'  { 
        $ServiceFilter = "(NOT StartName LIKE '%LocalSystem') AND (NOT StartName LIKE '%LocalService') AND (NOT StartName LIKE '%NetworkService') AND (NOT StartName LIKE 'NT AUTHORITY%')"
        $TaskSystemAccounts = 'INTERACTIVE', 'SYSTEM', 'NETWORK SERVICE', 'LOCAL SERVICE', 'Run As User', 'Authenticated Users', 'Users', 'Administrators', 'Everyone', '';
        $TaskFilter = { $TaskSystemAccounts -notcontains $_.{Run As User} }
        $IIS6Filter = 'AppPoolIdentityType = 3'
        $IIS7Filter = 'ProcessModel.IdentityType = 3'
        break
    }
}

Related Reading: https://blogs.msdn.com/b/powershell/archive/2008/12/23/powershell-v2-parametersets.aspx

Managed Service Accounts and Virtual Accounts
Instead of using a regular user account as a service account that you need to manage its password, you can assign a computer (Windows 2008 R2 or Windows 7) a Managed Service Account (a.k.a. MSA).
MSA’s allow you to create a special account in Active Directory that is tied to a specific computer. That account has its own complex password and is maintained automatically. This means that an MSA can run services on a computer in a secure and easy to maintain manner, while maintaining the capability to connect to network resources as a specific user principal.
MSAs cannot be shared between multiple computers, thus cannot be used in server clusters where a service is replicated on multiple cluster nodes.

Virtual accounts in Windows Server 2008 R2 and Windows 7 are "managed local accounts" that do not require any password management and have the ability to access the network with a computer identity in a domain environment (similar to Network service account).

Windows Server 2008 R2 domains provide native support for both automatic password management and SPN management of MSAs.
If the domain controller is on a computer running Windows Server 2008 or Windows Server 2003 and the Active Directory schema has been upgraded to support this feature, managed service accounts can still be used and MSAs passwords will be managed automatically. However, the domain administrator will still need to manually configure the SPNs.
Related reading:  https://technet.microsoft.com/en-us/library/dd548356 and https://support.microsoft.com/kb/2494158

The Get-ServiceAccountUsage function can be downloaded from here: https://gallery.technet.microsoft.com/Get-ServiceAccountUsage-b2fa966f
Please note that it is provided “as is” without warranty of any kind.

FAQs:
Q: How do I use the function?
A: The script file contains the Get-ServiceAcco​untUsage function.
You need to "dot-source" the script file, to have the function declared in your scope, and then you can call it with whatever parameters you need. for example:

PS> CD C:\myScripts
PS C:\myScripts> . .\Get-ServiceAc​​countUsage.ps1
PS C:\myScripts> Get-ServiceAcco​​untUsage -UserAccount 'myDomain\myUse​​r'

Stay tuned for the next post on the subject, where we’ll discuss Get-ServiceAccountUsage’s evil twin brother: Set-ServiceAccountUsage.

Martin.

In the last part of the series we're going to discuss Domain Controller replication failover between a Hub, Branch and DRP sites and different scenarios when doing so.

While talking about AD replication, it's important to note that usually Active Directory replication isn't considered as the most critical service in the environment, and I absolutely agree.. An environment can work seamlessly when Active Directory replication is not working. Obviously having Active Directory not replicating for long periods of time may cause issues, inconsistencies and other problems (long period => Tombstone Life Time), but having AD not replicating in the middle of the night wouldn't get me out of bed running to my computer in order to fix the issue.. On the other hand, I would go and do that first thing in the morning.

Now back to our environment.. again, we'll start with the simplest scenario, of one Domain Controller in each site:

In our environment we have two Branch sites (Branch and Branch2) which are connected to the HUB site, each with a site link cost of 100.

The HUB site is connected to the DRP site with a site link cost of 10. Bridge All Site Links (BASL) is enabled in the environment. Having said that an attempt to calculate the routes in the environment would result in the following (ordered based on costs):

From Branch

1. Branch –> Hub = 100

2. Branch –> DRP = 110 (Branch –> HUB –> DRP).

3. Branch –> Branch2 = 200 (Branch –> HUB –> Branch2)

From Branch2

1. Branch2 –> HUB = 100

2. Branch2 –> DRP = 110 (Branch2 –> HUB –> DRP)

3. Branch2 –> Branch = 200 (Branch2 –> HUB –> Branch).

(A short reminder to make things clearer: BASL – Bridge All Site Links, means all site links are transitive. More information on BASL and AD replication topology can be found here - https://technet.microsoft.com/en-us/library/cc755994(WS.10).aspx).

In that scenario it's obviously expected that the Branch sites (Branch and Branch2) would failover to the DRP site if the HUB site fails, instead of failing over to each other. (A matter of cost calculation, based on the table mentioned Branch –> DRP is cheaper than Branch –> Branch2).

So let's fail the DC in the HUB site…

Running repadmin /showrepl on Child-DC04 would show we already have several failed attempts to replicate with the Domain Controller in the HUB site:

So the question is:

What are we waiting for?

Well… the answer is this:

IntersiteFailuresAllowed

Value: Number of failed attempts

Default: 1

MaxFailureTimeForIntersiteLink (sec)

Value: Time that must elapse before being considered unavailable, in seconds

Default: 7200 (2 hours)

(All described here - https://technet.microsoft.com/en-us/library/cc755994(WS.10).aspx and https://technet.microsoft.com/en-us/library/cc961781.aspx).

Basically we'll wait for 2 hours before the source DC for replication is considered stale. So in our scenario when we have failed the DC in the HUB site it would take 2 hours from the last replication attempt for the DCs in the Branch sites to consider the DC in the HUB site as stale.

After the time and the number of failures have elapsed we will get the following event:

Event ID 1308, stating that "The Knowledge Consistency Checker (KCC) has detected that successive attempts to replicate with the following directory service has consistently failed." and that "The Connection object for this directory service will be ignored, and a new temporary connection will be established to ensure that replication continues. Once replication with this directory service resumes, the temporary connection will be removed. "

And a short while later we have received Event ID 2053: "A new connection has been created to address site connectivity issues."

Looking at our environments Visio diagram now would show (as expected):

Child-DC03 and Child-DC04 have created failover connection objects with Child-DC02, which is located at the DRP site, and vice versa, Child-DC02 has created failover connection objects with the DCs at the Branch and Branch2 sites.

So how long did this process take?

Well – we need three events to take place:

1. At least one replication attempt to occur, meaning if the link to the HUB site has failed at 3PM, but we have a replication schedule on the site link configured to replicate only at 1AM we wouldn't even try to replicate before that time… so how would we know the site link has failed?!

2. After we have at least one failed replication attempt (stated in the InterSiteFailuresAllowed registry) we begin counting the Failure time – as stated in the "MaxFailureTimeForIntersiteLink (sec)" registry key.

3. After the MaxFailureTimeForInterSiteLink has elapsed we need KCC to run (which by default occurs every 15 minutes).

So it very much depends on the environment how long it would take the failover connection objects to be created.

What Can I do to make it faster?

First of all, take things in perspective!

if you replicate once in 24 hours, how bad can it be to be 48 hours without replication? Like I mentioned in the beginning of the post – Active Directory not replicating would not get me running anywhere, it would just one of those things on the TODO list  (unless obviously it's a symptom for another issue – like all DCs have crashed on no one in the organization can work… well… I wouldn't consider that as a replication problem to be honest, but that's a matter of semantics cause I can see there's a replication issue there among other problems ).

If you still feel the failover time is not enough, and you need to expedite the failover times you can set the "MaxFailureTimeForIntersiteLink  (sec)" value to a lower value.

Again from https://technet.microsoft.com/en-us/library/cc755994(WS.10).aspx

Modifying the thresholds for excluding nonresponding servers requires editing the following registry entries in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters, with the data type REG_DWORD. You can modify these values to any desired value as follows:

For replication between sites, use the following entries:

• IntersiteFailuresAllowed
  Value: Number of failed attempts
  Default: 1
• MaxFailureTimeForIntersiteLink (sec)
  Value: Time that must elapse before being considered unavailable, in seconds
  Default: 7200 (2 hours)

You will have to perform this on every DC in every Branch site (as those are the ones counting the fails).

You also need to take care while reducing this as having a very low value for this setting may cause false positives when failing between DCs, and since a failover can be an expensive operation we want to minimize the false positives as much as possible.

Note: Whatever you do – Don't go creating manual connection objects! Manage the KCC and the topology of the environment to match your requirements, don't override it with manual connection objects.

Failing back

Usually that's not a concern, but many times this question rises. What happens when the failed DC has come back online?

Well – KCC is aware of that when we have a successful replication attempt with the failed DC (and again, that's based on our replication topology, schedule and times).

So the next time KCC is run we will receive event 1129 stating "To improve the replication load of Active Directory Domain Services, a replication connection from the following source directory service to the local directory service was deleted. "

So those temporary failover connection objects created for failover to the DR site are automatically deleted when the "best" DC (in our case – the DC at the HUB site) comes back online.

So now that we know how failover works lets just briefly discuss the following scenario:

Two Domain Controllers in the HUB site

Let's imagine that the physical site link between the Branch site and the HUB site have failed (to simulate that I'll shutdown the Active Directory Domain Services service on both DCs in the HUB site – Child-DC01 and Child-DC04.

So the first things occurs is exactly as previously: Child-DC03 (Branch) identifies that the current replication partner in the HUB site (Child-DC01) has failed and Event ID 1308 is generated on Child-DC03 (just as previously) stating "The Knowledge Consistency Checker (KCC) has detected that successive attempts to replicate with the following directory service has consistently failed. " and "The Connection object for this directory service will be ignored, and a new temporary connection will be established to ensure that replication continues. Once replication with this directory service resumes, the temporary connection will be removed. ".

Now is the different part:

The new connection object that is generated is with Child-DC01 (HUB):

Event ID 2054 stating:

"The Knowledge Consistency Checker (KCC) created a new bridgehead failover connection because the following bridgeheads used by existing site connections were not responding or replicating. 
Servers:
CN=NTDS Settings,CN=CHILD-DC04,CN=Servers,CN=HUB,CN=Sites,CN=Configuration,DC=trdemo,DC=local"

was generated on Child-DC03.

So Child-DC03 has failed over from Child-DC01 to Child-DC04. Is this the expected behavior???

The answer is yes! If you scroll back up you will note that I was stating all the time that we identify failed Domain Controllers. There is no possible way of identifying site link failures. So in terms of Active Directory replication a failed site is a site where all DCs are not responsive.

And that's an important thing to remember. So in this scenario where we have two Domain Controllers in the HUB site we count the InterSiteFailuresAllowed and the "MaxFailureTimeForIntersiteLink (sec)" values for each Domain Controller in the site.

So with this scenario if the MaxFailureTimeForInterSiteLink is the default 2 hours we are talking 4 hours for failover to the DRP site.

Now let's talk specifically about our test environment:

I have set the MaxFailureTimeForIntersiteLink  (sec) to a value of 300 seconds(decimal) – 5 minutes:

Meaning that 5 minutes of replication failures on an inter-site connection object would consider the source Domain Controller as failed.

So we have Child-DC01 and Child-DC04 failing since (repadmin /showrepl output on Child-DC03):

Source: HUB\CHILD-DC04
******* 8 CONSECUTIVE FAILURES since 2011-12-11 12:58:52

So taking the times we have configured are:

12:58:52 + 5 minutes (MaxFailureForIntersiteLink time) = 13:03:52. So at 13:03:52 Child-DC04 will be considered stale, after which we'll wait for KCC to run.

Since KCC runs every 15 minutes it depends on where in the 15 minutes timeframe we catch the KCC.

The KCC is generating Event 1308 stating that it has identified the failed Domain Controller, followed by Event 2052 stating a new connection object has been created with Child-DC01 (as expected we try to failover between DCs in the HUB site):

 
Next time the KCC is running (which is 15 minutes later @ 13:41:17) we still try to establish a connection object with Child-DC01 (or new selected server at the HUB site).

Next time KCC is run (that's at 13:56:17) we have identified Child-DC01 as a stale server:

Event ID 1307 stating that "The Knowledge Consistency Checker (KCC) has detected that attempts to establish a replication link with the following directory service has consistently failed. "

And only then we consider the HUB site as stale!

And we have Event ID 1566 to support that:

All directory servers in the following site that can replicate the directory partition over this transport are currently unavailable. 
Site:
CN=HUB,CN=Sites,CN=Configuration,DC=trdemo,DC=local

So now we can failover to the DRP site:

Event ID 2053 is generated, stating that we have created a new connection object for failover, and this time it's with Child-DC02 located at the DRP site:

So overall the process took us about 1 hour to failover, and that's with the MaxFailureForIntersiteLink set to a very low value (5 minutes). So with the default setting of 2 hours you can expect 4-4.5 hours (depending on KCC intervals and where you catch them) to failover between a branch site and a HUB site containing two Domain Controllers.

How can we make the process faster?

Just as previously – Take things in perspective. Ask – what happens if my environment doesn't replicate for 5 hours? Do I even need to change anything?

If you do need to decrease the MaxFailureForIntersiteLink  value again, take into consideration the false positives which may result if setting this value to a value which is too low.

Now – if you feel like asking "so what happens if I have 3 DCs in the HUB site?" just use your own logic… (Let me give you a hint – We wait for MaxFailureForIntersiteLink for each DC).

So hopefully it makes sense… now after I completely broke my Lab environment while writing this post I think I'm going to spend some time setting things back to Normal (e.g – Default).

Hope you enjoyed and it will make some more sense when troubleshooting/planning or testing your DRP scenarios.

And let me end on a cheerful note – A DRP site is not a DR Plan!!! In other words: Now that you got your DR site all sorted out, it's time to go and test your other DR scenarios!

(And our colleagues from the UK have nicely listed all the scenarios in one place -  https://blogs.technet.com/b/newenglandpfe/archive/2011/05/20/common-scenarios-for-active-directory-related-backup-and-disaster-recovery.aspx).

Hope we all never need it!

Michael.

The challenge in this scenario is to make the clients in the different Branch sites to failover to their closest Hub sites.

It's obvious that HUB is the best option for failover from Branch when the DC in branch (Child-DC03) fails, and HUB2 is the best option for Branch2 when the DC in Branch2 (Child-DC04) fails.

The problem is, as we learned in the previous post (https://blogs.technet.com/b/isrpfeplat/archive/2011/12/01/disaster-recovery-site-and-active-directory-part-1.aspx), that the client doesn't really care about sites and costs, all it cares about is DNS.

So in this scenario the client would query the generic list of SRV records for the domain (_ldap._tcp.dc._msdcs.domain.name) and will be able to use any of the DCs.

So why not the DNSAvoidRegisterRecords?

The problem is that in this scenario we can remove Child-DC03 (Branch) and Child-DC04 (Branch2) from registering in the DNS by using the DNSAvoidRegisterRecords solution, but… we would still always have Child-DC01 (HUB) and Child-DC2(HUB2) since those are located in HUB sites, and we want the clients to be able to find them no matter what. Plus if I remove them, which one to remove? The DCs in site HUB? That means clients in the Branch site would always login to the DCs in HUB2 and vise versa.

So how can we make the client actually figure out the best option for him if the DC in it's own site fails?

The solution is…. (drum roll).

Try Next Closest Site Feature

Warning: If you're not running 2008 DC/Vista clients or later you can stop reading and use the time to start planning your upgrade…

As described here - https://technet.microsoft.com/en-us/library/cc733142(WS.10).aspx

The behavior of Try Next Closest Site is:

• Try to find a domain controller in the same site.
• If no domain controller is available in the same site, try to find a domain controller in the next closest site. A site is closer if it has a lower site-link cost than another site with a higher site-link cost.
• If no domain controller is available in the next closest site, try to find any domain controller in the domain.

Important note: The NextClosestSite feature is redundant to the AutoSiteCoverage feature. If the site where the client is located is Auto Site Covered by DCs in another site the Domain Controllers performing the AutoSiteCoverage are already in the NextClosestSite.

So basically what this feature does is enabling the client to use the NextClosestSiteName attribute returned to the DC Locator query being issued by the client:

As you can see, this example was from a client located in the Branch site, which got the HUB site as it's NextClosestSiteName, the following example is from a client located at the Branch2 site:

Like we expected – the client located in Branch2 is getting HUB2 as it's NextClosestSiteName.

This attribute is returned for every client OS running a version later than 6.0, meaning Vista and later. But… the client will not make any use of this information automatically.

Enabling the client for Try Next Closest Site

In order for the client to actually use the information it receives in the NextClosestSiteName attribute we need to enable the usage of Try Next Closest Site in GPO otherwise it would just revert to the default behavior as we saw it Part1, which is to query the list of Generic SRV records for the Domain.

If you have DCs Running 2008 or 2008 R2 and clients running Vista or Win7, you can just enable this to be the default behavior for netlogon by using a simple GPO setting.

Located under Computer Configuration/Policies/Administrative Templates/System/Netlogon/DC Locator DNS Records. Try Next Closest Site –> Enabled.

This would make the clients looking for DCs always first try to locate a Domain Controller in the nearest site (based on site link costs and topology) prior to failing over to the generic list.

So what actually happens when a DC fails?

In order to test this behavior let's shut down the AD services on the DC in the client's site (Child-DC01) and perform a secure channel reset (by running nltest /sc_reset:Domain.name)

After we have enabled this feature in GPO and applied it to our clients the result of this test would be:

1. The client issues a query to _ldap._tcp.Branch2._sites.dc._msdcs.domain.name (Frame 203). Since none of the DCs in the site are available our client will receive the DCs IP address from DNS (Frame 204) but will not get a response to the LDAP UDP ping packet sent to the Domain Controller (Frame 207)

2. The client falls-back to the generic list of Domain Controllers and issues a DNS query to _ldap._tcp.dc_msdcs.domain.name. (Frame 240). Recieves the IP addresses of the DCs registered in the Domain's Generic SRV list (Frame 241)

3. The client sends the UDP LDAP Ping (Frame 244) to one of the DCs (in our case Child-dc02) and receives a responses with the Netlogon:LogonSAMLogonResponseEX message containing the NextClosestSiteName (Frame 247).

3. The client performs a DNS query based on the NextClosestSiteName information – _ldap._tcp.HUB2._sites.dc._msdcs.domain.name. (Frame 251) and receives a response containing the DCs in site HUB2 (Frame 252).

4. The client sends the UDP LDAP ping to a DC in site HUB2 (Frame 253). The client has received a valid response from Child-DC02 knowing it's in it's closest site. (Frame 254).

5. The client performs the secure channel binding (this what I actually requested to do by running nltest /sc_reset) against a DC in the closest site.

So by using the Try Next Closest Site feature we have enabled our clients to fail to sites which are the closest to them instead of randomly choosing an available DC in the domain based on the generic SRV record list.

That's it for Client logon and failover between sites. In Part 3 we will discuss the Domain Controller replication failover between sites in the different scenarios.

Part 3 - https://blogs.technet.com/b/isrpfeplat/archive/2011/12/11/disaster-recovery-site-and-active-directory-part-3-of-3.aspx

See you soon

Michael.

Michael here again, and this time I would like to talk a little bit about Active Directory replication and Disaster Recovery sites.

Since the not so recent events (taking place on 9/11) many companies started to invest time and money in designing and implementing Disaster Recovery solutions which are located at a different physical location in order to provide the organization the option to seamlessly (saying seamlessly after a disaster strikes is kind of bad choice of words, but hey… don't shoot the messenger) failover to that site and keep the business and the organization working.

One of the aspects which needs to be considered is the oh so important but often overlooked feature of client logon. In the first part of this post we will discuss about how clients logging on to the network are affected by this.

In the second part of the post we'll review how to fail-over clients when we have multiple sites with Domain Controllers, and we want the client to failover to the best site possible, and in the third part we'll see the affect it may have on Domain Controller replication in the organization, and how to properly configure and test the failover scenarios.

Client logon scenario:

In our sample organization we have a hub site and a DR site both of which contain Domain Controllers. In addition we have several branch sites which don't contain any DCs and rely on the Automatic Site Coverage feature to provide the closest DC for authentication to clients. (More information on the Automatic Site Coverage can be found here - https://technet.microsoft.com/en-us/library/cc978016.aspx)

In this scenario the required behavior (and please note I say the required behavior and not expected behavior – that will be explained later) is for clients to authenticate to the Domain Controllers in the DR site in case the Domain Controllers in the Hub site have failed (or the site link from a specific Branch to the Hub site has failed).

So, we have clients located at a branch site relying on the Automatic Site Coverage feature of the Domain Controllers in order to find the closest DC.

In reality this would look similar to this:

Child-DC01 (located in the HUB site) is performing Automatic Site Coverage for Branch and Branch2 sites) while Child-DC02 which is located in the DR does not.

(Note: More information on the Automatic Site Coverage may be found here - https://technet.microsoft.com/en-us/library/cc978016.aspx)

Now comes the interesting part…

What happens when Child-DC01 fails?

So based on this https://support.microsoft.com/kb/314861 (and this https://technet.microsoft.com/en-us/library/cc759550(WS.10).aspx) the client would then fall-back to the generic list of all Domain Controllers in the domain:

So in our "simple" scenario (And I say simple cause there's more it in a second ) the client would failover to that list and will successfully find a Domain Controller in the domain. Now since the only option left available is the DC in the DR site - Child-DC02 we're good!

Now, you remember (well, it's just in the line above, if you don't then you have more serious things to worry about than this post… ) me saying there's more??

So here's more:

How do I make a domain controller failover to that DR site if I have a 3rd DC in another site?

So in this scenario we would have a Branch site, just as with the previous example – getting Auto site covered by the DC in the HUB site, but we also have a second Branch site, called Branch2 which does contain a DC (child-dc03) and the DRP site which contains child-dc02:

So in this scenario we need to consider costs. So considering BASL (Bridge All Site Links) is enabled – meaning all site links are transitive the following is the list of costs from the perspective of the branch site:

Branch –> Hub = 100

Branch –>  DRP = 110  This is because the site links are transitive and we combine the cost of Branch-> Hub and Hub-> DRP(100 + 10).

Branch –> Branch2 = 200 (Branch-> Hub and Hub-> Branch2 = 100+100).

So obviously we would prefer to go where it's cheaper (which eventually translate to WAN link bandwidth, latency and other decisions affecting cost selection).

But, based on what we have experienced previously the client would get all DCs from the DNS query, including child-dc03 to which we don't want the client to go.

Looking at a netmon trace the DNS result would be similar to:

This is the default netlogon DC locator behavior. If the DC in my client site (and DCs which Auto Site Cover are considered to be in my site) fail then we fallback to query the generic list of DCs for the domain (_ldap._tcp.dc._msdcs.domain.name)

So in order to resolve this situation we have the long ago mentioned solutions:

DnsAvoidRegisterRecords

As explained in the Branch Offices Guide (https://technet.microsoft.com/en-us/library/cc749944.aspx) we can prevent the domain controllers at the branch site from registering the generic SRV records.

The recommended configuration in a branch office deployment is as follows:

• On all branch office domain controllers, add all entries that do not have "AtSite" as part of the mnemonic, to the value of the registry key, except the DsaCname.

On hub domain controllers, do not use the registry key. This allows the domain controller to register all records.

Creating the registry key on the branch DC (child-dc03) with the value of:

Dc
Gc
Kdc
LDAP
Rfc1510Kdc
Rfc1510UdpKdc
Rfc1510Kpwd
Rfc1510UdpKpwd

Would result in having only the Hub and DR DCs (child-dc01 and child-dc02) listed in the generic list of Domain Controllers for the domain:

Which leaves the client with only one option if the Hub site DCs fail… the DR site DCs.

That's it for Part 1. In Part 2 we'll talk about failover scenarios for client sites which DO contain Domain Controllers, but those have failed.

Part 2 - https://blogs.technet.com/b/isrpfeplat/archive/2011/12/04/disaster-recovery-site-and-active-directory-part-2-of-3.aspx

Michael.

One picture is worth a thousand words, so what I’m trying to explain is this:

Unknown publisher?? I can’t install it for users, I want to deploy it silently…

Scenario #2 -

While browsing to a website you’re getting the UAC prompt (or not able to install) an ActiveX object.

So let’s start with the basics – Authenticode certificate. What is it?

There are two issues that must be addressed to make the Internet a reliable source for software:

Ensuring authenticity - Assures users that they know where the code came from.

Ensuring integrity - Verifies that the code hasn't been tampered with since its publication.

Microsoft's solution to these issues is Microsoft Authenticode coupled with an infrastructure of trusted entities. Authenticode, which is based on industry standards, allows developers to include information about themselves and their code with their programs through the use of digital signatures.

While Authenticode itself cannot guarantee that signed code is safe to run, Authenticode is the mechanism by which users can be informed of whether the software publisher is participating in the infrastructure of trusted entities. Thus, Authenticode serves the needs of both software publishers and users who rely upon the Internet for the downloading of software.

In simple words Authenticode is a technology used by developers to sign their applications in order to notify end users that it was written by them. In here comes the whole idea of certificates, trusted authorities etc' which eventually gets utilized in order to make sure the signer is indeed a valid company (For example a certificate issued for the name Microsoft issued by VeriSign does insure it is indeed Microsoft, while a certificate issued for the name Microsoft issued by MyHomeCA doesn't really ensure the code was written by Microsoft.. does it?).

How does the certificate looks like?

Basically the certificate in question is a code signing certificate and is used for "Ensures software came from software publisher" and "Protects software from alteration after publication". As it says in the certificate usage policies:

That's the certificate used to sign the ActiveX or the VSTO control we have showed in the previous pictures.

Signed vs. Non-signed

So why do we need this certificate?

Well, let's look at IE behavior trying to install a signed ActiveX and an unsigned ActiveX:

The IE page references the cab file using the following code:

<object name="secondobj" style='display:none' id='TestActivex'  
  classid='CLSID:A47C22B1-3CC3-45bc-801E-3FCC4FFD3E45' 
  codebase='/TestApp/mycab.cab#version=-1,-1,-1,-1'></object>

Now if mycab.cab is not signed using the Authenticode certificate the page received is:

User Account Control prompt stating the publisher is unknown. This may lead to the user declining the installation of the ActiveX component and the inability to silently install the component by using the ActiveX installer service.

As so clearly mentioned in the ActiveX installer service description - "Silent installation for unsigned controls is not supported"

On the other hand, if the mycab.cab file is signed the screen we'll see is:

Which looks much friendlier, and now that we trust the publisher it means we can use ActiveX installer service to silently install it.

But that's not the end of it.

Sometimes I may still receive the "unsigned" UAC prompt, although the ActiveX is properly signed. So why is that?

Windows WinTrust setting:

The WinTrust feature in windows is basically a group of code-signing and certificate management tools which applications can access in order to check for information.

This way Internet Explorer access the WinTrust APIs (thoroughly documented on MSDN) to verify whether we trust the certificate which used to sign the ActiveX or not.

The WinTrust itself has a registry setting which controls which certificates do we trust. This key is located under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\ and the Value is State (DWORD).

The State value is a hexa-decimal flag which may represent a combination of any of the following flags:

WTPF_TRUSTTEST            0x00000020
WTPF_TESTCANBEVALID       0x00000080
WTPF_IGNOREEXPIRATION     0x00000100
WTPF_IGNOREREVOKATION     0x00000200
WTPF_OFFLINEOK_IND        0x00000400
WTPF_OFFLINEOK_COM        0x00000800
WTPF_OFFLINEOKNBU_IND     0x00001000
WTPF_OFFLINEOKNBU_COM     0x00002000
WTPF_VERIFY_V1_OFF        0x00010000
WTPF_IGNOREREVOCATIONONTS 0x00020000
WTPF_ALLOWONLYPERTRUST    0x00040000

An explanation can be found at https://msdn.microsoft.com/en-us/library/aa388197(v=VS.85).aspx

So since the default setting of this value is 23c00 which means:

WTPF_OFFLINEOK_IND        0x00000400
WTPF_OFFLINEOK_COM        0x00000800
WTPF_OFFLINEOKNBU_IND     0x00001000
WTPF_OFFLINEOKNBU_COM     0x00002000
WTPF_IGNOREREVOCATIONONTS 0x00020000

We'll be checking the Certificate Revocation List, which in turn, if not accessible will revert to the state that we do not the certificate used to sign the code (because we can't verify whether it's still a valid certificate if we can't access the CRLs).

This registry key is controller by an IE setting as well:

Unchecking the "Check for publisher's certificate revocation" will modify the State registry to a value of 23e00 which is:

WTPF_IGNOREREVOKATION     0x00000200 – This flag is added.
WTPF_OFFLINEOK_IND        0x00000400
WTPF_OFFLINEOK_COM        0x00000800
WTPF_OFFLINEOKNBU_IND     0x00001000
WTPF_OFFLINEOKNBU_COM     0x00002000
WTPF_IGNOREREVOCATIONONTS 0x00020000

So having a valid certificate without the ability to verify it's CRLs is the same as having an invalid certificate!

What's there to do with ActiveX's?

As always that depends:

Talking about production environments – you would need to troubleshoot the reason why the authenticode checks performed by WinTrust are failing and the ActiveX is not treated as signed by a trusted publisher.

Another option you may have is reducing the requirements which are used by WinTrust in order to verify the certificate.

Important: This option is only valid for test environments, reducing the WinTrust requirements will have a huge impact on your organizations security!

After you have verified your ActiveX is properly signed you can use the ActiveX installer policy to silently install the ActiveX for your organizations website:

(You can find that under Group Policy –> Machine settings –> Administrative Templates –> Windows Components –> ActiveX Installer Service)

Talking about VSTO

When discussing Authenticode in regards to VSTO we'll be using the same WinTrust functionality as we did with IE ActiveX installation with one small difference. Since VSTO is .NET application we're also relying on the .NET trust manager feature.

So trying to install an un-signed VSTO in our case resulted in the following:

Which makes sense.

Now – just as with Internet Explorer, if the VSTO is signed, but we weren't able to verify CRLs (and we were required based on the WinTrust policy) we will receive the same error message.

The .NET specific requirements for  signing are required under the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Security\TrustManager\PromptingLevel

Looking at our specific setting we noted that we have MyComputer set to a value of AuthenticodeRequired (REG_SZ)

Which (by using common sense) requires an assembly to pass the Authenticode requirements (defined by WinTrust) in order to be installed from the MyComputer zone.

This is called the Inclusion List (more information can be found at https://msdn.microsoft.com/en-us/library/bb772070.aspx).

So what's there to do with VSTO?

Well, the first and best option is to identify why our certificate is not passing the WinTrust requirements.

We can get information about the certificate used to sign the VSTO  manifest by just opening the manifest by using notepad and we'll be able to identify the certificate which was used in order to sign the VSTO. In our case the certificate was issued to <publisherIdentity name="CN=Michael Dubinsky, OU=Accounts, DC=w2k8r2, DC=local" issuerKeyHash="a8c0a14c4d0c3a2fc0a17c0439d4166baa3e44cf" />.

You can also use the certutil –verify option. More information on that is available at https://blogs.technet.com/b/pki/archive/2006/11/30/basic-crl-checking-with-certutil.aspx

By using this information we'll be able to see if the certificate is in our Trusted Publisher store, and whether it corresponds to all the requirements as required by WinTrust.

Another option would be to modify the Inclusion List policy (in this example I could set the Inclusion list for MyComputer Zone to Enabled).

Or, after looking at the certificate I have noted that I wasn't trusting the Certificate Authority which has generated the Trusted Publisher certificate (w2k8r2-W2K8R2DC01-CA).

Adding this CA to the Trusted Root Certificate Authorities has resolved the issue and I was able to silently install.

That's the story of Authenticode and digital signing.

Hopefully that would make some compatibility issues more understandable and easier to resolve.

Until next time,

Michael.

Hello world! This is Moti. Just as Michael and Guy, I am a member of the Israel PFE team, specializing in Performance/Internals, Remote Desktop and Failover Clustering.

I have been working recently on a case and came across an interesting performance behavior of SQL server installed with SCCM server. It appeared that the server (with 12 GB of RAM) was short on available memory, despite the fact that it was idle most of the time.

I used RAMMAP from Sysinternals, advanced physical memory usage analysis utility, and found out the largest block of memory was AWE. AWE allows a 32-bit software to manipulate physical memory greater than 4GB, and is used mostly by database applications, like SQL server.

But this is a x64 server! There is no need for AWE. So I checked SQL server memory properties and noticed that “use AWE” was not selected.

I launched WinDbg as kernel-mode debugger and checked if sqlserver.exe is indeed using AWE by using this command: dt NT!_EPROCESS <address of sqlserver.exe> AweInfo. If the process is not using AWE this values should be NULL, but I found a value. Another test was stopping SQL server service, and the result in RAMMAP showed that AWE is empty when SQL server was stopped, and AWE section was growing fast when the SQL server service was started.

OK, so we have found the culprit, but why is the SQL server using AWE ? It turns out that when you select the option to “lock pages in memory” on x64 bit systems, SQL Server will use AWE API calls that are more efficient for memory allocations than the standard API memory allocation calls.

Proof that the GUI sometimes tells you just a part of the story ;)

Moti

Disappeared attribute ? How that can happen ? I mean, either the attribute is in the schema or not, and there is no way to delete something from schema. The only option available to prevent attribute from being used is to defunct it, effectively making it impossible to use the attribute. The only way to do that, that I was aware till now, was to set isDefunct attribute of the schema object to True (given that it is not used by another active schema object), but you live and learn and sometimes your assumptions turn out to be not quite correct. Here is a story of a case I was involved in, where we had a customer loosing an attribute without setting its isDefunct to True.

Customer was trying to make user pictures available in the GAL using the instructions in the following blog post. The only caveat was that the customer did not run forestprep to extend the AD schema to W2K8 or W2K8 R2 version, which is a requirement for the Picture attribute to become available in the GAL. If you do some research, you will actually find that W2K8 schema extension has the following in Sch40.ldf file:

 1: dn: CN=Picture,CN=Schema,CN=Configuration,DC=X

 2: changetype: ntdsSchemaModify

 3: replace: mapiId

 4: mapiId: 35998

 5: -

What this particular part does is to set the mapiId attribute of Picture classSchema object in the Schema to the value of 35998.

“Well, if that is the only requirement needed for the change, why do I need to run the forestprep ?” – the customer asked himself and started looking for ways to perform this single change without rolling out fully blown W2K8/R2 schema extension. Now that IS dangerous, as we are dealing here with the base schema, which is expected to be modified only by controlled procedures and tools shipped by the base AD schema owner (read: “forestprep by Microsoft”) and if you change something, forestprep comes in later and overrides whatever you changed and you loose data or functionality, you will find yourself in the position where you can blame only yourself. Right… We warned you. Remember all those disclaimers that things might break ? Well, this is how that can happen.

At that point the customer decides that he manually edits the schema (should I repeat myself and remind that editing base schema objects is a bad idea ?) and tries to edit the “CN=Picture,CN=Schema,CN=Configuration,DC=X” attributeSchema object and set mapiId attribute to 35998, but is faced with a nice dialog from ADSIEDIT that informs that the attribute is owned by System and can not be edited:

Remember those Category 1 schema objects ? Well, thumbnailPhoto (aka Picture) attribute is Category 1 schema object:

But that does not scare our customer and he digs the net and discovers the “s c h e m a U p g r a d e I n P r o g r e s s” trick (the spaces are intentional. Just another step to make it harder for people to shoot themselves in the foot)… Now let me tell you something about that functionality: You should never ever use it. It is dangerous as it relaxes a number of restrictions and consistency checks that are performed during schema modifications. If you come to a conclusion that this is your only option, do yourself a favor and open a support incident with our customer support, or else, you might get into the situation where your only option would be a full forest recovery. Let me repeat myself: FULL FOREST RECOVERY.

And this is where things went wrong… Customer used the above mentioned trick and accidentally set mapiID attribute to 35998 on 2 objects:

• CN=Picture
• CN=MAPI-ID

See the irony ? MAPI-ID attributeSchema object in the schema has an attribute mapiId. So basically the attribute kind of describes itself:

Want to guess what happens when two attributes in the schema have the same MapiId ?

Here we go:

Huston, we have a problem ! We have two attributes auto-defuncted because of the MapiID collision. But hey, the event ID is providing us a solution: defunct one of those two attributes and you are done. Well… there is a catch: you can’t defunct an attribute that is used by schema classes and as it happens, this is the case for both attributes in question.

So what are our options ? Well… roughly we have to perform the following surgery:

1. Identify the attribute that is used less in the schema (we do want to minimize the schema changes)
   • Selecting thumbnailPhoto (CN=Picture,CN=Schema,CN=Configuration,DC=X) is quite natural as MapiID is used all over the board
2. Find in what classes the attribute is used and save this information (we will need it later)
   
   
   • To identify the classes you can use the following queries:
     
     

     C:\>dsquery * "cn=schema,cn=configuration,dc=w2k8r2,dc=local" -filter "systemMayContain=2.16.840.1.113730.3.1.35" "CN=Organizational-Person,CN=Schema,CN=Configuration,DC=w2k8r2,DC=local" C:\>dsquery * "cn=schema,cn=configuration,dc=w2k8r2,dc=local" -filter "mayContain=2.16.840.1.113730.3.1.35" C:\>dsquery * "cn=schema,cn=configuration,dc=w2k8r2,dc=local" -filter "mustContain=2.16.840.1.113730.3.1.35" C:\>dsquery * "cn=schema,cn=configuration,dc=w2k8r2,dc=local" -filter "systemMustContain=2.16.840.1.113730.3.1.35" C:\>

   • As my lab environment has only vanilla W2K8R2 schema, you will notice that only organizationalPerson object class is using the thumbnailPhoto attribute, but if you run this against a forest with Exchange schema, you will notice that also the group object class has thumbnailPhoto in mayContain.
3. Use the “s c h e m a U p g r a d e I n P r o g r e s s” trick (instructions NOT included)
4. Remove the attribute from mayContain/mustContain/systemMayContain/systemMustContain of the classes we found in [2]
5. Defunct the thumbnailPhoto attribute
   
   

   dn: CN=Picture,CN=Schema,CN=Configuration,DC=X changetype: ntdsSchemaModify replace: isDefunct isDefunct: TRUE -

   
   Side note: when an attribute is defuncted, the information stored in the attribute is not lost, so if you have already populated thumbnailPhoto attribute, after you bring it back to life, you will have the values back on the objects
6. Resolve the MapiID conflict by altering the MapiID attribute of MapiID attributeSchema object
   
   

   dn: CN=MAPI-ID,CN=Schema,CN=Configuration,DC=X changetype: ntdsSchemaModify replace: MapIID MapiID: 32974 - dn: CN=Picture,CN=Schema,CN=Configuration,DC=X changetype: ntdsSchemaModify replace: MapIID MapiID: 35998 - DN: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 -

7. Un-defunct thumbnailPhoto attribute
   
   

   dn: CN=Picture,CN=Schema,CN=Configuration,DC=X changetype: ntdsSchemaModify replace: isDefunct isDefunct: FALSE -

     
8. Update the schema cache
   
   

   DN: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 -

9. Add thumbnailPhoto attribute back to the classes we removed it from at [3]
   
   

   dn: CN=Organizational-Person,CN=Schema,CN=Configuration,DC=X changetype: ntdsSchemaModify add: systemMayContain systemMayContain: thumbnailPhoto - dn: CN=Group,CN=Schema,CN=Configuration,DC=X changetype: ntdsSchemaModify add: mayContain mayContain: thumbnailPhoto -

10. Update the schema cache:
    
    

    DN: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 -

11. Pray to the schema gods (this part is crucial )
12. Verify the results:
    
    

    Expanding base 'CN=Picture,CN=Schema,CN=Configuration,DC=w2k8r2,DC=local'... Result <0>: (null) Matched DNs: Getting 1 entries: >> Dn: CN=Picture,CN=Schema,CN=Configuration,DC=w2k8r2,DC=local                 2> objectClass: top; attributeSchema;                 1> cn: Picture;                 1> distinguishedName: CN=Picture,CN=Schema,CN=Configuration,DC=w2k8r2,DC=local;                 1> instanceType: 0x4 = ( IT_WRITE );                 1> whenCreated: 10/23/2002 03:50:19 Jerusalem Standard Time Jerusalem Daylight Time;                 1> whenChanged: 01/24/2011 14:52:45 Jerusalem Standard Time Jerusalem Daylight Time;                 1> uSNCreated: 4876;                 1> attributeID: 2.16.840.1.113730.3.1.35;                 1> attributeSyntax: 2.5.5.10;                 1> isSingleValued: TRUE;                 1> rangeLower: 0;                 1> rangeUpper: 102400;                 1> mAPIID: 35998;                 1> uSNChanged: 12157493;                 1> showInAdvancedViewOnly: TRUE;                 1> adminDisplayName: Picture;                 1> adminDescription: Picture;                 1> oMSyntax: 4;                 1> searchFlags: 0;                 1> lDAPDisplayName: thumbnailPhoto;                 1> name: Picture;                 1> objectGUID: 85e62def-5ba7-4f4e-9539-64d18246582b;                 1> schemaIDGUID: 8d3bca50-1d7e-11d0-a081-00aa006c33ed;                 1> attributeSecurityGUID: 77b5b886-944a-11d1-aebd-0000f80367c1;                 1> systemOnly: FALSE;                 1> systemFlags: 0x10 = ( FLAG_SCHEMA_BASE_OBJECT );                 1> isMemberOfPartialAttributeSet: TRUE;                 1> isDefunct: FALSE;                 1> objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=w2k8r2,DC=local;                 2> dSCorePropagationData: 01/18/2011 18:16:28 Jerusalem Standard Time Jerusalem Daylight Time; 1/1/1601 2:0:1 Jerusalem Standard Time Jerusalem Daylight Time; Expanding base 'CN=Mapi-ID,CN=Schema,CN=Configuration,DC=w2k8r2,DC=local... Result <0>: (null) Matched DNs: Getting 1 entries: >> Dn: CN=Mapi-ID,CN=Schema,CN=Configuration,DC=w2k8r2,DC=local                 2> objectClass: top; attributeSchema;                 1> cn: MAPI-ID;                 1> distinguishedName: CN=MAPI-ID,CN=Schema,CN=Configuration,DC=w2k8r2,DC=local;                 1> instanceType: 0x4 = ( IT_WRITE );                 1> whenCreated: 10/23/2002 03:50:16 Jerusalem Standard Time Jerusalem Daylight Time;                 1> whenChanged: 01/24/2011 14:52:43 Jerusalem Standard Time Jerusalem Daylight Time;                 1> uSNCreated: 4461;                 1> attributeID: 1.2.840.113556.1.2.49;                 1> attributeSyntax: 2.5.5.9;                 1> isSingleValued: TRUE;                 1> mAPIID: 32974;                 1> uSNChanged: 12157489;                 1> showInAdvancedViewOnly: TRUE;                 1> adminDisplayName: MAPI-ID;                 1> adminDescription: MAPI-ID;                 1> oMSyntax: 2;                 1> searchFlags: 0;                 1> lDAPDisplayName: mAPIID;                 1> name: MAPI-ID;                 1> objectGUID: 9cc0d7fa-822a-44e4-a891-eca43c55ddb0;                 1> schemaFlagsEx: 1;                 1> schemaIDGUID: bf9679b7-0de6-11d0-a285-00aa003049e2;                 1> systemOnly: TRUE;                 1> systemFlags: 0x10 = ( FLAG_SCHEMA_BASE_OBJECT );                 1> objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=w2k8r2,DC=local;                 2> dSCorePropagationData: 01/18/2011 18:16:27 Jerusalem Standard Time Jerusalem Daylight Time; 1/1/1601 2:0:1 Jerusalem Standard Time Jerusalem Daylight Time;

13. Done…

Bottom line: NEVER EVER perform changes like this directly in the production environment. Test, test, test and it will save you a lot of grief if/when something goes wrong…

Till next time,
GuyTe

That's just a short post while I'm working for a longer one.

A couple of days ago I was debugging an application, and I wanted to set a breakpoint for the DsGetDCName function to figure out the flags being passed to the function – (https://msdn.microsoft.com/en-us/library/ms675983(VS.85).aspx)

and while in the MSDN help in says it's in the netapi32.dll the query in the debugger didn't show it to actually be there:

0:000> bp netapi32!DsGetDCName
Couldn't resolve error at 'netapi32!DsGetDCName'

So after some digging and a lot of step overs eventually I found out that the DsGetDCName function was moved to the logoncli.dll!

So in order to break on the DsGetDCName you need to setup a breakpoint for logoncli!DsGetDCName

0:000> bp logoncli!DsGetDCNameW
0:000> bl
0 e 73a74ca8     0001 (0001)  0:**** LOGONCLI!DsGetDcNameW

That's it…

Hopefully it will save time for someone in the future

Michael.

The main purpose of this post is to present the LDAP_MATCHING_RULE_BIT_AND control, and how to use it when querying those bitwise flags in attributes.

Let look at the UserAccountControl attribute for example, this attribute controls the behavior of the user account.

In the msdn page describing the attribute you can find a full list of all possible flags for the attribute (https://msdn.microsoft.com/en-us/library/ms680832(VS.85).aspx).

Let’s look at some of the flags:

0x00000200 ADS_UF_NORMAL_ACCOUNT This is a default account type that represents a typical user.

0x00010000 ADS_UF_DONT_EXPIRE_PASSWD The password for this account will never expire.

0x00000002 ADS_UF_ACCOUNTDISABLE The user account is disabled.

Now let’s say we have a normal user account (userAccountControl flag set to 0x200 which is 512 decimal) which looks like this:

And then we set the password never expires flag (which is 0x10000), so together we’ll get 0x10200 (which is 66048 decimal). This would look something like the following:

So now the interesting part starts – if we also disable the account we will get the value of 0x10000 + 0x200 + 0x2= 0x10202 (66050 decimal).

Right, so far so good… now i want to query all user accounts in the domain set with password never expires flag (regardless if they are enabled or disabled)….

Huh??? query what??? why??? no… sorry… well…. hmmmm…. (sounds like a proper response to such a request, wouldn’t it? :) ).

While making all this sounds and vowels the thoughts going inside the head are: “Querying for userAccountControl=66048 wouldn’t get the disabled accounts, while querying for 66050 wouldn’t get the enabled accounts.”

So what’s the solution to the problem??

Query the specific BIT you want!

Active Directory provides a control in order to query specific bits of a flag - 1.2.840.113556.1.4.803 (LDAP_MATCHING_RULE_BIT_AND).

Constructing the query is easy, you just have to query the attribute (userAccountControl) with the flag you need (ADF_UF_DONT_EXPIRE_PASSWD – 0x10000 in decimal – 65536).

So using the provided example I will be able to query for all accounts with password never expires flag set by the following LDAP query - (&(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=65536))

How do you do that using a script?

Here’s a sample powershell script:

$strFilter = "(&(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=65536))"
$objDomain = New-Object System.DirectoryServices.DirectoryEntry
$objSearcher = New-Object System.DirectoryServices.DirectorySearcher
$objSearcher.SearchRoot = $objDomain
$objSearcher.Filter = $strFilter
$objSearcher.SearchScope = "Subtree"
$colResults = $objSearcher.FindAll()
foreach ($objResult in $colResults)
    {$objResult.path}

Hope this helps in querying the BITWISE attributes

Thank you all for attending my Session.. hope you had fun :-)

Here’s a list of all references on the topics i’ve been discussing:

1. New AD Features:

a. Recycle Bin - https://technet.microsoft.com/en-us/library/dd392261(WS.10).aspx

b. Recycle Bin - https://blogs.technet.com/b/qzaidi/archive/2010/10/23/quickly-explained-active-directory-recycle-bin.aspx

c. AD Module for Powershell - https://technet.microsoft.com/en-us/library/dd378937(WS.10).aspx

d. AD Web Services - https://blogs.msdn.com/b/adpowershell/archive/2009/04/06/active-directory-web-services-overview.aspx

e. Managed Service Accounts - https://blogs.technet.com/b/askds/archive/2009/09/10/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting.aspx

f. Fine Grained Password Policies - https://technet.microsoft.com/en-us/library/cc770842(WS.10).aspx

2. AD Replication

a. How AD Replication works - https://technet.microsoft.com/en-us/library/cc772726(WS.10).aspx

b. How DC are located in Windows - https://support.microsoft.com/kb/247811

c. Finding DCs in closest site - https://technet.microsoft.com/en-us/library/cc978016.aspx

d. Subnet to Site mapping - https://support.microsoft.com/kb/889031

e. Enabling Inter-Site change notifications - https://blogs.technet.com/b/qzaidi/archive/2010/09/23/enable-change-notifications-between-sites-how-and-why.aspx

f. Tombstone Lifetime events - https://technet.microsoft.com/en-us/library/cc757610(WS.10).aspx

g. Information about lingering objects - https://support.microsoft.com/kb/910205

h. Fixing Lingering objects problems - https://technet.microsoft.com/en-us/library/cc738018(WS.10).aspx

3. DC Virtualization

a. How to Virtualize DCs – Part 1 - https://blogs.technet.com/b/askds/archive/2010/06/15/how-to-virtualize-active-directory-domain-controllers-part-1.aspx

b. How to Virtualize DCs – Part 2 - https://blogs.technet.com/b/askds/archive/2010/06/15/how-to-virtualize-active-directory-domain-controllers-part-2.aspx

c. Planning considerations for Virtualized DCs - https://technet.microsoft.com/en-us/library/dd348476(WS.10).aspx

d. Things to consider when hosting virtual DCs - https://support.microsoft.com/kb/888794

4. Group Policy features

a. Managing ADMX files - https://technet.microsoft.com/en-us/library/cc709647(WS.10).aspx

b. How to create a Central Policy store - https://support.microsoft.com/kb/929841

c. Group Policy Preferences - https://technet.microsoft.com/en-us/library/dd367850(WS.10).aspx

d. Group Policy Preferences – Getting Started - https://technet.microsoft.com/en-us/library/cc731892(WS.10).aspx

e. Policy vs. Preferences vs. GP Preferences - https://blogs.technet.com/b/grouppolicy/archive/2008/03/04/gp-policy-vs-preference-vs-gp-preferences.aspx

d. 2003/XP/Vista Preferences Client Side Extension download - https://support.microsoft.com/?id=943729

5. Advanced Group Policy Management Console (AGPM)

a. AGPM Overview - https://technet.microsoft.com/en-us/library/cc749396(WS.10).aspx

b. AGPM 4.0 Home - https://technet.microsoft.com/en-us/library/ee382452.aspx

6. Monitoring

a. AD Management Pack download (includes documentation) - https://www.microsoft.com/downloads/details.aspx?FamilyID=008F58A6-DC67-4E59-95C6-D7C7C34A1447&amp;displaylang=fr&displaylang=en

b. Monitoring AD detailed explanation (older version) - https://technet.microsoft.com/en-us/library/bb727046.aspx

c. SCOM Home - https://www.microsoft.com/systemcenter/en/us/operations-manager.aspx

That oughta keep you guys busy reading for a while… feel to come back for more :-)

-Michael.