New dimension for AD – A Lap around Windows Azure Active Directory

June 30, 2012

Windows Azure Active Directory (WAAD) is the conceptual equivalent in the cloud of Windows Server Active Directory (WS AD), and is integrated with WS AD itself. In this session, developers, administrators, and architects gain a high-level overview of WAAD, covering functional elements, supported scenarios, and an end-to-end tour, plus a roadmap for the future. #TESIA209

Rerference: Tech Ed 2012 – North America

Software Architecture- System.DirectoryService – Improve the performance of AD access

April 30, 2012

Case Study: Currently Directory service library is implemented via System.DirectoryService
What is how can we improve the performance of AD access?
Solution: using System.DirectoryService.Protocol and VLV
Important Points:
>>VLV work really well when you want to do a one-level search of an OU. In other cases it gives wrong total count and is not super fast.
>>Using the System.DirectoryServices namespace should be avoided it due to heavy pollution of ADSI COM weirdness, and a variety of other performance and flexibility reasons — preferring instead to use System.DirectoryServices.Protocols wherever possible.
>>Total number of record estimate is calculated accurate till 10,000 limit. Incase of VLV records are normally fetched as sliding window to, it works in most of the cases.
>> Multiple types of indexes can be created on same field.
>> Can we force client to create related to indexes, can affect other applications because of it.!!
Must Read:
Summary of Sample Data is at:
(With thanks to Steve Kradel)
Ways out:
1 Porting our architecture to System.DirectoryServices.Protocols then implement VLV based in the new namespace.

a, More efficient in terms of performance
b, More stable
a, Major redo of directory Service library is required.
2 Continuing to integrate System.DirectoryService based VLV to application.
a, It is the current implementation. So need little afford to implement VLV.
a, Not very efficient in terms of performance and stability.

Conclusions :
1. Wrong Total Count:
Wrong number of total count is well known problem in searching domain.
Even in Google searching show the estimate number of pages. While searching, sometimes when you click on last pages, it shown nothing records and a custom message is shown. Basically in order to show fast results, search engine use approximation for total number of pages.
So paging can be shown on basis of estimate. When user clicks (try to go) on bad page (that does not exist) a user friendly message can be shown.
2. Navigation Style:
Navigation should be such that user moves from ou to ou and objects from only one ou are shown at time. In this way we can avoid the limitation of sub-tree search at a time. This type of navigation suits in most of the applications.
3. A warm up search with exact ldap query returning one record can serve the purpose of getting right number of records. It can solve the problem on getting right number of records. (A suggestion given by Steve Kradel [email: ] )
4. A index creator screen is proposed that can help product admin to create and manage index for searching.
A careful and well analyzed index is very critical for performance of application. A bad index can kills the performance of other applications too.
Code of POC will be loaded soon.
Related Error:
“LDAP_UNAVAILABLE_CRIT_EXTENSION 0x0c Critical extension is unavailable.”

Software Architecture – To find lockedout users from active directory

August 6, 2011

Objective : To find lockedout users from active directory

General Implementation:
Generally LDAP filter for getting Lockout accounts list is as:
Where 4294967295 is the highest number you can get using 32 bits (Binary digits)
11111111111111111111111111111111 = 4,294,967,295
FFFFFFFF = 4,294,967,295

1.2.840.113556.1.4.804 is the LDAP_MATCHING_RULE_BIT_OR rule. The matching rule is true if any bits from the property match the value. This rule is like the bitwise OR operator.

LockoutTime is AD attribute which is the date and time (UTC) that this account was locked out. This value is stored as a large integer that represents the number of 100-nanosecond intervals since January 1, 1601 (UTC). A value of zero means that the account is not currently locked out.
So (lockoutTime:1.2.840.113556.1.4.804:=4294967295) means fetch those entries which has any date time value in form of large integer.
However searching for any accounts that have a value for lockouttime is not an accurate method to use because an account is determined to be locked out if the CurrentTime – lockouttime exceeds the Lockout Duration.
It is only upon a successful logon that AD sets the value of lockouttime to zero, so it is possible for an account to still contain a value for lockouttime, yet the account is not locked.

