This is probally the first time you have run the Test command isn't it? In Exchange 2010 you need a test mailbox to perform tests with. This can be created using the new-TestCasConnectivityUser.ps1 powershell script Microsoft provides us with Exchange 2010.

Note: As the requirement for special formatting of unicodePwd has been lifted Microsoft has placed a default requirement to ensure all password operations are done through LDAPS instead of LDAP. To allow password operations through LDAP please see:

However the attribute which sets the account password to disabled "msDS-UserAccountDisabled" was not associated with the user class object in the schema. AD LDS has a series of attributes to control a user account for items such as Account Lockout, Account Disabled, Password Never Expires, User Cannot Change Password etc. For a list of these attributes please see:

Note: Active Directory does not have these attributes, instead all these values are associated with an attribute called userAccountControl. This attribute has an integer set to it.. 512 is a normal account. To disable an account add a value of 2. In decimal, this is 514 (2 + 512). For more information on how this works in Active Directory please see: http://support.microsoft.com/kb/305144

To associate these attributes with the user class object you need to connect to the LDS Instance using the Active Directory Schema Console. If Active Directory Schema does not exist in your MMC snap-in list register it using "regsrv32 schmmgmt.dll" from command line.

Note: When connecting to your LDS Instance you cannot use localhost or it will fail. You must use the IP address of the LDS Instance. This is due to a code error in the Active Directory schema console, please see:

Once connected to your LDS Instance in Active Directory Schema MMC snap-in go to the properties of the user class object and click the attributes tab.

As you see none of the msDS-User type class objects exist. Go ahead and add the following attributes:

- ms-DS-UserAccountAutoLocked

- msDS-UserAccountDisabled

- msDS-UserDontExpirePassword

- ms-DS-UserEncryptedTextPassword

- msDS-UserPasswordExpired

- ms-DS-UserPasswordNotRequired

After the attribute is added, restart your LDS Instance service and connect to the application partition in ADSIEdit containing your user account. Set the msDS-UserAccountDisabled to FALSE.

Problem 2

You must allow Simple Bind requests to an AD LDS Instance over standard LDAP. To do this connect to the configuration partition on your LDS Instance using ADSIEdit. My instance is listening on TCP 10001.

Open the properties of Directory Service. Open the multivalued attribute msDS-Other-Settings. Ensure RequireSecureSimpleBind is set to 0. This will ensure that both LDAP and LDAPS connections are allowed to bind authentication to the LDS Instance.

AD LDS does not include any default security principals. However, AD LDS does provide importable schema extensions that you can use to create users in AD LDS. Users that are created from these user classes can be used as security principals. In addition, you can make any object class in the AD LDS schema a security principal by adding the msDS-bindableobject auxiliary class and the unicodePwd attribute to the schema definition of an object class. Each AD LDS security principal must be assigned an account and password, which AD LDS uses for authentication.

To do this open up ADSIEdit and connect to the Schema partition of your LDS Instance.

Navigate to the CN=User class object in ADSIEdit under the Schema partition and open its properties.

As you see the msDS-bindableobject auxiliary class does not exist.

Add it to the list and click OK.

Restart the LDS Instance under the services MMC console.

Reset the user's password by connecting to the appropriate application partition in ADSIEdit, right clicking on the user and clicking Reset Password.

I was now ale to perform a simple bind to my LDS Instance using a LDS user account.

Wednesday, June 15, 2011

Active Directory user accounts have an attribute called userAccountControl which is used to control items such as Account Lockout, Account Disabled, Password Never Expires, User Cannot Change Password etc. This is determined by an integer value... based on the value the system knows which options are enabled and which are disabled. The value 512 is the base value for all normal user accounts. To understand all integers that make this attribute work please refer to the following KB article.

AD LDS (ADAM) does not support the userAccountControl attribute. Instead, AD LDS uses several individual attributes to hold the information that is contained in the flags of the userAccountControl attribute.

For a list of these attributes please refer to the following MSDN article:

