UserAccountControl Attribute

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" <Dixson.RemoveThis@discussions.microsoft.com> wrote in message
news:EDA82AC8-8E45-49C2-B4CE-908000B90E8B@microsoft.com...
>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 [MVP]" wrote:
>
>> 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" <Dixson.RemoveThis@discussions.microsoft.com> wrote in message
>> news:BE05BA6D-9E47-40E7-BDAC-0F7708E952AE@microsoft.com...
>> > 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 [MVP]" wrote:
>> >
>> >> 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" <Dixson.RemoveThis@discussions.microsoft.com> wrote in message
>> >> news:63F3722E-213C-4EF5-A9F5-27A939E5B2B8@microsoft.com...
>> >> > 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);
>> >> >
>> >> >
>> >> >
>> >> > "Dixson" wrote:
>> >> >
>> >> >> 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?
>> >>
>> >>
>> >>
>>
>>
>>

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 [MVP]" wrote:

> 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" <Dixson.DeleteThis@discussions.microsoft.com> wrote in message
> news:EDA82AC8-8E45-49C2-B4CE-908000B90E8B@microsoft.com...
> >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 [MVP]" wrote:
> >
> >> 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" <Dixson.DeleteThis@discussions.microsoft.com> wrote in message
> >> news:BE05BA6D-9E47-40E7-BDAC-0F7708E952AE@microsoft.com...
> >> > 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 [MVP]" wrote:
> >> >
> >> >> 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" <Dixson.DeleteThis@discussions.microsoft.com> wrote in message
> >> >> news:63F3722E-213C-4EF5-A9F5-27A939E5B2B8@microsoft.com...
> >> >> > 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);
> >> >> >
> >> >> >
> >> >> >
> >> >> > "Dixson" wrote:
> >> >> >
> >> >> >> 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?
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>