joeware - never stop exploring... :)

I am playing with a new utility I was challenged to write at the latest MVP Summit. It is a command line utility to manage msDS-PasswordSettings objects and I ran into a weird issue where one of my GC queries wasn’t finding what I thought it should be finding. So as a point of first resort, I fired up wireshark and start tracing the calls and when I went to check out the calls they were all encrypted… WTF. I went and checked to make sure I didn’t enable encryption and I didn’t… Oh wait domain policy GRRRRR.

So I go to pull up the domain policy editor and turn down the security (Shhh don’t tell anyone) and low and behold, the Feb customer preview of Longhorn doesn’t have a policy editor in it… Ah yes, I recall, it was purposely not in there for this version, the GPO folks did say that… It will definitely be in Beta3…

I knew I could fire up a policy editor on a client and tweak it that way but I have no clients in the Longhorn test domain and I wasn’t interested in testing how well the policy editor on a machine from Windows Server 2003 R2 DomainX would work on a Longhorn DomainY so I just decided to tweak the registry on my test client machine directly. How you ask? Great question and why I wrote this blog entry.

You want to go into the registry, specifically to the key

hklm\system\currentcontrolset\services\ldap

and look at the value called ldapclientintegrity and set it to 0.

Rerun my app and voila… Instantly I can see the LDAP traffic in clear text again.

So what was the issue you ask??? Silly stupid issue actually, related, interestingly to the fact that I was running the utility on a machine that wasn’t a member of the Longhorn domain. I can’t believe I made the mistake as it is a stupid mistake. In order to work from a non-trusted machine I allow, like with adfind, the ability to specify a specific host. That worked great, but then I went chasing after a GC and well the locator by default went after a GC for the domain the machine was part of, not a GC of the test Longhorn forest. So duh, yeah, it didn’t find what I was looking for because it only existed on the Longhorn domain. I corrected it by doing a quick manual lookup via DsGetDCName to get a GC in the Longhorn forest based on the info from the RootDSE of the specified host.

So why do I test this way instead of spinning up a client in the test forest? Because I like catching problems like this. I want my utilities to work under those conditions because 99% of the time I have to use the utilities I am not in the forest I am running the utilities against (usually in workgroup mode). Once I have a good chunk of the code written I will start running it from domain joined machines as well but in general, if it works from outside of the domain, it will work fine within the domain.

  joe

…is generally a very bad idea. Why, because in Windows 2000 and Windows Server 2003 AD, objectClass is not, by default, indexed.

What does that mean you ask? It means that your query is going to be way slow because it has to look at every single object in the search scope of the query with the attribute objectClass populated (basically ALL of the objects) will have to be looked at to determine if it is a match or not. Say you have 10,000 objects in your domain and you have 20 users. You will have to look at 10,000 objects to find those 20 users.

The better query is to use (&(objectCategory=person)(objectClass=user)) or possibly (samAccountType=805306368). These queries take advantage of indexed attributes which means things will go much better for you and you will have to look at far fewer objects for matches, hopefully JUST the objects that do match.  

See also http://blog.joeware.net/2005/12/08/147/

There is an easy way to correct this issue if you want to continue to use (objectClass=user), index the attribute.

“WHOA!!! Hold on!“, you say. “You don’t just want to index that attribute, it will break something. Someone from MSFT told me that Active Directory can’t properly Index multi-value non-unique attributes and that is specifically why objectClass isn’t indexed by default…“. Yes I heard that same rumor as well, multiple times in fact. When I dug into it, I found that the rumor did indeed seem true…. but only back in the early Windows 2000 beta’s. The bright folks on the DS team realized that that kind of crap wouldn’t fly in the real world and so corrected the issue. Unfortunately no one got around to correcting the over sight with objectClass by the time RTM came around so objectClass went out without an index and directories everywhere suffer for it when applications only use objectClass with other non-indexed attributes for their queries. Exchange was a perfect example of this for a long time.