Connecting to "localhost:10001"Logging in as current user using SSPIImporting directory from file "SVCLDAPQuery.ldf"Loading entries.Add error on entry starting on line 1: Invalid DN SyntaxThe server side error is: 0x2081 Multiple values were specified for an attribute that can have only one value.The extended server error is:00002081: NameErr: DSID-03050C42, problem 2003 (BAD_ATT_SYNTAX), data 0, best match of:'CN=SVCLDAPQuery,CN=Users,DC=testinstance,DC=ADAM'

0 entries modified successfully.An error has occurred in the programNo log files were written. In order to generate a log file, pleasespecify the log file path via the -j option.

This occured because the "cn" attribute did not match the first part of the "distinguishedName" attribute. If we change this to:

Note: For ADAM, Microsoft enabled the userPassword attribute to function as a write-alias for unicodePwd and removed the requirement for the special formatting unicodePwd required. This allows your LDIF files to have clear-text passwords specified.

I am performing the import with the following command:

ldifde -i -f SVCLDAPQuery.ldf -s localhost:10001

This command throws out the following errors:

Connecting to "localhost:10001"Logging in as current user using SSPIImporting directory from file "SVCLDAPQuery.ldf"Loading entries.Add error on entry starting on line 1: Operations ErrorThe server side error is: 0x2077 Illegal modify operation. Some aspect of the modification is not permitted.The extended server error is:00002077: SvcErr: DSID-033807B5, problem 5012 (DIR_ERROR), data 8237

0 entries modified successfully.An error has occurred in the programNo log files were written. In order to generate a log file, pleasespecify the log file path via the -j option.

As the requirement for special formatting of unicodePwd has been lifted Microsoft has placed a default requirement to ensure all password operations are done through LDAPS instead of LDAP. This is why it will not import the password!

To lift this requirement make the following change to the configuration partition of the instance:

Navigate to CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN={GUID of the ADAM}

Monday, June 13, 2011

I am performing ADAMSync from an Active Directory domain to an LDS Instance. My AD Domain Partition is called DC=Domain,DC=Local. My LDS Instance also has the same distinguished name of DC=Domain,DC=Local. When Syncing the following error is experienced:

************************************ A fatal error occured in the program while processing entry************ GUID=08080633da0dfe4f8b46508f00f2708f************ The error will be ignored at user request. Continuing...************************

Below I will explain how to resolve this. I am syncing all User Objects from Active Directory to userProxy objects in LDS. This is required for single sign on (SSO). userProxy objects forward authentication bind requests to domain controllers which process the authentication request, pass it back to LDS then to the client.

To understand this in more detail please read my following blog post on the userProxy class:

Notice the bits in bold. These are the attribute I want to Sync. I am also syncing these attributes FROM a user object TO a userProxy object. Let's use the "Active Directory Schema" mmc snap-in to look at the LDS Instance schema. To understand how to use "Active Directory Schema" mmc snap-in to connect to an LDS Instance please read:

In this environment I imported the following schema extensions MS-UserProxy.ldf, MS-AdamSyncMetadata.ldf, MS-AdamSchemaW2K8.ldf to my LDS Instance. In my Active Directory Schema if I look at my userProxy class object attribute association I have the following attributes associated:

However in my user class object I have the following attributes associated:

Can you pick the problem yet? I have asked ADAMSync to sync the following attributes FROM user class in Active Directory TO userProxy:

Back when LDS (Lightweight Directory Services) was called ADAM (Active Directory Application Mode) there was a console known as "ADAM Schema" which was the ADAM version of the "Active Directory Schema" MMC console.

Now with LDS the "ADAM Schema" no longer exists. Microsoft say to use "Active Directory Schema" for both LDS and Active Directory databases. For the TechNet article please see:

I setup an LDS instance running on TCP10001. When I try and connect to the instance using Active Directory Schema on localhost:10001 it comes up as available. However I know my instance is there as I can connect to it using ADSIEdit.

I found out if you connect using the IP address of the server's primary network interface card it connects successfully.

