joeware - never stop exploring... :)

…you have an iPhone or iPod Touch…

http://itunes.apple.com/us/app/active-directory-fourth-edition/id329336118?mt=8

 

I think I might get $.10 a copy for this…

I had someone ping me about an issue with maxValRange a few months ago and they mentioned that MSFT had changed some internal hard coded limits. I meant to go look into it but never found time. This was just posted on ActiveDir Org the last few days which makes it so I don’t have to go check the source code. 🙂

http://support.microsoft.com/kb/2009267

 

Hardcoded LDAP limitations have been introduced in Windows Server 2008 R2 and Windows Server 2008 to prevent overloading the domain controller. These limits overwrite the LDAP policy setting when the policy value should be higher.

 LDAP setting              maximum value (hardcoded) 
 MaxReceiveBuffer          20971520 
 MaxPageSize                  20000 
 MaxQueryDuration              1200 
 MaxTempTableSize            100000 
 MaxValRange                   5000 

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=12a6de81-c633-4f2c-a35f-cea6fe772712

http://blogs.technet.com/configmgrteam/archive/2010/03/26/announcement-updated-configuration-manager-superflows-are-available.aspx

Recently a post on ActiveDir org reminded me that with even as much as I know about Active Directory, I still have more to learn and likely always will have more to learn. The information I put forth in this blog post may be well known to some of the folks who read it but I know there are many who didn’t have a clue or just recently learned it while I learned it publicly on ActiveDir Org and the related testing I performed during the posting myself.

The basic question was around Password Settings Objects (PSO’s) and specifically around msDS-LockoutDuration and msDS-LockoutObservationWindow. These attributes are used to define various parts of the lockout policy, specifically

• msDS-LockoutDuration specifies how long an ID is locked out, once locked.
• msDS-LockoutObservationWindow specifies how long the system should collect bad password attempts to compare to the msDS-LockoutThreshold value. For example, say your threshold is specified as 10 and you get 5 bad attempts an hour with no good attempts between the bad attempts. If your observation window is 60 minutes, you won’t ever lock out because it is only seeing 5 bads during that period. If you set the observation window to 120 minutes, well now you will get 10 bad attempts in the period and the account will lock. Make sense? Note that this DOES NOT reset the badPwdCount attribute.

The question was about what was documented in technet, specifically “The value of msDS-LockoutObservationWindow cannot be smaller than the value of msDS-LockoutDuration.” found in Appendix B: PSO Attribute Constraints (http://technet.microsoft.com/en-us/library/cc753858(WS.10).aspx).

It seems the original poster (OP) was running into an issue with setting his desired lockout policy. Specifically he wanted to set the following

Account Lockout Duration	0
Account Lockout Threshold	4
Reset Account Lockout Counter After	1 day

 

and was attempting to create the PSO via LDIF (which is fully supported) with the following

dn:CN=PSO_AdminUser,CN=Password Settings Container,CN=System,dc=intra,dc=contoso,dc=com
changetype:add
objectClass:msDS-PasswordSettings
msDS-MaximumPasswordAge:-25920000000000
msDS-MinimumPasswordAge:-864000000000
msDS-MinimumPasswordLength:10
msDS-PasswordHistoryLength:24
msDS-PasswordComplexityEnabled:TRUE
msDS-PasswordReversibleEncryptionEnabled:FALSE
msDS-LockoutObservationWindow:-864000000000
msDS-LockoutDuration:0
msDS-LockoutThreshold:10
msDS-PasswordSettingsPrecedence:30
msDS-PSOAppliesTo: CN=DL_ADDS_AdminPWpolicy,ou=groups,ou=_shared,ou=_justice,dc=intra,dc=contoso,dc=com

And when he specifies an account lockout duration of 0, he means the popularly well known/understood value that we see in the domain policy when you specify 0 which is to mean “require administrator to unlock” as seen in the following image.

 

When he ran the LDIF file through LDIFDE, Active Directory unexpectedly (to many of us) kicked back an error. Specifically “Unwilling To Perform” or more specifically “Extended Error: 000020E7: SvcErr: DSID-030F03B5, problem 5003 (WILL_NOT_PERFORM), data 0” which is duplicated with AdFind for your enjoyment here:

C:\temp>admod -b "CN=newpso10,CN=Password Settings Container,CN=System,DC=k8dom,DC=loc"  msDS-LockoutDuration::0 msds-LockoutObservationWindow::-864000000000 -exterr

AdMod V01.12.00cpp Joe Richards (joe@joeware.net) February 2010

DN Count: 1
Using server: k8dom-dc1.k8dom.loc:389
Directory: Windows Server 2008

Modifying specified objects…
   DN: CN=newpso10,CN=Password Settings Container,CN=System,DC=k8dom,DC=loc…: [k8dom-dc1.k8dom.loc] Error 0x35 (53) – Unwilling To Perform

   Extended Error: 000020E7: SvcErr: DSID-030F03B5, problem 5003 (WILL_NOT_PERFORM), data 0

ERROR: Too many errors encountered, terminating…

The command did not complete successfully

 

I was a bit shocked by this as I, like everyone else, has been taught by years and years of Windows experience that infinite lockout is a 0 value for duration but it didn’t work when you specified it in the PSO. I looked at the source code for PSO validation and it definitely showed that this error should be thrown based on that input. I, again, so well indoctrinated about what 0 means for lockout thought, wow, this is a bug and forwarded to a friend in the DS team. My friend didn’t see a flaw in my logic or at least didn’t point one out and my relationship with the DS guys is generally pretty open and if I am being stupid, they don’t have an issue telling me. :)  Anyway he indicated he would look into it.

