none
AD Connector - User Account via LDAP Query - Bitmask query ignored?

    Question

  • Hello all,

    I am working with SCSM 2012 RTM.  I am attempting to use an LDAP query with the AD connector to only import non-disabled user accounts from Active Directory.  However, I am having issues.

    Here is my primary query for pulling non-disabled AD user accounts: 

    (&(objectcategory=person)(objectclass=user)(!useraccountcontrol:1.2.840.113556.1.4.803:=2))

    If I run a query in ADUC for User accounts regardless of disabled status, it finds some 13,000 results.  When I run the above query in ADUC, it correctly pulls all non-disabled User accounts, giving me just over 8,000 results.  These are the accounts I would like to pull into SCSM 2012.

    However, when I configure an AD Connector in SCSM and enter the above query into the LDAP field (confirming that the checkbox is checked and that the connector is configured to just pull the results of the LDAP queries) and let the Connector sync, I still end up with the full 13,000 accounts being pulled into SCSM. 

    I have confirmed that my other AD Connectors (One for computers and printers, one for AD groups, both limited via LDAP queries of their own) are working correctly and are not pulling in the disabled user accounts.

    My question is this - do LDAP queries made using the AD Connector not support the bitwise query used above to exclude disabled accounts?  Or is there another piece of query tied to the AD connector's field itself which may be interfering with mine?  Since my query works correctly in AD, I'm not certain why it isn't working in SCSM.  Any advice or guidance would be most appreciated.

    Thanks in advance!

    Wednesday, June 27, 2012 5:59 PM

Answers

All replies

  • Upon further investigation, it appears that the AD Connector is wrapping the query I provide it inside the following query:

    (|(&(objectCategory=person)(MY QUERY HERE))(&(objectCategory=group)(MY QUERY HERE, ALSO)))

    This results in the following query being sent to AD:

    (|(&(objectCategory=person)(&(objectcategory=person)(objectclass=user)(!useraccountcontrol:1.2.840.113556.1.4.803:=2)))(&(objectCategory=group)(&(objectcategory=person)(objectclass=user)(!useraccountcontrol:1.2.840.113556.1.4.803:=2))))

    However, when I run that query in ADUC, it still returns the correct list of non-disabled accounts (just over 8,000 results).  It would seem to appear that the (!useraccountcontrol...) portion of the query is not being taken into account when ran by the AD Connector, as it is still pulling all 13,000 accounts from AD into SCSM.  How can I make this work via the AD Connector?

    Wednesday, June 27, 2012 7:05 PM
  • Maybe you can try to use the following queries in the LDAP query field for users:

    (!useraccountcontrol:1.2.840.113556.1.4.803:=2)

    or 

    (useraccountcontrol:1.2.840.113556.1.4.803:=2)

    You don't need this "(&(objectcategory=person)(objectclass=user)" in the query field for users.

    Hope this helps.


    Andreas Baumgarten | H&D International Group

    Wednesday, June 27, 2012 7:46 PM
    Moderator
  • Unfortunately, that was what I tried first; I had added the rest of my query to see if perhaps I had left something important out.  I tried it again, though, in case I had somehow missed something the first time, but it still grabbed all 13,000 accounts. 

    Knowing now that the "objectcategory=person" is built into the query, at least I can leave that out.  I put the "objectclass=user" in to avoid grabbing contacts, but it looks like SCSM doesn't sync contacts anyway, so I suppose that's extraneous as well.  

    Thanks for the advice.  I can't find any official documentation (or any documentation regardless, for that matter) on LDAP queries in the SCSM AD Connector.  I wonder if this behavior of the AD connector disregarding the "useraccountcontrol" attribute is a bug or if it was known by the product team that it wouldn't work due to a technical limitation somewhere.  Or maybe there is still something special with the AD Connector we haven't stumbled upon yet. :)

    Wednesday, June 27, 2012 8:47 PM
  • Hmmm.

    Could you please try this:

    (!useraccountcontrol:1.2.840.113556.1.4.804:=2)

    If this doesn't work I am running out of ideas ;-)


    Andreas Baumgarten | H&D International Group

    Wednesday, June 27, 2012 9:59 PM
    Moderator
  • I have mine working correctly with the following syntax:

    Thursday, June 28, 2012 11:29 AM
  • Thanks for the suggestion.

    I tested Dieter's query in AD, adding the query elements SCSM automatically adds to the query in order to confirm first that it pulled just the non-disabled users and groups, and it worked fine there.  So gave it a try and used the exact format Dieter gave in the "Users or User Groups" query field.  However, it is still grabbing every user account regardless of disabled status.

    I did wait to delete my previous connector until after this one had synced, but since the removal of a connector removes all data synced via that connector which wasn't updated by a different connector, that should have simply removed the disabled accounts from the CMDB.  However after waiting an hour and restarting the console, they still exist, plus the entry in the event log from the new connector's sync lists that the query had 13,000+ results.

    I'm going to remove the new connector to confirm everything is removed from the CMDB and then re-implement it to confirm whether or not it works for me.  If it continues to not work, though, that then begs the question of what is different between my environment and Dieter's....

    More info to come.

    Thursday, June 28, 2012 5:56 PM
  • After removing all my AD Connectors and confirming all of the CIs were removed from the CMDB, I created one again with the LDAP query above.  It still grabbed everything.  Hrm.  If it weren't for the fact that it works for you, Dieter, I'd say it simply doesn't work.  But now I need to figure out what is different in my environment that would cause it to not work for me.
    Thursday, June 28, 2012 7:39 PM