I recommend you do some level of analysis on your directory with say Server Performance Advisor and check to see if people are sending bad queries based on objectClass but if you have a directory of any size and you are using any LDAP aware apps, you are probably getting hit with inefficient queries based on objectClass. So just do it. You are going to do it down the road anyway… More on that later.

So how do you index objectClass? Its easy.

The following command run from a schema admin account will do the work for you:

adfind -schema -f name=object-class searchFlags -adcsv | admod searchFlags::{{.:set:1}} -exterr

That command finds the DN and current searchFlags values for the class definition and then lights up bit 0 (value 1) which tells it to index the attribute. Cool huh? And you thought schema changes were tough…

Example:

F:\>adfind -schema -f name=object-class searchFlags -adcsv
~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~
“dn”,”searchFlags”
“CN=Object-Class,CN=Schema,CN=Configuration,DC=joe,DC=com”,“8”

F:\>adfind -schema -f name=object-class searchFlags -adcsv | admod searchFlags::{{.:set:1}} -exterr

AdMod V01.10.00cpp Joe Richards (joe@joeware.net) February 2007

DN Count: 1
Using server: 2k3dc11.joe.com:389
Directory: Windows Server 2003

Modifying specified objects…
DN: CN=Object-Class,CN=Schema,CN=Configuration,DC=joe,DC=com…

The command completed successfully

As an aside, you will note that I didn’t target a specific domain controller for this update… In other words, I didn’t target the schema master… You will also note there was no error message… “So what” you say, “2k3dc11 must be your schema master, you got lucky…” No, 2k3dc11 isn’t my Schema Master, 2k3dc02 is. This is the magic of something called the LDAP Write Referral. What happens is the DC that I hit, 2k3dc11, knew it wasn’t able to write that value I needed written so it sent back a Write Referral to my machine telling me which server to contact to make that change. My application, like most, by default, will chase the referral and execute the command on the schema master refereed to by the first DC.

This is important functionality to keep in mind because once you start running Longhorn and you decide to deploy Read Only DCs (RODC) this will almost certainly crop up with normal object updates. By default, RODCs will refer all write requests to a full DC since they aren’t allowed to accept updates. This could be a problem if you aren’t aware of it. Any apps you have that write an update and then look at the directory immediately after will get confused because the update won’t be on the DC they thought they wrote it to. Depending on the app, different things will occur. You need to test test test test any apps that you have that will need to run against RODCs.

To illustrate this issue, right after I made the update above, I ran another query to check that the value was written properly:

F:\>adfind -sc s:objectclass searchFlags -adcsv
~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~
“dn”,”searchFlags”
“CN=Object-Class,CN=Schema,CN=Configuration,DC=joe,DC=com”,“8 [PRESERVE TOMBSTONE(8)]”

Note that the value didn’t change… Oh my! It didn’t work… No, not quite, give it a few moments for replication to complete and voila:

F:\>adfind -sc s:objectclass searchFlags -adcsv
~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~
“dn”,”searchFlags”
“CN=Object-Class,CN=Schema,CN=Configuration,DC=joe,DC=com”,“9 [INDEX(1);PRESERVE TOMBSTONE(8)]”

This isn’t a problem, it is how it HAS to work. Just be aware of it and if you write programs for Active Directory, keep that in mind and write your programs accordingly. There are programmatic ways to ask for Writeable DCs.

 

So now that the schema change is replicated, you will want to make sure you are working with the refreshed schema. If you aren’t going to use the changes right away this isn’t necessary because the schema cache will refresh itself. Usually though, when you make a change, you want to test it right away, so you want to force an immediate schema cache refresh. I personally use admod to refresh the schema with the command

admod -sc refreshschema

 

So the next question is…. Is that small change worth it? YES! Here is an example from the test directory that I updated. First a user query across the entire domain with objectclass in its natural Windows 2000/Server 2003 state.

F:\>adfind -default -f objectclass=user -dn -stats+only

AdFind V01.37.00cpp Joe Richards (joe@joeware.net) March 2007

Using server: 2k3dc11.joe.com:389
Directory: Windows Server 2003
Base DN: DC=joe,DC=com

Statistics
=================================
Elapsed Time: 110 (ms)
Returned 17308 entries of 40434 visited – (42.81%)

Used Filter:
(objectClass=user)

Used Indices:
DNT_index:13183:N

Analysis
———————————
Hit Rate of 42.81% is Ok

No dedicated indices used for search, this is inefficient.

Indices used:

Index Name : DNT_index
Record Count: 13183 (estimate)
Index Type : Normal Attribute Index

Filter Breakdown:

(objectClass=user)

And after objectClass is indexed and the index has had a chance to build…

F:\>adfind -default -f objectclass=user -dn -stats+only

AdFind V01.37.00cpp Joe Richards (joe@joeware.net) March 2007

Using server: 2k3dc11.joe.com:389
Directory: Windows Server 2003
Base DN: DC=joe,DC=com

Statistics
=================================
Elapsed Time: 20 (ms)
Returned 17308 entries of 20339 visited – (85.10%)

Used Filter:
(objectClass=user)

Used Indices:
idx_objectClass:19117:N

Analysis
———————————
Hit Rate of 85.10% is Efficient

Indices used:

Index Name : idx_objectClass
Record Count: 19117 (estimate)
Index Type : Normal Attribute Index

Filter Breakdown:

(objectClass=user)

 

Sound good?

So previously I mentioned that you will eventually end up doing this anyway right? Well Microsoft FINALLY has built this into the schema on Longhorn. You can see it for yourself, and in fact I really encourage you to, by going out to MSDN and downloading the February CTP of Longhorn (you DO have an MSDN subscription don’t you? If not, why not?). Once you have Longhorn loaded up (I run it on Virtual Server in 16GB disk configurations with 512MB of RAM allocated and it works great) run through the new DC Promo dialog and fire it up. Assuming you don’t have a bunch of weird apps running on your Domain Controllers, you will likely have Longhorn out on your DCs before you have Vista deployed to a majority of your clients. If you have branch DCs the RODC helps with so many issues with those kinds of deployments, couple that with the other security upgrades and the granular password policy and Longhorn for domain controllers is really going to be a must have for many companies.

  joe

So you are in a spaceship…. In interstellar space…

Obviously you have no nearby points of reference…. Say maybe stars light-years away….

Is your spaceship moving? Yes? No?

How do you authoritatively know without nearby external points of reference that allow you to track your motion?

One of the more secret but possibly hottest new features of Longhorn Server is now “out of the closet”. It is something that has been in the last couple of customer preview versions of Longhorn available up on MSDN and blog entries from Microsoft and other parties are starting to pop up. Rumors have abounded for months and months. Some of us have known for many many many months and gave input on the whole thing but sworn to secrecy. What is it you ask???

Granular Password Policy Control!!!

[Author’s Note: All of the rest of this is about a feature that is still in a beta product, so all of it is subject to change at a moment’s notice, if you read this article and you don’t see what I am talking about, it is because it was beta when I wrote about it and it changed.]

Yes, Longhorn in its current form right now has the ability to allow multiple password policies in a single domain. Previously you couldn’t do this with a native configuration, you had to add additional domains. If you wanted to buy someone’s third party password filter or “roll your own”, you could also have multiple password policies for certain features like password length and history. Longhorn allows you to configure lockout, expiration, history, length, whether complexity is enabled or not, and more. Best of all, this can be manipulated at the global group or even at the user level.

Password policy for the domain is being taken out of the GPO system (though if you only want one policy for the entire domain you can keep it there, they aren’t forcing you to change) and put into AD objects called Password Settings objects. You can read more details of the implementation at Ulf’s blog

http://msmvps.com/blogs/ulfbsimonweidner/archive/2007/03/12/windows-server-quot-longhorn-quot-granular-password-settings.aspx

