Recently, I was working on a scenario where I was trying to update the attributes of ADAM objects. If I clear an attribute value which is null and then I call CommitChanges on the object, it gives me an exception :

0x8007200a (The specified directory service attribute or value does not exist)

Here is the code sample which I was trying:

DirectoryEntry de = new DirectoryEntry("LDAP://localhost:50002/CN=TestUser,CN=Roles,CN=Partition1,DC=MyWorld,DC=COM");　　　　
de.Properties["otherHomePhone"].Clear();　　　　　　　　　　　
de.Properties["otherHomePhone"].Add("12345");
de.CommitChanges();

After doing some research on it, I found that this behavior is seen because ADSI doesn’t send the control LDAP_SERVER_PERMISSIVE_MODIFY_OID [ http://msdn.microsoft.com/en-us/library/aa366984(VS.85).aspx ] for ADAM or any third party LDAP servers. This control modifies the default behavior of ldap_modify_ext function which by default doesn’t allow the deletion of an attribute value that is not set.

So If you do not want to fall into this scenario, just check for the null before calling CommitChanges on the object.

DirectoryEntry de = new DirectoryEntry("LDAP://localhost:50002/CN=TestUser,CN=Roles,CN=Partition1,DC=MyWorld,DC=COM");
if (de.Properties["otherHomePhone"].Count > 0)
{
   de.Properties["otherHomePhone"].Clear();
}
de.Properties["otherHomePhone"].Add("12345");
de.CommitChanges();

ADAM running on Windows 7/ Vista/ 2008 or 2008 R2 does not exhibit this behavior. However, the workaround will function against all instances of ADAM running on any windows operating system.

 

 

The articles you have seen so far on this blog have been largely demonstrations.  When one of our customers asks us how they can do something, such as programmatically creating group policies, we write them some sample code that shows them how to do whatever they have in mind.  However, not all problems can be solved by demonstration.    We answer the question, “can you do this in Windows” by actually showing you how to do it.  Think back to geometry -- you probably have heard at some point that you cannot “square the circle” -- just using a compass and a straightedge, make a square that has the same area as a circle.  Yet, how could you prove this?

 

Sometimes, certain things aren’t possible to achieve in code, given certain constraints, and we won’t be able to provide a sample that will do the impossible.  How can we prove that a particular task, given certain constraints, is impossible?  One method is reductio ad absurdum, or proof by contradiction.  Start by assuming that something is possible, and then show that from this assumption that something results that is clearly impossible -- that, just by inspection, couldn’t possibly happen.

 

Wouldn’t you like to know who had changed a particular attribute in the Active Directory?   We could hold someone accountable for a mistake, or praise them for making a timely change.   The Active Directory is an RFC 3377 compliant LDAP directory server (for more information, see the article:   Active Directory's LDAP Compliance), but the standard does not define a security model.   In the Microsoft implementation, every object is protected by a security descriptor (see:  http://msdn.microsoft.com/en-us/library/aa746428(VS.85).aspx).  Ultimately, security in the Windows world is role-based -- the highest level of authorization to alter properties of the system is designed to be shared by multiple users, each maintaining their own secret password.   If a particular object is protected by being owned only by this highest level, then we can be sure (barring physical compromise of the system or its secrets, of course), that only one of the persons having that role have made the change.  Yet, is it possible to go deeper, to know exactly which one of the uses has done the deed?

 

Suppose that you could actually determine which particular user has made a specific change to an Active Directory object.  Suppose that the database that acts as the data store for Active Directory, the Extensible Storage Engine (ESE), actually maintained a record of the security descriptor of the user that made the change -- and that even though there is no “who changed” attribute, there was some record in the DIT file of who that Security Principle was.  This is our assumption.  From making the assumption, I’m going to demonstrate that a “who changed” attribute is actually impossible without making changes at every domain controller.

 

Remember that Active Directory is a distributed database.  A change made at one domain controller will be propagated, in accord with the enterprises’ replication schedule, to all other domain controllers.  Microsoft treats information that travels “across a wire” in a very special way.  We disclose it fully.  Here (http://msdn.microsoft.com/en-us/openspecifications/default.aspx) is the portal for these Open Specifications, and you can see that the WSPP (Windows Server Protocols) contain a discussion of what domain controllers do when they talk to one another.  When you examine the replication protocol, you see the sum total of what is transferred with regard to the information in Active Directory is described by the schema.  There is no place for the information to hide.  Even if there was some trace in the ESE, that trace couldn’t move from place to place.

 

You may have seen some programs that could create reports that did distinguish between different users, holding the same security role, changing an attribute in Active Directory.  How could such programs possibly work, if there is no “who changed” attribute?  How have they managed to square this circle?  What they have done is go beyond Active Directory, to augment its functioning.  They aren’t accessing something that is there, but hidden -- they are importing an entirely new functionality.  This functionality comes with some costs, and some limitations.  There are several places where Microsoft provides a way to augment the directory.  The Password Change Notification Service (http://technet.microsoft.com/en-us/library/cc720654(WS.10).aspx) is an example.  If you install a service on EVERY domain controller in the domain, the service will signal the identity integration server that this has happened.  This is an example of a password filter (http://msdn.microsoft.com/en-us/library/ms721882(VS.85).aspx). 

 

In the case of arbitrary LDAP calls, however, there isn’t a predefined hook into the functioning of the wldap32.dll, as we see with password filters.  If you wanted to add a “who changed” attribute, you would have to create your own hook.  One way to do so would be the Detours library (http://research.microsoft.com/en-us/projects/detours/) from Microsoft Research, which you can incorporate into a program without charge for experimentation, and is licensed for commercial products.  It will let you hook into every LDAP call on the machine, and the code in your service will be responsible for updating the “who changed” attribute. Note that this process will need to be installed on every domain controller in the domain.  You would need to extend the schema of Active Directory for every attribute that you want to track, so that the information about who changed it can be distributed to the other domain controllers.

 

A caution, however, in relying upon any “who changed” attribute that a program creates in this fashion.  If the way in which the “who changed” service functions is known to the Domain Administrators (if they could use Bing, say, and find the code in a blog post for the “who changed” service), they would be able to impersonate the specific identity of any of the other Domain Administrators in making a change, by changing the attribute directly in the same way in which the service would have changed the attribute.  There is no way of guarding the guardians in role-based security, if there is a lack of trust in the final guardians.  This fact (http://en.wikipedia.org/wiki/Quis_custodiet_ipsos_custodes) has been known for quite some time.

 

 

WMI provides two very useful Resultant Set of Policy (RSOP) classes that can be used together to determine the current set of GPOs that are applied to the local machine.

 

The RSOP_GPO class provides information about GPOs that could be applied to your machine.    Instances of this class are divided into three categories:

 

1. Instances that represent applied GPOs
2. Instances that represent GPOs that have read-access but not applyGroupPolicy access
3. Instances that represent disabled GPOs.

 

The following MSDN link provides more information about the RSOP_GPO class:

 

http://msdn.microsoft.com/en-us/library/aa374918(VS.85).aspx.

 

The RSOP_GPLink WMI class represents the links from a site, domain, organizational unit, or local scope, to one or more GPOs. All the links from the current scope of management (SOM), including those that have been disabled.   The RSOP_GPLINK class is documented at the following MSDN link:

 

http://msdn.microsoft.com/en-us/library/aa374916(VS.85).aspx

 

Notice the “appliedOrder” property.  This property will contain either and integer value that represents the order in which the GPO was applied or the value of 0 which indicates that the GPO was either not linked or not applied.

 

Using these two classes together, one can determine the actual list of GPOs that are applied to the local machine.  The process is very straight forward:

 

1. Perform a WMI query on the RSOP namespace to return only those RSOP_GPLINK objects that have an “appliedOrder” value that is non 0.
2. Build a dictionary from the results of the query, building the key name for the GPO.
3. Walk the dictionary, querying the namespace for the matching RSOP_GPO class objects.

 

The following Visual Basic Script (VBS) illustrates how to implement the 3 steps listed above:

    strComputer = "."
    
    ' Step1: Execute the WMI query to retrieve the matching RSOP_GPLink objects:
    ' and create the dictionary.
    ' 
    
    Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\rsop\computer")
    Set colItems = objWMIService.ExecQuery("Select GPO From RSOP_GPLink Where AppliedOrder <> 0")
    Set dict = CreateObject("Scripting.Dictionary")


    '
    ' Step 2: Load the dictionary with the query results.
    ' 

    For Each objItem in colItems  
            dict.Add Replace(objItem.GPO, "RSOP_GPO.", ""), Replace(objItem.GPO, "RSOP_GPO.", "")
    Next
 

    '
    ' Step 3: Walk the dictionary, and query the repository for the RSOP_GPO objects that have been 
    'applied to the local machine and display its properties.
    '

    For Each vItem In dict.Items
            Set colItems = objWMIService.ExecQuery("Select * from RSOP_GPO where " & vItem)
            For Each objItem in colItems  
                        Wscript.Echo "Name: " & objItem.Name
                        Wscript.Echo "GUID Name: " & objItem.GUIDName
                        Wscript.Echo "ID: " & objItem.ID
                        Wscript.Echo "Access Denied: " & objItem.AccessDenied
                        Wscript.Echo "Enabled: " & objItem.Enabled
                        Wscript.Echo "File System path: " & objItem.FileSystemPath
                        Wscript.Echo "Filter Allowed: " & objItem.FilterAllowed
                        Wscript.Echo "Filter ID: " & objItem.FilterId
                        Wscript.Echo "Version: " & objItem.Version
                        Wscript.Echo ""
                        Wscript.Echo "====="
            Next      
    Next

 

This happens because If there is no container  specified, the principal context class will create a System.DirectoryServices.DirectoryEntry object by binding to builtin CN=Users container to start searching for users. System.DirectoryServices is built on top of ADSI.  ADSI by default does an objectclass=* search as part of its normal bind process unless the fastbind flag is specified.  if the user  performing the search does not  have permission to read the attributes of default users contain, the search operation will fail, thus causing “The specified directory service attribute or value does not exist”, exception.

 

This is also true when searching computer objects using ComputerPrincipal::FindByIdentity and you don’t have read permission on CN=Computer container and have not specified a container in the constructor of System.DirectoryServices.AccountManagemnt.PrincipalContext. The remarks section of the documentation at http://msdn.microsoft.com/en-us/library/system.directoryservices.accountmanagement.principalcontext.principalcontext.aspx explains the rules followed by the PrincipalContext class in selecting a container when one has not been explicitly specified in the constructor.

 

The right approach is to specify the container where the object resides if you know the name of the container.  Alternatively, you can simply specify the domain naming context as the container.  The performance in this case will be inferior to specifying the name of the container explicitly, since the search will encompass the entire domain.

 

The issue can be reproduced by using the following code (Change the name of the domain and searched user to values appropriate for your environment):

 

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.DirectoryServices.AccountManagement;

using System.DirectoryServices;

 

namespace TestInvalidCreds

{

    class Program

    {

        static void Main(string[] args)

        {

           

PrincipalContext pc = new PrincipalContext(ContextType.Domain, "dc163608.local");

UserPrincipal up = UserPrincipal.FindByIdentity(pc, IdentityType.SamAccountName, "InnerUser");

     

        }

    }

}

 

 

To reproduce the issue deny read permission for a user on CN=Users container for the user that is running the search, and the run the above code in Visual Studio or the compiled program under the above user account. The searched (in this example InnerUser) user can be in any OU.

 

You will get an exception “The specified directory service attribute or value does not exist”.

 

Modify the code as below (Change the name of the domain and searched user to values appropriate for your environment):

 

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.DirectoryServices.AccountManagement;

using System.DirectoryServices;

 

namespace TestInvalidCreds

{

    class Program

    {

        static void Main(string[] args)

        {

            

            PrincipalContext pc = new PrincipalContext(ContextType.Domain, "dc163608.local","dc=dc163608,dc=Local");

            UserPrincipal up = UserPrincipal.FindByIdentity(pc, IdentityType.SamAccountName, "InnerUser");

 

        }

    }

}

 

 

It should now return the object.

 

In my previous post we discussed how to modify a registry based GPO programmatically.  In this post we will focus on using the GPMC ( Group Policy Management Console ) object model to find a GPO  that contains a specific string in the display name. 

The steps for using the GPMC to locate GPOs from C++ are straight forward:

1.       Create an IGPM interface to initialize the GPMC dlls. (http://msdn.microsoft.com/en-us/library/aa814148(VS.85).aspx )

2.       Use IGPM::GetDomain to initialize a SOM (Scope of Management) object to manage GPOs from a specific domain. (http://msdn.microsoft.com/en-us/library/aa814309(VS.85).aspx).  This returns an IGPMDomain object (http://msdn.microsoft.com/en-us/library/aa814189(VS.85).aspx ).

3.       Initialize a variant with the portion of the string you wish to match in the Display Name attribute of the GroupPolicyContainer object in the Active Directory.

4.       Retrieve a GPMC Constants object from the IGPM interface by calling IGPM::GetConstants().  This method returns an IGPMConstants object (http://msdn.microsoft.com/en-us/library/aa814177(VS.85).aspx  ) Using the GPMC constants object to retrieve GPMC constants will make the code much easier to read.

5.       Create a Search Criteria object using the IGPMC::CreateSearchCriteria() method.  This method returns an IGPMSearchCriteria object (http://msdn.microsoft.com/en-us/library/aa814259(VS.85).aspx ).

6.       Using the IGPMConstants::get_SearchPropertyGPODisplayName() object, create a GPMSearchProperty object. This object will contain information that identifies the attribute you are searching for.  

7.       Using the IGPMConstants::get_SearchOpContains () method to retrieve a GPMSearchOperation object initialized to a wild card contains search.

8.       Add the search property object ( GPMSearchProperty created in step 6) along with the search operation object ( GPMSearchOperation created in step 7) to the search criteria object ( created in step 5 ) with the variant ( initialized in step 3 ) using the IGPMSearchCriteria::Add method (http://msdn.microsoft.com/en-us/library/aa814260(VS.85).aspx )

9.       Execute the search using the SOM domain object created in step 2 by calling the IGPMDomain::SearchForGPOs( ) method passing in the IGPMSearchCriteria object initialized in step 8.  You will be given a IGPMGPOCollection object (http://msdn.microsoft.com/en-us/library/aa814200(VS.85).aspx ) containing the results of the search.  The collection object will contain a set of IGPMGPO objects returned as variants containing IDispatch interfaces.

Let’s take a look at each step in a C++ code block.

        //

        // Locate a GPO with contains match and modify it

        //

        {

            //

            IGPM *pGPM = NULL;   // Initial GPMC interface. 

                                 // Used to retrieve other GPO objects.

            IGPMDomain *pDom = NULL; // Returned by pGPM, limits items

                                     // to a specific domain.

            IGPMGPO *pGPO = NULL;    // The GPMC interface that

                                     // represents a single GPO

            IGPMConstants *pGPMConstants = NULL; // Used to help retrieve

                                                 // GPMC constants easily

            IGPMSearchCriteria *pIGPMSearch = NULL; // Defines a search

                                                    // criteria to locate

                                                    // GPOs.

            IGPMGPOCollection *pGPOCollection = NULL; // used to search for

                                                      // a GPO, this will

                                                      // contain the results

                                                      // of the search.

            //

            // To use _bstr_t classes must use the comutil library and

            // and header files

            //

            _bstr_t bErrorStr("");

            //

            // Retrieve FQDN

            //

            wchar_t strFQDN[255], strDispName[255];

            fflush( stdin );

            printf("Enter the FQDN of the domain to create the GPO in: ");

            _getws( strFQDN );

            fflush(stdin);

            //

            // Retrieve Display Name

            //

            printf("Enter Display name for GPO to Match: ");

            _getws( strDispName );

            fflush(stdin);

            //

            // Step 1: Create and initialize the GPMC objects.

            // Use the GPMC to create SOM and locate GPO

            // To use this interface the GPMC components must be present

            // on the client.

            //

            _bstr_t bstrFQDN(strFQDN);

            hr = CoCreateInstance(CLSID_GPM, NULL,

                                  CLSCTX_INPROC_SERVER,

                                  IID_IGPM , (LPVOID*)&pGPM);

            //

            // Step 2: Retreive the SOM ( Scope of Management object )

            // Retrieve a SOM object associated with the target domain

            //

            hr = pGPM->GetDomain( (BSTR)bstrFQDN, NULL, 0, &pDom);

            //

            // Step 3: initialize the search string into a variant.

            //

            _variant_t vData( strDispName );

            //

            // Step 4:

            // Retreive the GPMC constants object.

            //

            hr = pGPM->GetConstants( &pGPMConstants );

            if( FAILED(hr) )

            {

                bErrorStr = L"Failed to retrieve IGPMConstants";

                goto CLEANUP_CONTAINS2;

            }

            //

            // Step 5:

            // Retrieve the search criteria object.

            //

            hr = pGPM->CreateSearchCriteria( &pIGPMSearch);

            if( FAILED(hr) )

            {

                bErrorStr = L"Failed to create IGPMSearchCirteria";

                goto CLEANUP_CONTAINS2;

            }

            //

            // Step 6 & 7: Setup the search property and the

            // search operation constants.

            //

            GPMSearchProperty sp;

            GPMSearchOperation so;

            //

            // Contains Match for display name.

            //

            pGPMConstants->get_SearchPropertyGPODisplayName( &sp);

            pGPMConstants->get_SearchOpContains( &so);

            //

            // Step 8:

            // Add the search operation and property

            // to the search criteria object.

            //

            pIGPMSearch->Add( sp, so, vData );

            long lCount = 0;

            //

            // Step 9:

            // Perform the search and retrieve the GOP collection.

            //

            hr = pDom->SearchGPOs( pIGPMSearch, &pGPOCollection);

            if( FAILED(hr) )

            {

                bErrorStr = L"IGPMDomain::SearchGPOs failed";

                vData.Clear();

                goto CLEANUP_CONTAINS2;

            }

            //  

            // the following is an example of how to work

            // with the GPO collection returned from the search.

            // If we matched at least one item, lets use a helper

            // function to retrieve the index of the GPO object

            // from the collection.

            //

            pGPOCollection->get_Count( &lCount);

            printf("Found %d GPOs that matched the display name criteria \"%S\"\n",

                   lCount, strDispName);

            if( lCount > 0 )

            {

                long lIndex = 0;

                //

                // Get a selected GPO to delete

                // if the count is 1, then we have only 1 item,

                // if the count is > 1, then we need to

                // ask the user to select one to modify.

                //

                if( lCount == 1 ) lIndex = 1;

                else lIndex = RequestGPOIndex( pGPOCollection );

                if( lIndex > 0 )

                {

                    //

                    // Retrieve the mode and settings

                    //

                    int iMode = RequestMode();

                    DWORD lData = RequestSetting();

                    //

                    // Clear the variant to request an IDispatch

                    // pointer to the IGPMGPO interface that

                    // represents the GPO.

                    //

                    vData.Clear();

                    hr = pGPOCollection->get_Item( lIndex, &vData);

                    if( FAILED(hr) )

                    {

                        bErrorStr = L"Failed to retrieve IGPMGPO interface form collection";

                        goto CLEANUP_CONTAINS2;

                    }

                    //

                    // QI for the GPO interface

                    //

                    hr = vData.pdispVal->QueryInterface( IID_IGPMGPO,

                                                         (void **)&pGPO);

                    if( FAILED(hr) )

                    {

                        bErrorStr = L"Failed to retreive GPO pointer from vData.pdispVal->QueryInterface";

                        vData.Clear();

                        goto CLEANUP_CONTAINS2;

                    }

                    //

                    // Get the path to the GPO and then call the

                    // modify function.

                    //

                    BSTR bPath;

                    pGPO->get_Path( &bPath);

                    _bstr_t bADsPath("LDAP://");

                    bADsPath = bADsPath + strFQDN;

                    bADsPath = bADsPath + "/";

                    bADsPath = bADsPath + bPath;

                    SysFreeString( bPath );

                    hr = ModifyUserPolicyForPreventAccessToCmdPrompt(

                                        bADsPath, iMode, lData);

                    if( SUCCEEDED(hr) ) bErrorStr = L"Successfully modified GPO";

                    else bErrorStr = L"Unable to modify GPO";

 

                }

 

CLEANUP_CONTAINS2:

                vData.Clear();

                if( pGPO ) pGPO->Release();

                if( pGPOCollection) pGPOCollection->Release();

                if ( pIGPMSearch ) pIGPMSearch->Release();

                if( pGPMConstants ) pGPMConstants->Release();

                if( pGPM ) pGPM->Release();

                if( pDom ) pDom->Release();

                LPTSTR pstr = bErrorStr;

                printf("%S\nLast HRESULT: %0X\n", pstr, hr);

                CoUninitialize();

                return hr;

            }

        }

        break;

 

Below are 3 helper functions:

RequestGPOIndex – example of working with the GPO collection returned from the search.

RequestMode – retrieves the mode setting for the GPO.

RequestSetting – Retreives the data to be written to the registry.

int RequestMode ( )

{

    int retval = -1;

    BOOL bContinue = TRUE;

    fflush(stdin);

    while( (retval < 0 ) || ( retval > 2 ) )

    {

        printf("\nEnter GPO Mode Value:\n   0 - Not Configured\n   1 - Enabled\n   2 - Disabled\nEnter Selection: ");

        fscanf_s(stdin, "%d", &retval);

        if( (retval < 0 ) || ( retval > 2 )) printf("Invalid Mode Values, must be 0, 1, 2\n");

        fflush(stdin);

    }

    return retval;

}

DWORD RequestSetting( )

{

    int retval = -1;

    BOOL bContinue = TRUE;

    fflush(stdin);

    while( (retval < 1 ) || ( retval > 2 ) )

    {

        printf("\nDisable the command prompt script processing also?\n   1 - Yes\n   2 - No\nEnter Selection: ");

        fscanf_s(stdin, "%d", &retval);

        if( (retval < 1 ) || ( retval > 2 )) printf("Invalid Mode Values, must be  1, 2\n");

        fflush(stdin);

 

    }

    return retval;

}

long RequestGPOIndex( IGPMGPOCollection *pGPOs)

{

    long lSelection = -1;

    long lCount = 0;

    if( pGPOs )

    {

        pGPOs->get_Count( &lCount );

        _variant_t vData;

        IGPMGPO *pGPO;

        while ( (lSelection < 0) || (lSelection > lCount ) )

        {

            long lLoop = 1;

            printf("GPOs in Collection:\n");

            BSTR bID;

            VARIANT_BOOL bUser;

            VARIANT_BOOL bMachine;

            HRESULT hr;

            for( lLoop =1 ;lLoop <= lCount; lLoop++ )

            {

                hr = pGPOs->get_Item( lLoop, &vData );

                hr = vData.pdispVal->QueryInterface(IID_IGPMGPO, (void **)&pGPO);

                pGPO->get_ID( &bID);

                pGPO->IsComputerEnabled( &bMachine );

                pGPO->IsUserEnabled( &bUser);

                printf(" %d -> ID: \"%S\"\n", lLoop, bID );

                printf("\tUser Enabled: ");

                if( bUser == VARIANT_TRUE ) printf(" Yes ");

                else printf(" No ");

                printf(" Machine Enabled: ");

                if( bMachine ) printf(" Yes \n");

                else printf(" No\n");

                SysFreeString( bID );

                pGPO->get_DisplayName( &bID );

                printf("\tDisplay Name: \"%S\"\n", bID);

                SysFreeString( bID );

                pGPO->Release();

                vData.Clear();

            }

            printf(" 0  -> No Selection\n\nEnter a number from 0 to %d: " , lCount);

            fflush(stdin);

            fscanf_s(stdin,"%d",&lSelection);

            if( (lSelection < 0) || (lSelection > lCount) ) printf("\n\007Invalid Entry\n");

        }

        if( lSelection == 0 ) lSelection = -1;

    }

    return lSelection;

}

Greetings!

Over the past few months our team has seen a number of customer requesting information on how to programmatically/create/edit/read registry based GPO information.  I took some time to combine a couple of samples into one that illustrates a number of these concepts.

The first question one must answer when working with a registry based GPO is the programmatic modification of this GPO setting supported by Microsoft.  The general answer to that question is that if their exist public documentation on the MSDN or Tech Net site that provides information on the registry key paths and the possible values then, yes, programmatic modification is supported.  In my sample, I used the excel spreadsheet available at the following MSDN link:

http://www.microsoft.com/downloads/details.aspx?familyid=41dc179b-3328-4350-ade1-c0d9289f09ef&displaylang=en

The spreadsheet contains a list of policies and their associated registry keys.

 Remember, the GPO can have information stored in 3 different places:

1. The Active Directory in the form of a GroupPolicyContainer object.
2. The Sysvol of any DC, where GPO related INI file or POL file is created.   The POL file is then written into the local machine registry in either HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER. In addition to these two files, the GPO could store private data in a format known only to the GPO extension.
3. The client system where a GPO extension could exist to process GPO private data.

The next step is to determine exactly what values need to be written to the keys in order to enable/disable/set the policy.  While the key values are generally documented, there can be subtle differences in the values that the GUI recognizes and uses to determine if a GPO is enable/disable or set.  I find that using the empirical method works best to solve this problem.   Using the Group Policy Management Console GUI tool, I create a GPO with a specific display name like "MaxVs Test Policy".   I set the policy that I want to set programmatically.   Then I do a query in the Active Directory Users and computers tool to locate the GPO  Object in the Active Directory.  The GPO object contains a CN that is a GUID.  This GUID can be used to locate the NTFS folder on the SYSVOL of a DC that the policy registry information was written to.

 For example, if I created a GPO that sets the "Prevent access to the command prompt" under the "User Configuration" node:

User Configuration -> Policies -> Administrative Templates -> Security -> "Prevent access to the command prompt"

 I enable it and set it.  When I click the Apply button, a Registry.POL file will be created on the sysvol in a directory named after the common name of the GroupPolicyContainer object created in the AD.  The path will look similar to the following:

C:\Windows\SYSVOL\sysvol\maxv08.nttest.microsoft.com\Policies\{529AB3E5-3818-42F5-9BDE-95629F33780C}\User

Where "maxv08.nttest.microsoft.com" will be the domain name of your domain and the GUID string will be the display name of the GPO you just created.  At this point, you can view the POL file in notepad or using a binary file editor.  If you use notepad, the contents would be similar to the following:

PReg
   [ S o f t w a r e \ P o l i c i e s \ M i c r o s o f t \ W i n d o w s \ S y s t e m   ; D i s a b l e C M D   ;    ;    ;    ]

To see the actual values written in the key, you would need to use a binary editor that displays the binary representation for the values displayed above.

Copy this file to another location with a name that indicates the setting values.

Repeat this process for all the settings you wish to duplicate programmatically.

Once you know the registry values to write, we are ready to write the C++ code to set them.

Keep watching this blog, I will make another post  that provides a function that illustrates how to set the "Prevent access to the command prompt" policy.

Problem:

 

When running a script to add a user from forest Fabrikam, to a domain local group in forest Microsoft, you will receive an error as follows:

80072030 "There is no such object on the server"

This is a snippet of the code we tried to perform the procedure:

=================================================
set objGroup = GetObject("LDAP:// microsoft.com /cn=Domain Local Group,ou=Test,dc=microsoft,dc=com")
set objUser = GetObject("LDAP://fabrikam.com/cn=Vishal Joshi,ou=CrossDomainTestOU,dc=fabrikam,dc=com")

wscript.echo "Group:" & objgroup.adspath & vbcrlf & "User:" & objUser.adspath

objGroup.add(objUser.adspath)
===================================================

If the domains are in two forests with a two way trust and running at 2003 native forest functional level, it will not work.

You will have no trouble using Active Directory Users & Computers to add the user to the group.

The echo works in all the above scenarios, so you know that the GetObject is working. The script will always fail on the objGroup.add.

Even adding the serverbind to the LDAP requests the script will not work.

 

Also running under the user who has enough right’s on both domains.

 

 

Resolution:

 

 

We need to use the LDAP://<SID=S-1-5-21-2052111302-2139871995-839522115-1115> format while adding the user

 

Something like

 

objGroup.add(“LDAP://<SID=S-1-5-21-2052111302-2139871995-839522115-1115>”)

 

What happens when you use the SID bind string, it creates a place holder.

 

If you provide the path, it tries to verify the object and retrieve the SID to create the FSP, because the FSP is what is added to the local domain group.

 

It did not check to see if the SID was valid... it just accepted it because it was a valid SID. Meaning, it was the correct size with the correct number of sub authorities.

 

So it’s the callers responsibility to send the right SID to this call.

Since the user is in a foreign forest, the object will not represented in local GC. So the foreign user should be added to the local domain group using the SID of the user object instead of distinguished name.

Password Settings objects were introduced in Windows 2008 AD to allow administrators more control over the password policies for the domain.  These objects can be associated with a container of user objects or groups.

The following link provides details on how PSOs are applied:

http://msdn.microsoft.com/en-us/library/cc212097(PROT.10).aspx

When you create a PSO, there are 10 properties that must be set:

msds-maximumpasswordage - a 64 bit time value interval represented in nanoseconds before the password expires.
msds-minimumpasswordage  -  a 64 bit time value interval represented in nanoseconds before a password change is allowed.
msds-LockoutObservationWindow -a 64 bit time value interval in nanoseconds to look for possible bad password entries
msds-LockoutDuration - a 64 bit time value interval in nanoseconds to lock the account after a specified number of bad password attempts during the observation period.
msds-LockoutThreshold - a 16-bit unsigned integer indicating the number of bad password attempts within an Effective-LockoutObservationWindow that will cause an account to be locked out.
msds-PasswordSettingsPrecedence - an integer value used to  resolve conflicts with multiple PSOs.  The PSO with the lowest precedence value is applied.
msds-PasswordHistoryLength-  number of old passwords that are retained to prevent duplication of a previous password.
msds-MinimumPasswordLength - minim length of the password.
msDS-PasswordComplexityEnabled - Boolean value, if true, password complexity rules apply to new passwords.
msDS-PasswordReversibleEncryptionEnabled -  A Boolean value indicating that the user's clear text password is to be stored in the supplemental Credentials attribute.

Most of these properties are straight forward types and can be easily converted from native Powershell types.  The time intervals are represented as 64 bit negative values for the number of nanoseconds each property should be in effect.  The following KB provides some useful information on how to create these values using long value types:
http://support.microsoft.com/kb/954414

There is a native .Net type that works with nanosecond intervals called System.TimeSpan.  If you use the static Parse method, you can provide a string representation for the time interval using the following format:

"Days.hours:Minutes:Seconds:Milliseconds"

So, if you wanted to create a TimeSpan object for time interval representing 2 days, 3 hours, 15 minutes, 30 seconds, the string would look like: "3.03:15:30".  To create a TimeSpan object in PSH using this value, the line of code would be:

$timeInterval = [System.TimeSpan]::Parse("3.03:15:30")

Using the System.TimeSpan.Tick property, you can retrieve the total nanoseconds.  Just multiply by -1 and the value is in the format that needs to be stored to the Active Directory.

We still have one problem to solve, we need to take this 64 bit integer and convert it into a format that ADSI can send to the AD.  We need to convert this value into an IADsLargeInteger interface. I know my solution for this conversion is not the most elegant one, however, I was having trouble trying to figure out how I could remove the top 32 bits of the 64 bit value to load them into the IADsLargeInteger::HighPart.

I used Adam Weigert's Blog post as a basis, then created my own home grown System.TimeSpan to IADsLargeInteger conversion routine.  Many thanks to Adam for posting the conversion information.  Below is a link to his blog post:

http://weblogs.asp.net/adweigert/archive/2007/03/23/powershell-convert-active-directory-iadslargeinteger-to-system-int64.aspx

Once I was able to convert the ticks to IADsLargeInteger types,  the creation of the PSO was a piece of cake. 

Using the TimeSpan object makes it very easy to create human readable time spans.  No mucking about with large conversion multipliers, we let the TimeSpan::Parse method do all the work. 

Below is the PSH code to create a PSO in a 2008 Functional Mode domain:

#
# Conversion function to take TimeSpan objects
# and create IADsLargeInteger objects
#
function ConvertTimeSpanToTimeIntervalIADsLargeInteger([System.TimeSpan] $ts, [object]$olG)
{
    [Int64] $i64 = [Int64]$ts.Ticks * -1;
    $i64
    $bytes = [System.BitConverter]::GetBytes($i64)
    #
    # Ok, I know this is not very elegant or Powershellish....
    # but IT WORKS!
    # I would love to see a better way of working with bits in PSH
    #
    $tmpHigh = [System.Byte[]]@(0,0,0,0);
    $tmpLow = [System.Byte[]]@(0,0,0,0);
    [System.Array]::Copy($bytes,0,$tmpLow,0,4);
    [System.Array]::Copy($bytes,4,$tmpHigh,0,4);
    $lowPart = [System.BitConverter]::ToInt32($tmpLow, 0)
    $highPart = [System.BitConverter]::ToInt32($tmpHigh, 0)
    $oLG.GetType().InvokeMember("HighPart", [System.Reflection.BindingFlags]::SetProperty, $null,  $oLG, @($highPart))
    $oLG.GetType().InvokeMember("LowPart", [System.Reflection.BindingFlags]::SetProperty, $null,  $olG, @($lowPart))
    #
    return $oLG
}
#
# Function to convert IADsLargeIntegers to 64 bit values
# Adam Weigert's conversion routine
#
function ConvertADSLargeInteger([object] $adsLargeInteger)
{
    $highPart = $adsLargeInteger.GetType().InvokeMember("HighPart", [System.Reflection.BindingFlags]::GetProperty, $null, $adsLargeInteger, $null)
    $lowPart  = $adsLargeInteger.GetType().InvokeMember("LowPart",  [System.Reflection.BindingFlags]::GetProperty, $null, $adsLargeInteger, $null)

    $bytes = [System.BitConverter]::GetBytes($highPart)
    $tmp   = [System.Byte[]]@(0,0,0,0,0,0,0,0)
    [System.Array]::Copy($bytes, 0, $tmp, 4, 4)
    $highPart = [System.BitConverter]::ToInt64($tmp, 0)

    $bytes = [System.BitConverter]::GetBytes($lowPart)
    $lowPart = [System.BitConverter]::ToUInt32($bytes, 0)
 
    return $lowPart + $highPart
}
#
# Replace $Server with your target server
# Replace $UserID with your credentials
# Replace $Password with the appropriate password
#
$Server = "my.Server.My.Domain.Com"
$UserID = "Domain\UserID"
$Password = "Password"
#
# Build a ROOT DSE path so you can retrieve the
# DefaultNamingContext
#
$rootpath = "LDAP://" + $Server + "/RootDSE"
$oRoot = new-object System.DirectoryServices.DirectoryEntry($rootpath, $UserID, $Password)
$oRoot.PSBase.RefreshCache()
$strDNC = $oRoot.defaultnamingcontext
#
# Build the path to the default password settings container
#
$strContainerPath = "LDAP://" + $Server + "/CN=Password Settings Container,CN=System," + $strDNC
$strContainerPath
$oPWDContainer = new-object System.DirectoryServices.DirectoryEntry($strContainerPath, $UserID, $Password);
$oPWDContainer.PSBase.RefreshCache()
#
# Create a PasswordSetting Object, then fill it with values
#
$oObj = $oPWDContainer.PSBase.Children.Add("CN=My PSO Object41", "msds-passwordsettings");
#
# Setup the individual ticks objects
# Using KB Defaults described in KB954414:
# http://support.microsoft.com/kb/954414
#
$oLarge2Days = new-object -ComObject "LargeInteger"
$oLarge1Day = new-object -ComObject "LargeInteger"
$oLarge30Minutes = new-Object -ComObject "LargeInteger"
#
# setup the time spans
#
$TM2days = [System.TimeSpan]::Parse("2.00:00:00");
$TM30Minutes = [System.TimeSpan]::Parse("00:30:00");
$TM1Day = [System.TimeSpan]::Parse("1.00:00:00");
#
# Convert the TimeSpans to Time Interval LargeIntegers
#
ConvertTimeSpanToTimeIntervalIADsLargeInteger $TM2Days $oLarge2Days
ConvertTimeSpanToTimeIntervalIADsLargeInteger $TM1Day $oLarge1Day
ConvertTimeSpanToTimeIntervalIADsLargeInteger $TM30Minutes $oLarge30Minutes
#
# Set the precedence, Reverse Encryption, PasswordLengths and other values
#
$PolicyPrecedence = 20
$ReversibleEncryption = $false
$ComplexityRequirements = $true
$LockoutThreshold = 0
$MinPasswordLength = 8
$HistoryLength = 20
#
# Load up the Properties
#
$oObj.PSBase.Properties["msds-maximumpasswordage"].Value = $oLarge2Days
$oObj.PSBase.Properties["msds-minimumpasswordage"].Value = $oLarge1Day
$oObj.PSBase.Properties["msds-LockoutObservationWindow"].Value = $oLarge30Minutes
$oObj.PSBase.Properties["msds-LockoutDuration"].Value = $oLarge30Minutes
$oObj.PSBase.Properties["msds-LockoutThreshold"].Value =  $LockoutThreshold
$oObj.PSBase.Properties["msds-PasswordSettingsPrecedence"].Value = $PolicyPrecedence
$oObj.PSBase.Properties["msds-PasswordHistoryLength"].Value = $HistoryLength
$oObj.PSBase.Properties["msds-MinimumPasswordLength"].Value = $MinPasswordLength
$oObj.PSBase.Properties["msDS-PasswordComplexityEnabled"].Value = $ComplexityRequirements
$oObj.PSBase.Properties["msDS-PasswordReversibleEncryptionEnabled"].Value = $ReversibleEncryption
$oObj.PSBase.CommitChanges()