More NET::LDAP questions

[Steve The Geek]

I have the script running to plow through out AD structure and pull
out all the disabled accounts.

I've also got the damnedable thing parsing the logon script for
userhome drive mappings, getting the last logon date, and highlighting
the user's distinguished name.

According to MS, an LDAP query of
(useraccountcontrol:1.2.840.113556.1.4.803:=2) should pull up all
expired accounts. From the LDP utility in the Windows 2000 resource
kit, it works.

What I get in perl is:

I/O Error at SearchViaLdapForExpiredAccounts-modified.pl line 45

I've had to pull out the combinations that work, but damn...



Here's the relevant (working) code section:

$mesg = $ldap->search( # find all objects with "accountDisabled" set
base => 'DC=workplace,DC=com',
filter => '(|(useraccountcontrol=2)
(useraccountcontrol=514)
(useraccountcontrol=18)
(useraccountcontrol=34)
(useraccountcontrol=52)
(useraccountcontrol=66)
(useraccountcontrol=84)
(useraccountcontrol=136)
(useraccountcontrol=514)
(useraccountcontrol=532)
(useraccountcontrol=584)
(useraccountcontrol=668)
(useraccountcontrol=65538)
(useraccountcontrol=65556)
(useraccountcontrol=65608)
(useraccountcontrol=65692)
(useraccountcontrol=66360)
(useraccountcontrol=8388610)
(useraccountcontrol=8388628)
(useraccountcontrol=8388680)
(useraccountcontrol=8388764)
(useraccountcontrol=8389432)
(useraccountcontrol=8455792))',
attrs => ['memberof',
'samaccountname',
'homedirectory',
'name',
'distinguishedname',
'lastlogon']
);

print $mesg->count," enteries found.\n";

$mesg->code && die $mesg->error;

<end code section>

Any thoughts of why the easier 1.2.840.113556.1.4.803:=2 won't work?

Thanks!

Steve the (**** MS) Geek

 

[pkent]

According to MS, an LDAP query of
(useraccountcontrol:1.2.840.113556.1.4.803:=2) should pull up all
expired accounts. From the LDP utility in the Windows 2000 resource
kit, it works. ....
Any thoughts of why the easier 1.2.840.113556.1.4.803:=2 won't work?

Our LDAP books are all in the office technical library and, given it's
23:38, I'm nowhere near work but I do think that Net::LDAP _can_
handle these strings-of-numbers. A quick look at the docs reveals the
'CONTROLS' section near the bottom where you can specify an OID. No idea
if that's any help though...

Actually, the example code download at:
http://www.winnetmag.com/Articles/ArticleID/38058/pg/3/3.html
gives me a hint. Listing 3 has these lines:

....
sub LDAP_CONTROL_TREE_DELETE () { "1.2.840.113556.1.4.805" }
....
my $treedelc = Net::LDAP::Control->new( LDAP_CONTROL_TREE_DELETE );
$rc = $ldap->delete($dn_to_delete, control => [ $treedelc ]);
....

so maybe you can create your own control with that OID that you have and
use that in the search() call.

P

 

[Steve The Geek]

According to MS, an LDAP query of

Actually, the example code download at:
http://www.winnetmag.com/Articles/ArticleID/38058/pg/3/3.html
gives me a hint. Listing 3 has these lines:

...
sub LDAP_CONTROL_TREE_DELETE () { "1.2.840.113556.1.4.805" }
...
my $treedelc = Net::LDAP::Control->new( LDAP_CONTROL_TREE_DELETE );
$rc = $ldap->delete($dn_to_delete, control => [ $treedelc ]);
...

so maybe you can create your own control with that OID that you have and
use that in the search() call.

Took the advice.

###new code snippets:

my $LogicalOrOid = Net::LDAP::Control->new(
type => "1.2.840.113556.1.4.803",
critical => "1",
value => "LDAP_MATCHING_RULE_BIT_AND"
);

....

$mesg = $ldap->search( # perform a search on all useful permutations
of "accountDisabled"
base => 'DC=workplace,DC=com',
scope => 'sub',
sizelimit => '1',
filter => '(useraccountcontrol=2)',
control => [$LogicalOrOid],
attrs => ['memberof',
'samaccountname',
'homedirectory',
'name',
'distinguishedname',
'lastlogon'],
);

### End new code snippets

Now it kicks back a whole new error:

00000057: LdapErr: DSID-0C090591, comment: Error processing control,
data 0, v893l line 55

Mind you, if I change the filter criteria to '(useraccountcontrol=*)'
it returns all users without fail. No other filter value in
useraccountcontrol works.

According to MS[1] this error is the result of a second request
arriving at the LDAP server prior to results coming back for the first
one. They claim[2] this was fixed in W2K SP4.

We *are* running SP4, and the files referenced in the KB article are
up-to-date. And, as the snippet above shows, I've set sizelimit => "1"
-- in theory, this should cause the queries to wait for one response
before sending another.

Furrfu.

I'm of the mindset that this is a MS problem and no longer a perl one.
:-/

Steve the (anyone have the coordinates for Redmond WA handy?) Geek

[1] http://support.microsoft.com/default.aspx?kbid=329727
[2] for values of 'claim' that include 'because we say so'...