But the basics, in case Ulf’s blog isn’t available for some reason (or if I need to search my own blog to find the info again – this blog is starting to serve as part of my memory) are:

• Password Settings Objects (PSO) are created and have the various attributes (specified below) populated.
• The PSO is linked to users or global groups via a standard forward/backlink mechanism just like the membership of groups is populated. The forward link is on the PSO, the backlink is on the user/group object.
• Multiple PSO’s can be linked to a given user or group through group nesting however only one policy will be in effect for a user, it will not merge the policies as this would just cause tremendous confusion.
• You determine which PSO “wins” and is applied to a user via precedence values assigned to the PSO objects, lowest precedence wins. The precedence value is an arbitrary number that you define just like it is with site link metrics. It could be set in intervals of 1, 10, or whatever. If you have two PSO’s linked to a user object with the same precedence, lowest GUID on PSO wins (has to be something and this is consistent with several other “who wins” scenarios in AD).
• PSOs can only be applied to global groups… That is because the policies can only be applied to users in the domain where the policy exists, only users in the same domain as a global group can be members of a global group. This is a case where only having the choice of the one group scope makes perfect sense, quite unlike other arbitrary group requirements from some Microsoft and third party apps.

More nitty gritty details:

• Password Settings object objectClass: msDS-PasswordSettings
• Where are the objects kept: CN=Password Settings,CN=System,[Domain DN]
• Precedence is maintained in: msDS-PasswordSettingsPrecedence
• Reversible Encryption: msDS-PasswordReversibleEncryptionEnabled – Boolean – TRUE or FALSE
• Password History: msDS-PasswordHistoryLength – Integer – 0,1,2,3,4,5,…
• Complexity: msDS-PasswordComplexityEnabled – Boolean – TRUE or FALSE
• Length: msDS-MinimumPasswordLength – Integer – 0,1,2,3,4,5,…
• Minimum Password Age: msDS-MinimumPasswordAge – INT8 interval – this is just like it is specified on the NC Head previously
• Expiration: msDS-MaximumPasswordAge – INT8 Interval – ditto above
• Bad password count for lockout: msDS-LockoutThreshold – Integer – 0,1,2,3,4,5,…
• Reset bad password count: msDS-LockoutObservationWindow – INT8 Interval (see above)
• Lockout Duration: msDS-LockoutDuration – INT8 Interval (see above)
• Backlink on user/group object showing all linked policies: msDS-PSO-Applied
• Effective policy on a given user: msDS-Resultant-PSO (operational so you can’t query, only return)

So my personal thoughts on this???

I am elated, I think this is absolutely great. There are details that once people think about them will irk them but so what, this is functionality that companies have been clamoring for since I started working on NT4 back in the mid-90’s. The fact that they pulled the password policies out of the Group Policy system is one of the best things to happen with Group Policy ever. The domain password policy (amongst other items) being handled in GPOs was one of the most counter intuitive and confusing things about Active Directory, there are many good admins who still think you can set policy for domain users at the OU level because that is how GPOs work in general.

I would like to see more out of this. Specifically I would like to see some ability to specify some password complexity rules for instance, x number of alphanumeric characters, x number of special characters, x number of caps, can or can’t have userid in password, etc. I also requested this last week that they pass the PSO DN to the password filter DLL function (or alternately a structure with the attribute values) so that custom complexity filters could use that info easily.

I am certain this will cause heartache for some people and certainly some of my apps will need to be updated to reflect the changes, specifically FindExpAcc, OldCmp, Unlock will all need updates. However, I have no problem with this as I am so excited to see this capability in the product. I am very much applauding the efforts of MSFT and the DS teams involved to finally get this “in there”. THANK YOU!

Another good blog entry on this topic to check out is

http://blogs.technet.com/seanearp/archive/2007/03/16/windows-server-longhorn-per-user-password-policy.aspx

   joe