UserAccountControl Attribute
in [Active Directory]
|
From: Dixson on 11 Dec 2008 11:16 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(a)discussions.microsoft.com> wrote in message > news:63F3722E-213C-4EF5-A9F5-27A939E5B2B8(a)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? > > >
From: Richard Mueller [MVP] on 11 Dec 2008 14:34 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(a)discussions.microsoft.com> wrote in message news:BE05BA6D-9E47-40E7-BDAC-0F7708E952AE(a)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(a)discussions.microsoft.com> wrote in message >> news:63F3722E-213C-4EF5-A9F5-27A939E5B2B8(a)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? >> >> >>
From: Dixson on 11 Dec 2008 17:52 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(a)discussions.microsoft.com> wrote in message > news:BE05BA6D-9E47-40E7-BDAC-0F7708E952AE(a)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(a)discussions.microsoft.com> wrote in message > >> news:63F3722E-213C-4EF5-A9F5-27A939E5B2B8(a)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? > >> > >> > >> > > >
From: Richard Mueller [MVP] on 11 Dec 2008 21:10 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(a)discussions.microsoft.com> wrote in message news:EDA82AC8-8E45-49C2-B4CE-908000B90E8B(a)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(a)discussions.microsoft.com> wrote in message >> news:BE05BA6D-9E47-40E7-BDAC-0F7708E952AE(a)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(a)discussions.microsoft.com> wrote in message >> >> news:63F3722E-213C-4EF5-A9F5-27A939E5B2B8(a)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? >> >> >> >> >> >> >> >> >>
From: Dixson on 29 Dec 2008 21:01 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(a)discussions.microsoft.com> wrote in message > news:EDA82AC8-8E45-49C2-B4CE-908000B90E8B(a)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(a)discussions.microsoft.com> wrote in message > >> news:BE05BA6D-9E47-40E7-BDAC-0F7708E952AE(a)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(a)discussions.microsoft.com> wrote in message > >> >> news:63F3722E-213C-4EF5-A9F5-27A939E5B2B8(a)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? > >> >> > >> >> > >> >> > >> > >> > >> > > >
First
|
Prev
|
Pages: 1 2 Prev: Error adding NAP Role Next: I_NetLogonControl failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN |