Property 'userAccountControl' not found

Discussion in 'ASP .Net Security' started by Thomas, Mar 18, 2009.

  1. Thomas

    Thomas Guest

    I'm running into a serious problem getting Forms Authentication to work with
    the .NET 3.5 ActiveDirectoryMembershipProvider. The catch in all of this is
    that while the servers are running Windows 2003, they are running it in
    Windows 2000 mode. This works fine in many other Windows 2003 environments
    but I cannot determine why it is not working in Windows 2000. I'm not even
    sure what I can do to narrow down the problem. Does the .NET 2.0/3.5
    ActiveDirectoryMembershipProvider even work against Windows 2000?

    [ProviderException: Property 'userAccountControl' not found.]
    res, String propertyName) +2040711
    res) +555
    containerEntry, String filter, SearchScope searchScope, Boolean
    retrieveSAMAccountName, DirectoryEntry& userEntry, Boolean&
    resetBadPasswordAnswerAttributes, String& sAMAccountName) +572
    containerEntry, String filter, DirectoryEntry& userEntry, Boolean&
    resetBadPasswordAnswerAttributes) +31
    username, Boolean userIsOnline) +317
    response, String domain, String username, String password, Boolean
    rememberMe, String[] roleNames, String[] automaticUserRoles, String[]
    automaticFilmTrackRoles, String[] requiredRoles, Boolean redirect, String&
    cleanedUsername, String& errorLabel) +480
    response, String domain, TextBox usernameTextBox, TextBox passwordTextBox,
    CheckBox rememberMeCheckBox, String[] roleNames, String[]
    automaticUserRoles, String[] automaticxxxRoles, String[] requiredRoles,
    Label errorLabel) +135
    xxx.UI.Login.LoginButton_Click(Object sender, EventArgs e) +200
    System.Web.UI.WebControls.Button.OnClick(EventArgs e) +111
    System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument)
    eventArgument) +10
    sourceControl, String eventArgument) +13
    System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) +36
    includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1565
    Thomas, Mar 18, 2009
    1. Advertisements

  2. Thomas

    Joe Kaplan Guest

    This looks more like a permissions problem related to security context to
    me. In AD 2000, the directory allows searches to be performed when you have
    authenticated anonymously. However, the permissions you are given as an
    anonymous user are very restricted and you probably won't be able to see
    some attributes like userAccountControl. There can also be problems with
    reading the schema as a result of the anonymous auth.

    In 2003 AD, anonymous searches are blocked by default so you get a glaring
    "operations error" when the same anonymous auth happens and the search is
    attempted. It makes the problem more obvious.

    The solution is to ensure that the provider is binding to the directory as
    an authenticated domain user with appropriate permissions.

    It is also possible that you are authenticating but the AD has been locked
    down extensively and you need an ID with more privileges to read that
    attribute. That seems less likely but it could happen.

    It is also probably a good idea to consider moving the AD to 2003 FFL if
    there are no more 2000 DCs left. Are they really going to add one at this
    point? Seems a little farfetched...

    Joe Kaplan-MS MVP Directory Services Programming
    Co-author of "The .NET Developer's Guide to Directory Services Programming"
    Joe Kaplan, Mar 19, 2009
    1. Advertisements

  3. Thomas

    Thomas Guest

    The odd thing is that if I run ADSI Edit as the user account used for
    authentication, I can navigate to to the users and see the
    userAccountControl property. Now that said, in my cursory investigation,
    every account in which I looked had that property set to Null. So, perhaps
    the ADSI UI was simply nulling out values I couldn't read?

    What permission and where might this restriction be located? A group policy?
    If so, what would the permission or policy be?


    Thomas, Mar 19, 2009
  4. Thomas

    Joe Kaplan Guest

    All user objects in AD have a userAccountControl attribute. If you can't
    see this using the account you are using can't see the attribute, then you
    don't have the permissions you need. Note that in the membership provider,
    it does not use the permissions of the user who was authenticated to search
    the directory. Instead it uses the permissions of either the IIS app pool
    identity or the ID you have configured for the provider to access the

    You'd need to work with the admins of the AD to determine what they did to
    the ACLs in the directory to restrict this and what you would need to do to
    get the required access. It is not related to group policy.

    Joe Kaplan-MS MVP Directory Services Programming
    Co-author of "The .NET Developer's Guide to Directory Services Programming"
    Joe Kaplan, Mar 19, 2009
  5. Thomas

    Thomas Guest

    So, correct me if I'm wrong, but that would require someone to go into the
    Active Directory Schema MMC, find the attribute in question and change the
    ACL to something else? Is there any other way other than something like a
    powershell or vbscript file? I'd be surprised if the client did this
    intentionally but who knows.

    Thanks for your help!

    (Btw, I do have and read your book. An excellent read!)

    Thomas, Mar 20, 2009
  6. Thomas

    Joe Kaplan Guest

    Thanks for the kind words. :)

    It isn't in the schema, it is just in the directory itself in the ACLs on
    the individual objects. There are many tools that can make this change
    including ADUC, ADSI Edit, ldp and DSACLs and numerous code options as well.
    The right thing to do will depend on what actually needs to be modified. It
    might just be one inherited ACL on the domain root but it may also involve
    many individual changes.

    The key thing to understand is why the default permission that typically
    grants this access and then to decide the right way to apply a permission to
    grant the required rights on the required objects (presumably all the users
    in the directory). This should really be up the admins of the directory. I
    have a suspicion that this AD may have had authenticated users removed from
    the "pre-windows 2000" group which grants full read to lots of objects in
    the directory by default. However, they may have done this for a reason.

    Good luck getting it resolved!
    Joe Kaplan, Mar 20, 2009
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.