The correct LDAP filters with a dynamic calculation based on Active Directory Account Lockout policy.
To determine the users that are currently locked out, you have to query the lockoutDuration attribute stored on the domain object (e.g., dc=rallencorp,dc=com). This attribute defines the number of minutes that an account will stay locked before becoming automatically unlocked. You need to take this value and subtract it from the current time to derive a timestamp that would be the outer marker for which users could still be locked. You can then compare this timestamp with the lockoutTime attribute of the user object. The search filter to find all locked users once you’ve determined the locked timestamp would look something like this:


For any users that have a lockoutTime that is less than the derived timestamp, their account has already been automatically unlocked per the lockoutDuration setting.

Where DerivedTimestamp = ( Now-LockoutDurationFromDomainPolicy)
[While accounting for local time zones and daylight savings time.]

So in this way, we can avoid problem in previous ldap filter.

Use of Windows Time Service Tool named W32tm.exe for diagnostic purpose to Convert an NT system time, in (10^-7)s intervals from 0h 1-Jan 1601, into a readable format as below.

w32tm /ntte

Class for getting the domain policy will be as:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.DirectoryServices;

namespace MyDirectoryServices.MyDirectory

     This class get the domain poilcy from domain controller
     All policy attributes can be get via that.
     Make a public property and user it, as done for LockoutDuration

    public enum PasswordPolicy

    public class DomainPolicy
        public static string pLockoutTime = "lockoutTime";
        public static string pLockoutDuration = "lockoutDuration";
        public const long pNeverExpireConstant = 9223372036854775807;  // Used for AD attribute accountexpire, to show as never expires value
        ResultPropertyCollection attribs;

        public DomainPolicy()
            // hardcoded domain name
            String pathRootDSE = String.Format("LDAP://softcom.imanami.lab");
            DirectoryEntry dse = new DirectoryEntry(pathRootDSE);
            //properties to fetch
            string[] policyAttributes = new string[] {
                  "lockoutDuration", "objectClass", 

            DirectorySearcher ds = new DirectorySearcher(

            // search
            SearchResult result = ds.FindOne();

            //do some quick validation...							  
            if (result == null)
                throw new ArgumentException(
                  "domainRoot is not a domainDNS object."

            this.attribs = result.Properties;

        //for some odd reason, the intervals are all stored
        //as negative numbers. We use this to "invert" them
        private long GetAbsValue(object longInt)
            return Math.Abs((long)longInt);

        /// <summary>
        /// LockoutDuration of domain policy
        /// </summary>
        public TimeSpan LockoutDuration
                string val = pLockoutDuration;
                //this should fail if not found
                var value = this.attribs[val][0];
                if (value == null)
                    return TimeSpan.MinValue;

                var result = (long)value;
                if (result == pNeverExpireConstant || result == 0)
                    return TimeSpan.MaxValue;

                var finalResult = TimeSpan.FromTicks(result);
                return finalResult;

The code to get list of locked out accounts will be as:

 DomainPolicy dc = new DomainPolicy();
            // Print LockoutDuration from domain policy
            Console.WriteLine(" lockout" + dc.LockoutDuration);

            // get difference timestamp 
            DateTime dateTimeStamp = DateTime.Now.Subtract(-dc.LockoutDuration);

            // Hard coded domain name
            String pathRootDSE = String.Format("LDAP://dc=softcom,dc=imanami,dc=lab");

            DirectoryEntry dse = new DirectoryEntry(pathRootDSE);

            // list of properties to fetch
            string[] policyAttributes = new string[] {
            "distinguishedName" , "cn","lockoutTime"

            // filter to search the items
            string filterString = string.Format("(&(objectCategory=Person)(objectClass=user)(lockoutTime>={0}))", dateTimeStamp.ToFileTimeUtc().ToString());

            DirectorySearcher ds = new DirectorySearcher(

            SearchResultCollection result = ds.FindAll();

            // loop n print users
            foreach (SearchResult item in result)
                Console.WriteLine("Item: " + item.Properties["cn"][0].ToString() + " " + item.Properties["distinguishedName"][0].ToString() + " " + item.Properties["lockoutTime"][0].ToString());

Happy exploring AD related application architecture.