Must be something dodgy embedded into the code of the Active Directory Schema snap-in.

Monday, June 6, 2011

When setting up windows networks a DMZ must be created. This DMZ cannot contain any PC's that are a member of your internal Active Directory domain for security reasons. For your SME companies best practice is to generally configure all machines in your DMZ in a workgroup setup. For your enterprise companies best practice is to create a separate active directory forest for your DMZ. This allows centralised management over your DMZ servers allowing administrators to control servers using things such as Group Policy and WSUS.

However there are times where you need to allow PC's in your DMZ to access your internal Active Directory. For example I needed to setup an ADAM server to synchronise only particular attributes from various domains in an Active Directory forest which to be exposed to the internet using LDAPS (Secure LDAP) on secure port 636 for an external application. This ADAM server needs to be a member of of the Active Directory domain as I require User Proxy Bind Redirection to forward authentication requests through to an Active Directory domain controller. We created a separate DMZ just to contain this server requiring domain membership.

All the ports above still do not allow a workstation to be a member of an Active Directory domain due to the DCOM RPC ports. Microsoft RPC (MS-RPC) does not only use port TCP135 it also uses randomly generated ports from TCP 1024-65535 for XP/2003 and TCP 49152-65535 for Vista/2008 upwards. These are frequently informally referred to as "random RPC ports." In these cases, RPC clients rely on the RPC Endpoint Mapper (EPM) which runs on TCP135 to tell them which dynamic port(s) were assigned to the server.

Multiple components from the underlining windows subsystem get assigned their own dynamic RPC port every time the windows PC boots. These components include:

All these windows components get a dynamic port each time the system boots. RPC clients discover which port these services are on by querying TCP 135 (the port mapper).

So how did we get around this without opening every port from 1024-65535?

Our corporate firewall is currently a Cisco ASA 5540 running OS v8.4(1). The lastest Cisco OS software for the 5540 has integrated smarts for the Windows RPC Endpoint Mapper (EPM) running on TCP135. Cisco refers to this as "DCERPC".

This process works as follows:1. A client queries an EPM server for the dynamically-allocated port number of a required DCERPC service. The EPM server listens on the well-known TCP port 135.2. The ASA, located between the client and EPM server, intercepts the communication.3. The EPM server indicates the port number on which the DCERPC service is available.4. The ASA opens a pinhole for that DCERPC service.

This allows us to make the access control lists (ACLs) as tight as possible maintaining security whilst allowing application functionality through the ASA firewall.

Here is the Syntax used for configuring this functionality on our ASA:

In this post we will look at the Alternate Witness Server - what is it?

The Alternate Witness Server provides a replacement witness server for a DAG to use after a datacenter switchover. When you are performing a datacenter switchover, you’re restoring service and data to an alternate or standby datacenter after you’ve deemed your primary datacenter un-usable from a messaging service perspective.

Although you can configure an Alternate Witness Server (and corresponding Alternate Witness Directory) for a DAG at any time, the Alternate Witness Server will not be used by the DAG until part-way through a datacenter switchover; specifically, when the Restore-DatabaseAvailabilityGroup cmdlet is used.

The Alternate Witness Server itself does not provide any redundancy for the Witness Server, and DAGs do not dynamically switch witness servers, nor do they automatically start using the Alternate Witness Server in the event of a problem with the Witness Server.

The reality is that the Witness Server does not need to be made redundant. In the event the server acting as the Witness Server is lost, it is a quick and easy operation to configure a replacement Witness Server from either the Exchange Management Console or the Exchange Management Shell.

Thursday, June 2, 2011

After joining a new Windows Server 2008 R2 member server to the domain I was not able to log in, even with a Domain Admin account. The following error was experianced:

The security database on the server does not have a computer account for this workstation trust relationship

After some investigation it turns out the computer new computer account did not have a SPN (Service Principal Name). This is stored in the servicePrincipalName attribute in Active Directory. Below is a screenshot from ADSIEdit:

I added two SPN's to the computer account object in Active Directory in the format of: