UserAccountControl Attribute

  • Thread starter Thread starter Dixson
  • Start date Start date
D

Dixson

We have a custom application that uses an LDAP query against AD (2000 native)
to provide a list of all active user accounts but, the results of the query
is missing a handfull of active user accounts. From what I've been able to
find, all the user accounts in question are not flagged as NORMAL_ACCOUNT
(hex=0x0200, dec=512) but, when I've checked the properties of each account
in AD there's nothing different from the accounts that appear from the query.

Can ldp.exe or adsiedit.msc help find what may be different about the user
accounts in question? If so, is there a good "for dummies" on how to use
these tools?
 
what is your definition of ACTIVE accounts?

do you mean accounts that are NOT DISABLED?

if yes, use the following filter in the following example:
ADFIND -bit -default -f
"(&(objectCategory=person)(objectClass=user)(!(userAccountControl:AND:=2)))"
sAMAccountName

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services #

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
 
Dixson said:
We have a custom application that uses an LDAP query against AD (2000
native)
to provide a list of all active user accounts but, the results of the
query
is missing a handfull of active user accounts. From what I've been able
to
find, all the user accounts in question are not flagged as NORMAL_ACCOUNT
(hex=0x0200, dec=512) but, when I've checked the properties of each
account
in AD there's nothing different from the accounts that appear from the
query.

Can ldp.exe or adsiedit.msc help find what may be different about the user
accounts in question? If so, is there a good "for dummies" on how to use
these tools?
Click to expand...

The userAccountControl attribute is a integer used to indicate several
things. You cannot just look at the integer value. You must AND the value
with a bit mask to check for each condition. For example, the bit mask for a
normal account is &H200 (512 decimal). If lngFlag is the value of the
userAccountControl attribute, then:
=========
Const ADS_UF_NORMAL_ACCOUNT = &H200

lngFlag = 512
If (lngFlag AND ADS_UF_NORMAL_ACCOUNT) <> 0 Then
Wscript.Echo "Normal user account"
Else
Wscript.Echo "NOT a normal user account"
End If
========
The above shows that 512 corresponds to a normal user account, but many
other values do also. For example 514 (a disabled account), 544 (no password
required), 546 (disabled and no password required), and 66048 (password does
not expire).

The LDAP query for all user objects should be similar to:

(&(objectCategory=person)(objectClass=user)

However, the following also works (it's just harder to remember):

(sAMAccountType=805306368)

What does your query look like? What values for userAccountControl do you
see? Also, how many user objects are returned by the query?
 
Thanks for the input fellas. As we continued to dig into this what we've
found is all the user accounts that are found by the query have a count of 6
_hashtable entries...the accounts we're having issues with only have 4. The
AD atributes 'MEMBEROF' and 'userACCOUNTCONTROL' are not found or included
in the _hashtable results so when masked with the bit for NORMAL_ACCOUNT the
results become false.

I beleive the query is written in ASP.net...I'm not the developer but just
the guy trying to get everyone to show on the list.

I believe this is the query:

string[] Parameters = { "samaccountname", "cn", "mail", "memberof",
"useraccountcontrol" };
try
{
DirectoryEntry entry = new DirectoryEntry("LDAP://" +
AdDomain, AdAccount, AdPassword);
DirectorySearcher Searcher = new DirectorySearcher(entry);
Searcher.Filter = "(objectCategory=" + "user" + ")";
foreach (string parameter in Parameters)
{
Searcher.PropertiesToLoad.Add(parameter);
}
Searcher.Sort.PropertyName = "cn";

XmlElement RowsNode =
(XmlElement)UsersDoc.DocumentElement.SelectSingleNode("Rows");

foreach (SearchResult result in Searcher.FindAll())
{
DirectoryEntry Entry = result.GetDirectoryEntry();

ResultPropertyCollection PropColl = result.Properties;
string AccountName = null;
string CommonName = null;
string EmailAddress = null;
bool NORMAL_ACCOUNT = false;
bool ACCOUNTDISABLE = false;
Int32 AccountControl = 0;

foreach (string Key in PropColl.PropertyNames)
{
if (Key == "samaccountname")
{
AccountName = PropColl[Key][0].ToString();
}
if (Key == "cn")
{
CommonName = PropColl[Key][0].ToString();
}
if (Key == "mail")
{
EmailAddress = PropColl[Key][0].ToString();
}
if (Key == "useraccountcontrol")
{
//http://support.microsoft.com/kb/305144
AccountControl = (Int32)PropColl[Key][0];
NORMAL_ACCOUNT = ((AccountControl & 0x00000200)
0);
Click to expand...
ACCOUNTDISABLE = ((AccountControl & 0x00000002)
0);
Click to expand...
 
The filter "(objectCategory=user)" will include contact objects as well as
user objects. Contact objects do not have sAMAccountName or
userAccountControl attributes. Does this explain what you experience?

As noted before, the filter should be
"(&(objectCategory=person)(objectClass=user))". This will exclude contact
objects. Contact objects do have cn, mail, and memberOf attributes.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

Dixson said:
Thanks for the input fellas. As we continued to dig into this what we've
found is all the user accounts that are found by the query have a count of
6
_hashtable entries...the accounts we're having issues with only have 4.
The
AD atributes 'MEMBEROF' and 'userACCOUNTCONTROL' are not found or
included
in the _hashtable results so when masked with the bit for NORMAL_ACCOUNT
the
results become false.

I beleive the query is written in ASP.net...I'm not the developer but just
the guy trying to get everyone to show on the list.

I believe this is the query:

string[] Parameters = { "samaccountname", "cn", "mail", "memberof",
"useraccountcontrol" };
try
{
DirectoryEntry entry = new DirectoryEntry("LDAP://" +
AdDomain, AdAccount, AdPassword);
DirectorySearcher Searcher = new DirectorySearcher(entry);
Searcher.Filter = "(objectCategory=" + "user" + ")";
foreach (string parameter in Parameters)
{
Searcher.PropertiesToLoad.Add(parameter);
}
Searcher.Sort.PropertyName = "cn";

XmlElement RowsNode =
(XmlElement)UsersDoc.DocumentElement.SelectSingleNode("Rows");

foreach (SearchResult result in Searcher.FindAll())
{
DirectoryEntry Entry = result.GetDirectoryEntry();

ResultPropertyCollection PropColl = result.Properties;
string AccountName = null;
string CommonName = null;
string EmailAddress = null;
bool NORMAL_ACCOUNT = false;
bool ACCOUNTDISABLE = false;
Int32 AccountControl = 0;

foreach (string Key in PropColl.PropertyNames)
{
if (Key == "samaccountname")
{
AccountName = PropColl[Key][0].ToString();
}
if (Key == "cn")
{
CommonName = PropColl[Key][0].ToString();
}
if (Key == "mail")
{
EmailAddress = PropColl[Key][0].ToString();
}
if (Key == "useraccountcontrol")
{
//http://support.microsoft.com/kb/305144
AccountControl = (Int32)PropColl[Key][0];
NORMAL_ACCOUNT = ((AccountControl & 0x00000200)
0);
Click to expand...
ACCOUNTDISABLE = ((AccountControl & 0x00000002)
0);
Click to expand...



Dixson said:
We have a custom application that uses an LDAP query against AD (2000
native)
to provide a list of all active user accounts but, the results of the
query
is missing a handfull of active user accounts. From what I've been able
to
find, all the user accounts in question are not flagged as NORMAL_ACCOUNT
(hex=0x0200, dec=512) but, when I've checked the properties of each
account
in AD there's nothing different from the accounts that appear from the
query.

Can ldp.exe or adsiedit.msc help find what may be different about the
user
accounts in question? If so, is there a good "for dummies" on how to use
these tools?
Click to expand...
Click to expand...
 
Thanks for your time Richard!

It's similar to your explaination but not related to contact objects...it's
specific user objects (enabled user accounts) that appear to be missing those
two attributes.

The developer is here today and he changed the filter to match what you
suggested just to see what would happen but no joy. Everything we've tried
points to missing those two attributes (MEMBEROF and userACCOUNTCONTROL).
How can I view the attributes of the user objects in question?

Chad

Richard Mueller said:
The filter "(objectCategory=user)" will include contact objects as well as
user objects. Contact objects do not have sAMAccountName or
userAccountControl attributes. Does this explain what you experience?

As noted before, the filter should be
"(&(objectCategory=person)(objectClass=user))". This will exclude contact
objects. Contact objects do have cn, mail, and memberOf attributes.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

Dixson said:
Thanks for the input fellas. As we continued to dig into this what we've
found is all the user accounts that are found by the query have a count of
6
_hashtable entries...the accounts we're having issues with only have 4.
The
AD atributes 'MEMBEROF' and 'userACCOUNTCONTROL' are not found or
included
in the _hashtable results so when masked with the bit for NORMAL_ACCOUNT
the
results become false.

I beleive the query is written in ASP.net...I'm not the developer but just
the guy trying to get everyone to show on the list.

I believe this is the query:

string[] Parameters = { "samaccountname", "cn", "mail", "memberof",
"useraccountcontrol" };
try
{
DirectoryEntry entry = new DirectoryEntry("LDAP://" +
AdDomain, AdAccount, AdPassword);
DirectorySearcher Searcher = new DirectorySearcher(entry);
Searcher.Filter = "(objectCategory=" + "user" + ")";
foreach (string parameter in Parameters)
{
Searcher.PropertiesToLoad.Add(parameter);
}
Searcher.Sort.PropertyName = "cn";

XmlElement RowsNode =
(XmlElement)UsersDoc.DocumentElement.SelectSingleNode("Rows");

foreach (SearchResult result in Searcher.FindAll())
{
DirectoryEntry Entry = result.GetDirectoryEntry();

ResultPropertyCollection PropColl = result.Properties;
string AccountName = null;
string CommonName = null;
string EmailAddress = null;
bool NORMAL_ACCOUNT = false;
bool ACCOUNTDISABLE = false;
Int32 AccountControl = 0;

foreach (string Key in PropColl.PropertyNames)
{
if (Key == "samaccountname")
{
AccountName = PropColl[Key][0].ToString();
}
if (Key == "cn")
{
CommonName = PropColl[Key][0].ToString();
}
if (Key == "mail")
{
EmailAddress = PropColl[Key][0].ToString();
}
if (Key == "useraccountcontrol")
{
//http://support.microsoft.com/kb/305144
AccountControl = (Int32)PropColl[Key][0];
NORMAL_ACCOUNT = ((AccountControl & 0x00000200)
0);
Click to expand...
ACCOUNTDISABLE = ((AccountControl & 0x00000002)
0);
Click to expand...



Dixson said:
We have a custom application that uses an LDAP query against AD (2000
native)
to provide a list of all active user accounts but, the results of the
query
is missing a handfull of active user accounts. From what I've been able
to
find, all the user accounts in question are not flagged as NORMAL_ACCOUNT
(hex=0x0200, dec=512) but, when I've checked the properties of each
account
in AD there's nothing different from the accounts that appear from the
query.

Can ldp.exe or adsiedit.msc help find what may be different about the
user
accounts in question? If so, is there a good "for dummies" on how to use
these tools?
Click to expand...
Click to expand...
Click to expand...
 
I assume by "missing" you mean that no value is assigned (the value is "not
set"). I don't think it is possible for a user object to have no value
assigned to userAccountControl, but it is certainly possible that the
memberOf attribute, which is multi-valued, could have no values in the
collection (the user is a direct member of no groups other than the
"primary" group). By default, the "primary" group for users is "Domain
Users". If this is the only group the user is a direct member of, the
memberOf attribute will be Empty. Perhaps this causes your problem.

In ADUC you can view direct group memberships on the "Member Of" tab of the
user properties dialog. If there is just one entry, the memberOf attribute
is Empty. You can also see this with a tool like ADSI Edit (part of the
Windows 2000 Support Tools). In fact, the number of DN's in the memberOf
attribute is always one less than the number of groups that show up on the
"Member Of" tab of ADUC.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

Dixson said:
Thanks for your time Richard!

It's similar to your explaination but not related to contact
objects...it's
specific user objects (enabled user accounts) that appear to be missing
those
two attributes.

The developer is here today and he changed the filter to match what you
suggested just to see what would happen but no joy. Everything we've
tried
points to missing those two attributes (MEMBEROF and userACCOUNTCONTROL).
How can I view the attributes of the user objects in question?

Chad

Richard Mueller said:
The filter "(objectCategory=user)" will include contact objects as well
as
user objects. Contact objects do not have sAMAccountName or
userAccountControl attributes. Does this explain what you experience?

As noted before, the filter should be
"(&(objectCategory=person)(objectClass=user))". This will exclude contact
objects. Contact objects do have cn, mail, and memberOf attributes.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

Dixson said:
Thanks for the input fellas. As we continued to dig into this what
we've
found is all the user accounts that are found by the query have a count
of
6
_hashtable entries...the accounts we're having issues with only have 4.
The
AD atributes 'MEMBEROF' and 'userACCOUNTCONTROL' are not found or
included
in the _hashtable results so when masked with the bit for
NORMAL_ACCOUNT
the
results become false.

I beleive the query is written in ASP.net...I'm not the developer but
just
the guy trying to get everyone to show on the list.

I believe this is the query:

string[] Parameters = { "samaccountname", "cn", "mail", "memberof",
"useraccountcontrol" };
try
{
DirectoryEntry entry = new DirectoryEntry("LDAP://" +
AdDomain, AdAccount, AdPassword);
DirectorySearcher Searcher = new
DirectorySearcher(entry);
Searcher.Filter = "(objectCategory=" + "user" + ")";
foreach (string parameter in Parameters)
{
Searcher.PropertiesToLoad.Add(parameter);
}
Searcher.Sort.PropertyName = "cn";

XmlElement RowsNode =
(XmlElement)UsersDoc.DocumentElement.SelectSingleNode("Rows");

foreach (SearchResult result in Searcher.FindAll())
{
DirectoryEntry Entry = result.GetDirectoryEntry();

ResultPropertyCollection PropColl =
result.Properties;
string AccountName = null;
string CommonName = null;
string EmailAddress = null;
bool NORMAL_ACCOUNT = false;
bool ACCOUNTDISABLE = false;
Int32 AccountControl = 0;

foreach (string Key in PropColl.PropertyNames)
{
if (Key == "samaccountname")
{
AccountName = PropColl[Key][0].ToString();
}
if (Key == "cn")
{
CommonName = PropColl[Key][0].ToString();
}
if (Key == "mail")
{
EmailAddress = PropColl[Key][0].ToString();
}
if (Key == "useraccountcontrol")
{
//http://support.microsoft.com/kb/305144
AccountControl = (Int32)PropColl[Key][0];
NORMAL_ACCOUNT = ((AccountControl &
0x00000200)
0);
ACCOUNTDISABLE = ((AccountControl &
0x00000002)
0);



:

We have a custom application that uses an LDAP query against AD (2000
native)
to provide a list of all active user accounts but, the results of the
query
is missing a handfull of active user accounts. From what I've been
able
to
find, all the user accounts in question are not flagged as
NORMAL_ACCOUNT
(hex=0x0200, dec=512) but, when I've checked the properties of each
account
in AD there's nothing different from the accounts that appear from the
query.

Can ldp.exe or adsiedit.msc help find what may be different about the
user
accounts in question? If so, is there a good "for dummies" on how to
use
these tools?
Click to expand...
Click to expand...
Click to expand...
 
I hope this doesn't make your head spin...when I stated "missing" I meant
missing. The LDAP query is running against AD...asking for the parameters of
"samaccountname", "cn", "mail", "memberof", and "useraccountcontrol". The
results for some of the user object do not return any value (not even null)
for memberof and useraccountcontrol.

Your suggestion that the "memberof" attribute would have no value if the
user is not a member of another group (besides primary) is logical but not
the case because the missing results (user objects) have direct membership
several other groups.

I'm sure you're just as bewildered as we are. I'm going to dabble with
ADSIedit to see what differences I can find about the user accounts in
question. Do you know where I would go in ADSIedit to find the attributes
and the values they are set to?

Richard Mueller said:
I assume by "missing" you mean that no value is assigned (the value is "not
set"). I don't think it is possible for a user object to have no value
assigned to userAccountControl, but it is certainly possible that the
memberOf attribute, which is multi-valued, could have no values in the
collection (the user is a direct member of no groups other than the
"primary" group). By default, the "primary" group for users is "Domain
Users". If this is the only group the user is a direct member of, the
memberOf attribute will be Empty. Perhaps this causes your problem.

In ADUC you can view direct group memberships on the "Member Of" tab of the
user properties dialog. If there is just one entry, the memberOf attribute
is Empty. You can also see this with a tool like ADSI Edit (part of the
Windows 2000 Support Tools). In fact, the number of DN's in the memberOf
attribute is always one less than the number of groups that show up on the
"Member Of" tab of ADUC.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

Dixson said:
Thanks for your time Richard!

It's similar to your explaination but not related to contact
objects...it's
specific user objects (enabled user accounts) that appear to be missing
those
two attributes.

The developer is here today and he changed the filter to match what you
suggested just to see what would happen but no joy. Everything we've
tried
points to missing those two attributes (MEMBEROF and userACCOUNTCONTROL).
How can I view the attributes of the user objects in question?

Chad

Richard Mueller said:
The filter "(objectCategory=user)" will include contact objects as well
as
user objects. Contact objects do not have sAMAccountName or
userAccountControl attributes. Does this explain what you experience?

As noted before, the filter should be
"(&(objectCategory=person)(objectClass=user))". This will exclude contact
objects. Contact objects do have cn, mail, and memberOf attributes.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

Thanks for the input fellas. As we continued to dig into this what
we've
found is all the user accounts that are found by the query have a count
of
6
_hashtable entries...the accounts we're having issues with only have 4.
The
AD atributes 'MEMBEROF' and 'userACCOUNTCONTROL' are not found or
included
in the _hashtable results so when masked with the bit for
NORMAL_ACCOUNT
the
results become false.

I beleive the query is written in ASP.net...I'm not the developer but
just
the guy trying to get everyone to show on the list.

I believe this is the query:

string[] Parameters = { "samaccountname", "cn", "mail", "memberof",
"useraccountcontrol" };
try
{
DirectoryEntry entry = new DirectoryEntry("LDAP://" +
AdDomain, AdAccount, AdPassword);
DirectorySearcher Searcher = new
DirectorySearcher(entry);
Searcher.Filter = "(objectCategory=" + "user" + ")";
foreach (string parameter in Parameters)
{
Searcher.PropertiesToLoad.Add(parameter);
}
Searcher.Sort.PropertyName = "cn";

XmlElement RowsNode =
(XmlElement)UsersDoc.DocumentElement.SelectSingleNode("Rows");

foreach (SearchResult result in Searcher.FindAll())
{
DirectoryEntry Entry = result.GetDirectoryEntry();

ResultPropertyCollection PropColl =
result.Properties;
string AccountName = null;
string CommonName = null;
string EmailAddress = null;
bool NORMAL_ACCOUNT = false;
bool ACCOUNTDISABLE = false;
Int32 AccountControl = 0;

foreach (string Key in PropColl.PropertyNames)
{
if (Key == "samaccountname")
{
AccountName = PropColl[Key][0].ToString();
}
if (Key == "cn")
{
CommonName = PropColl[Key][0].ToString();
}
if (Key == "mail")
{
EmailAddress = PropColl[Key][0].ToString();
}
if (Key == "useraccountcontrol")
{
//http://support.microsoft.com/kb/305144
AccountControl = (Int32)PropColl[Key][0];
NORMAL_ACCOUNT = ((AccountControl &
0x00000200)
0);
ACCOUNTDISABLE = ((AccountControl &
0x00000002)
0);



:

We have a custom application that uses an LDAP query against AD (2000
native)
to provide a list of all active user accounts but, the results of the
query
is missing a handfull of active user accounts. From what I've been
able
to
find, all the user accounts in question are not flagged as
NORMAL_ACCOUNT
(hex=0x0200, dec=512) but, when I've checked the properties of each
account
in AD there's nothing different from the accounts that appear from the
query.

Can ldp.exe or adsiedit.msc help find what may be different about the
user
accounts in question? If so, is there a good "for dummies" on how to
use
these tools?
Click to expand...
Click to expand...
Click to expand...
 
In ADSI Edit you navigate to objects in AD just as you do in ADUC. Once you
find the object you want right-click it and select "Properties". All of the
attributes, their syntax, and their values are displayed in alphabetical
order. Double click an attribute name to view the value or values.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

Dixson said:
I hope this doesn't make your head spin...when I stated "missing" I meant
missing. The LDAP query is running against AD...asking for the parameters
of
"samaccountname", "cn", "mail", "memberof", and "useraccountcontrol". The
results for some of the user object do not return any value (not even
null)
for memberof and useraccountcontrol.

Your suggestion that the "memberof" attribute would have no value if the
user is not a member of another group (besides primary) is logical but not
the case because the missing results (user objects) have direct membership
several other groups.

I'm sure you're just as bewildered as we are. I'm going to dabble with
ADSIedit to see what differences I can find about the user accounts in
question. Do you know where I would go in ADSIedit to find the attributes
and the values they are set to?

Richard Mueller said:
I assume by "missing" you mean that no value is assigned (the value is
"not
set"). I don't think it is possible for a user object to have no value
assigned to userAccountControl, but it is certainly possible that the
memberOf attribute, which is multi-valued, could have no values in the
collection (the user is a direct member of no groups other than the
"primary" group). By default, the "primary" group for users is "Domain
Users". If this is the only group the user is a direct member of, the
memberOf attribute will be Empty. Perhaps this causes your problem.

In ADUC you can view direct group memberships on the "Member Of" tab of
the
user properties dialog. If there is just one entry, the memberOf
attribute
is Empty. You can also see this with a tool like ADSI Edit (part of the
Windows 2000 Support Tools). In fact, the number of DN's in the memberOf
attribute is always one less than the number of groups that show up on
the
"Member Of" tab of ADUC.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

Dixson said:
Thanks for your time Richard!

It's similar to your explaination but not related to contact
objects...it's
specific user objects (enabled user accounts) that appear to be missing
those
two attributes.

The developer is here today and he changed the filter to match what you
suggested just to see what would happen but no joy. Everything we've
tried
points to missing those two attributes (MEMBEROF and
userACCOUNTCONTROL).
How can I view the attributes of the user objects in question?

Chad

:

The filter "(objectCategory=user)" will include contact objects as
well
as
user objects. Contact objects do not have sAMAccountName or
userAccountControl attributes. Does this explain what you experience?

As noted before, the filter should be
"(&(objectCategory=person)(objectClass=user))". This will exclude
contact
objects. Contact objects do have cn, mail, and memberOf attributes.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

Thanks for the input fellas. As we continued to dig into this what
we've
found is all the user accounts that are found by the query have a
count
of
6
_hashtable entries...the accounts we're having issues with only have
4.
The
AD atributes 'MEMBEROF' and 'userACCOUNTCONTROL' are not found or
included
in the _hashtable results so when masked with the bit for
NORMAL_ACCOUNT
the
results become false.

I beleive the query is written in ASP.net...I'm not the developer
but
just
the guy trying to get everyone to show on the list.

I believe this is the query:

string[] Parameters = { "samaccountname", "cn", "mail", "memberof",
"useraccountcontrol" };
try
{
DirectoryEntry entry = new DirectoryEntry("LDAP://" +
AdDomain, AdAccount, AdPassword);
DirectorySearcher Searcher = new
DirectorySearcher(entry);
Searcher.Filter = "(objectCategory=" + "user" + ")";
foreach (string parameter in Parameters)
{
Searcher.PropertiesToLoad.Add(parameter);
}
Searcher.Sort.PropertyName = "cn";

XmlElement RowsNode =
(XmlElement)UsersDoc.DocumentElement.SelectSingleNode("Rows");

foreach (SearchResult result in Searcher.FindAll())
{
DirectoryEntry Entry =
result.GetDirectoryEntry();

ResultPropertyCollection PropColl =
result.Properties;
string AccountName = null;
string CommonName = null;
string EmailAddress = null;
bool NORMAL_ACCOUNT = false;
bool ACCOUNTDISABLE = false;
Int32 AccountControl = 0;

foreach (string Key in PropColl.PropertyNames)
{
if (Key == "samaccountname")
{
AccountName =
PropColl[Key][0].ToString();
}
if (Key == "cn")
{
CommonName = PropColl[Key][0].ToString();
}
if (Key == "mail")
{
EmailAddress =
PropColl[Key][0].ToString();
}
if (Key == "useraccountcontrol")
{
//http://support.microsoft.com/kb/305144
AccountControl = (Int32)PropColl[Key][0];
NORMAL_ACCOUNT = ((AccountControl &
0x00000200)
0);
ACCOUNTDISABLE = ((AccountControl &
0x00000002)
0);



:

We have a custom application that uses an LDAP query against AD
(2000
native)
to provide a list of all active user accounts but, the results of
the
query
is missing a handfull of active user accounts. From what I've been
able
to
find, all the user accounts in question are not flagged as
NORMAL_ACCOUNT
(hex=0x0200, dec=512) but, when I've checked the properties of each
account
in AD there's nothing different from the accounts that appear from
the
query.

Can ldp.exe or adsiedit.msc help find what may be different about
the
user
accounts in question? If so, is there a good "for dummies" on how
to
use
these tools?
Click to expand...
Click to expand...
Click to expand...
 
Alrighty...this was put on hold for Christmas and now I'm back with good
news. I've found the exact problem, know what needs to be fixed, and it has
nothing to do with missing attributes but rather security permissions in AD
(Richard, you were on the right track earlier when you thought it was not
possible for a user object to have no value assigned to userAccountControl).

The group Authenticated Users needs the permission Read to be set to
'Allow'. All the users objects we've been missing from our query results do
not have this permission set. When this permission is set correct they
appear in the results.

So, my next question is...Can I set this permission for bulk users or is it
a one at a time deal?

Also, would enabling anonymous LDAP access (setting the Directory Service
object attribute dsHeuristics to 0000002) be a good idea or better solution
altogether?

Thanks,
Chad

Richard Mueller said:
In ADSI Edit you navigate to objects in AD just as you do in ADUC. Once you
find the object you want right-click it and select "Properties". All of the
attributes, their syntax, and their values are displayed in alphabetical
order. Double click an attribute name to view the value or values.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

Dixson said:
I hope this doesn't make your head spin...when I stated "missing" I meant
missing. The LDAP query is running against AD...asking for the parameters
of
"samaccountname", "cn", "mail", "memberof", and "useraccountcontrol". The
results for some of the user object do not return any value (not even
null)
for memberof and useraccountcontrol.

Your suggestion that the "memberof" attribute would have no value if the
user is not a member of another group (besides primary) is logical but not
the case because the missing results (user objects) have direct membership
several other groups.

I'm sure you're just as bewildered as we are. I'm going to dabble with
ADSIedit to see what differences I can find about the user accounts in
question. Do you know where I would go in ADSIedit to find the attributes
and the values they are set to?

Richard Mueller said:
I assume by "missing" you mean that no value is assigned (the value is
"not
set"). I don't think it is possible for a user object to have no value
assigned to userAccountControl, but it is certainly possible that the
memberOf attribute, which is multi-valued, could have no values in the
collection (the user is a direct member of no groups other than the
"primary" group). By default, the "primary" group for users is "Domain
Users". If this is the only group the user is a direct member of, the
memberOf attribute will be Empty. Perhaps this causes your problem.

In ADUC you can view direct group memberships on the "Member Of" tab of
the
user properties dialog. If there is just one entry, the memberOf
attribute
is Empty. You can also see this with a tool like ADSI Edit (part of the
Windows 2000 Support Tools). In fact, the number of DN's in the memberOf
attribute is always one less than the number of groups that show up on
the
"Member Of" tab of ADUC.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

Thanks for your time Richard!

It's similar to your explaination but not related to contact
objects...it's
specific user objects (enabled user accounts) that appear to be missing
those
two attributes.

The developer is here today and he changed the filter to match what you
suggested just to see what would happen but no joy. Everything we've
tried
points to missing those two attributes (MEMBEROF and
userACCOUNTCONTROL).
How can I view the attributes of the user objects in question?

Chad

:

The filter "(objectCategory=user)" will include contact objects as
well
as
user objects. Contact objects do not have sAMAccountName or
userAccountControl attributes. Does this explain what you experience?

As noted before, the filter should be
"(&(objectCategory=person)(objectClass=user))". This will exclude
contact
objects. Contact objects do have cn, mail, and memberOf attributes.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

Thanks for the input fellas. As we continued to dig into this what
we've
found is all the user accounts that are found by the query have a
count
of
6
_hashtable entries...the accounts we're having issues with only have
4.
The
AD atributes 'MEMBEROF' and 'userACCOUNTCONTROL' are not found or
included
in the _hashtable results so when masked with the bit for
NORMAL_ACCOUNT
the
results become false.

I beleive the query is written in ASP.net...I'm not the developer
but
just
the guy trying to get everyone to show on the list.

I believe this is the query:

string[] Parameters = { "samaccountname", "cn", "mail", "memberof",
"useraccountcontrol" };
try
{
DirectoryEntry entry = new DirectoryEntry("LDAP://" +
AdDomain, AdAccount, AdPassword);
DirectorySearcher Searcher = new
DirectorySearcher(entry);
Searcher.Filter = "(objectCategory=" + "user" + ")";
foreach (string parameter in Parameters)
{
Searcher.PropertiesToLoad.Add(parameter);
}
Searcher.Sort.PropertyName = "cn";

XmlElement RowsNode =
(XmlElement)UsersDoc.DocumentElement.SelectSingleNode("Rows");

foreach (SearchResult result in Searcher.FindAll())
{
DirectoryEntry Entry =
result.GetDirectoryEntry();

ResultPropertyCollection PropColl =
result.Properties;
string AccountName = null;
string CommonName = null;
string EmailAddress = null;
bool NORMAL_ACCOUNT = false;
bool ACCOUNTDISABLE = false;
Int32 AccountControl = 0;

foreach (string Key in PropColl.PropertyNames)
{
if (Key == "samaccountname")
{
AccountName =
PropColl[Key][0].ToString();
}
if (Key == "cn")
{
CommonName = PropColl[Key][0].ToString();
}
if (Key == "mail")
{
EmailAddress =
PropColl[Key][0].ToString();
}
if (Key == "useraccountcontrol")
{
//http://support.microsoft.com/kb/305144
AccountControl = (Int32)PropColl[Key][0];
NORMAL_ACCOUNT = ((AccountControl &
0x00000200)
0);
ACCOUNTDISABLE = ((AccountControl &
0x00000002)
0);



:

We have a custom application that uses an LDAP query against AD
(2000
native)
to provide a list of all active user accounts but, the results of
the
query
is missing a handfull of active user accounts. From what I've been
able
to
find, all the user accounts in question are not flagged as
NORMAL_ACCOUNT
(hex=0x0200, dec=512) but, when I've checked the properties of each
account
in AD there's nothing different from the accounts that appear from
the
query.

Can ldp.exe or adsiedit.msc help find what may be different about
the
user
accounts in question? If so, is there a good "for dummies" on how
to
use
these tools?
Click to expand...
Click to expand...
Click to expand...
 
Back
Top