In the meanwhile, my recommendation to the OP as a workaround was just to set the lockout duration to some large value such as one year as that would effectively be an unlimited lockout. If someone locks an account and then sits around waiting for a year to try to attack it again… all the power in the world to them… If they are that patient then likely any value for observation window likely isn’t going to work for you since they are patient enough to wait for it to reset before trying again. Certainly waiting 10 minutes or a day or 20 days is less than waiting a year.  The OP seemed content with this and I figured I would just hear back from MSFT eventually saying it was “fixed”.

A bit later, the OP came back with another post indicating that one of his friends pointed out a TechNet article (http://technet.microsoft.com/en-us/library/cc754461(WS.10).aspx) that indicated that you could specify the value of “(never)” in ADSIEDIT when working on PSO’s, and in fact he had tried it and indeed it seemed to work. This was interesting to me since the attribute is of type 2.5.5.16 (aka LARGEINTEGER) and obviously “(never)” is not a LARGEINTEGER. I fired up ADSIEDIT and tested setting msDS-LockoutDuration to (never) and as specified by the OP, shockingly, it did in fact work.

At that point all sorts of theories popped into my head but the first thing I needed to do was test to see if “(never)” was being handled by ADSIEDIT or the DSA. This is an easy test:

C:\temp>admod -b "CN=newpso10,CN=Password Settings Container,CN=System,DC=k8dom,DC=loc"  msDS-LockoutDuration::(never) -exterr

AdMod V01.12.00cpp Joe Richards (joe@joeware.net) February 2010

DN Count: 1
Using server: k8dom-dc1.k8dom.loc:389
Directory: Windows Server 2008

Modifying specified objects…
   DN: CN=newpso10,CN=Password Settings Container,CN=System,DC=k8dom,DC=loc…: [k8dom-dc1.k8dom.loc] Error 0x15 (21) – Invalid Syntax

   Extended Error: 00000057: LdapErr: DSID-0C090B73, comment: Error in attribute conversion operation, data 0, v1771

ERROR: Too many errors encountered, terminating…

The command did not complete successfully

This authoritatively proved the “(never)” value was being handled in ADSIEDIT. So looking at the PSO object after ADSIEDIT set the attribute to the value –9223372036854775808.

C:\temp>adfind -b "CN=newpso10,CN=Password Settings Container,CN=System,DC=k8dom,DC=loc" -samdc -tdcd -tdcas msds-lockoutduration

AdFind V01.41.00cpp Joe Richards (joe@joeware.net) February 2010

Using server: k8dom-dc1.k8dom.loc:389
Directory: Windows Server 2008

dn:CN=newpso10,CN=Password Settings Container,CN=System,DC=k8dom,DC=loc
>msDS-LockoutDuration: -9223372036854775808 [undefined]

1 Objects returned

This was all previously unknown to me but made sense, and in fact, the workaround I mentioned to the OP was drifting in this direction. However… this made me think… what about the domain policy? Does the same thing happen there? You set the domain policy (normally) via the Group Policy Editor tools, editing it via LDAP never really comes up[1]. So to validate I edited the domain policy to unlimited duration lockout and checked the lockoutDuration attribute on the domain head and sure enough, it had the same value.

C:\temp>adfind -default -s base lockoutduration

AdFind V01.41.00cpp Joe Richards (joe@joeware.net) February 2010

Using server: k8dom-dc1.k8dom.loc:389
Directory: Windows Server 2008
Base DN: DC=k8dom,DC=loc

dn:DC=k8dom,DC=loc
>lockoutDuration: -9223372036854775808

1 Objects returned

Shortly after working this out, my DS team friend got back to me and indicated that the PSO value checking was pulled straight from the domain value checking and it was likely something handled in the GUI. That of course aligned exactly to what I was seeing and explained what I figured out. I also said the documentation all needs to be updated to reflect this information. It wasn’t so important when just the domain policy was involved because the primary supported mechanism for updating the domain policy is through the GPO Editor, but PSO’s bring a new twist to this and using LDAP tools like LDIFDE are indicated to create and manage these objects.

Hopefully folks find this info useful and now I have to add a DCR to the list of DCRs for PSOMgr, AdMod and AdFind to reflect this new information. 

 

    joe

 

[1] An unlimited lockout duration also doesn’t normally come up for me. It isn’t something I recommend as lockouts can be used for some nasty Denial Of Service (DOS) attacks.

Yesterday I received an email from one of the faithful joeware customer’s with an issue that when I first started reading confused me and then as I continued reading I was reminded of my earlier, eviler, more maverick days… The days when men were men and sheep were scared, at least in New Zealand and parts of Australia and the Netherlands. Of course we are talking about the early years of Windows 2000… But let’s have Art explain a little about what he saw…

…we discovered an interesting issue with ADFIND last week in our SYS AD forest (systems testing). Turns out ADFIND and a number of our scripts stopped working for some reason. We are able to run the tool in two other forests that mirror SYS and ADFIND runs with no issues. When we attempt to perform a query with ADFIND in SYS it returns the below error:

>adfind -b "DC=domain,DC=com" -f "objectcategory=user"
AdFind V01.41.00cpp Joe Richards (joe@joeware.net<mailto:joe@joeware.net>) February 2010
LDAP_SEARCH_S: 0x4
LDAP_SEARCH_S: Size Limit Exceeded

After I read that I thought… Oh that can’t be good, but that is AD, not AdFind as I use paged searches like a good little LDAP dev…

Then I read on through the various levels of testing that Art and his compatriots performed and then I started chuckling when I hit

Debug time … I executed the same query with ADFIND only added the debug switch ‘-d’

>adfind -b "DC=domain,DC=com" -f "objectcategory=user" -d
AdFind V01.41.00cpp Joe Richards (joe@joeware.net<mailto:joe@joeware.net>) February 2010
DEBUG: Opening TCP connection
DEBUG: In OpenLDAP… Params:
DEBUG:    ARecEx: 0
DEBUG:    SSL: 0
DEBUG:    Port:        389
DEBUG:    Ref:       1
DEBUG:    V3:        1
DEBUG:    Anonymous: 0
DEBUG:    userdn:
DEBUG:    password:
DEBUG:    Simple: 0
DEBUG:    Digest Auth: 0
DEBUG:    LDAP_OPT_ENCRYPT: 0
DEBUG:    Delegation: 0
DEBUG:    Req Writeable: 0
DEBUG:    Extended Error Info: 0
LDAP_OPTION: Version 3
LDAP_OPTIONS SET
LDAP_BIND: [(null)] Successful
DEBUG: Gathering RootDSE
DEBUG: Entering CRootDSE…
DEBUG: Leaving CRootDSE.
DEBUG: RootDSE Completed
DEBUG: Loading OIDs from schema…
LDAP_SEARCH_S: 0x4
LDAP_SEARCH_S: Size Limit Exceeded

You may think it is odd that I started chuckling, but I did because I knew for sure I was to blame. I had been stupid. Or at least severely myopic. But I continued reading anyway…

Something in the schema is clearly causing the size limit error. Recently we extended the schema in SYS for Exchange 2007 SP2, OCS 2007 R2, and SCCM 2007. These changes have NOT yet been introduced in our 2 other forests and are scheduled for implementation in April and May.

And further along the email…

Lab time. I took this into an isolated AD environment (vanilla install of win2k3 sp2 / default AD query values) and using ADSchemaAnalyzer exported our production AD schema (the one without Exchange 2007 SP2/OCS 2007 R2/SCCM 2007) and imported into my lab. ADFIND works as expected and returns the results for all queries. I then extended the schema for Exchange 2007 SP2. Immediately after the schema extension I am able to reproduce the issue and see the same size limit exceeded error:

and still further

Same failure, immediately after ADFIND loads the OIDs from the schema. I decided to change the MaxPageSize in Active Directory to 10, 000, reboot and ADFIND works again. I change it back to 1000, reboot and ADFIND fails. After digging around the ADFIND help file I noticed the tool includes a switch ‘-dloid’:

And finally

ADFIND returns all the user objects in my isolated lab forest. I then ran the same query in our SYS forest and ADFIND and all our ADFIND dependant scripts start working again. Interesting that by either adding the -dloid switch or changing the MaxPageSize in AD to 10,000 immediately fixes the issue. Changing the MaxPageSize to 10,000 will not be possible given MS recommendations and Exchange requirements for this value to be set at 1000. For the time being I’m using the DLOID switch.

Any idea what could be causing the failure without the DLOID switch? is it something specific to the Exchange 2007 SP2 schema upgrade? or did we exceed some sort of limit somewhere? let me know if there are any additional logs we can gather for you.

 

As I mentioned, I knew pretty early on that I was at fault and every paragraph after that re-emphasized that it was my problem. I was happy to see the depth and quality of Art’s debugging of the issue. Great job Art. 🙂

The history behind the issue… back in the wild days of Windows 2000 when I first put AdFind together, I knew of no other way to determine how to decode various attributes than to have a set of mapping structures to identify the attributes when they were encountered. That way I knew which attributes to decode as time fields, which were SIDs, which were GUIDs, which were binary, etc. I would manually update the maps as I found the attributes. This worked ok initially but once I went north of 400 separate requests for people who wanted me to add “their” custom attributes I decided I needed to do something else and I implemented it in V01.09.00 in 2002.

That something else ended up as a routine that tore through various attributes in the schema looking for the types that I cared about and building the attribute maps dynamically on the fly. The –dloid switch avoids that process. Even if you use –dloid, there are still some attributes hardcoded into the maps so there will be some decoding that occurs, just not all of the decoding that could occur.

Anyway… the stupid assumption I made, and obviously now quite embarrassed by, is that I used a non-paged search to pull the attributes I wanted from the schema. Back when I did it I knew that paged searches were goodness and should be used but I never really thought it would be an issue for this specific query… I mean seriously, even in a default Windows Server 2003 schema, there are only 293 attributes that I pick up for my query and the failure doesn’t occur until after 1000 attributes of type DN, binary, or SID… Lots of head room right? Should be safe right? Wrong… And this is why we tell people to use paged queries when requesting information from Active Directory, this very reason.

To validate the issue I simply changed my lDAPAdminLimits MaxPageSize value to 10 and sure enough… Kaboom.

F:\Dev\Current\CPP\AdFind\Release>adfind -default -s base

AdFind V01.42.00cpp ***BETA*** Joe Richards (joe@joeware.net) March 2010

LDAP_SEARCH_S: 0x4
LDAP_SEARCH_S: Size Limit Exceeded

So I fixed the issue by changing the section that pulls the info from schema to use a paged query just like I should have used in the first place. Ran the new binary against my “hacked” test directory with a MaxPageSize of 10 entries and it worked like a champ. I sent the link to the beta binary to Art and he tested it in his environment and he is working A-OK again.

If anyone else is having the issue and wants to try the beta, you can find the new betas for AdFind and AdMod at

http://www.joeware.net/downloads/beta/adfindmod_beta.zip

The AdMod beta has a rather large fix in it as well, but I am not ready to discuss that yet. However your data is safe, it was a crash issue when data was specified in a specific way.

    joe