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.]
    System.Web.Security.PropertyManager.GetSearchResultPropertyValue(SearchResult
    res, String propertyName) +2040711
    System.Web.Security.ActiveDirectoryMembershipProvider.GetMembershipUserFromSearchResult(SearchResult
    res) +555
    System.Web.Security.ActiveDirectoryMembershipProvider.FindUser(DirectoryEntry
    containerEntry, String filter, SearchScope searchScope, Boolean
    retrieveSAMAccountName, DirectoryEntry& userEntry, Boolean&
    resetBadPasswordAnswerAttributes, String& sAMAccountName) +572
    System.Web.Security.ActiveDirectoryMembershipProvider.FindUser(DirectoryEntry
    containerEntry, String filter, DirectoryEntry& userEntry, Boolean&
    resetBadPasswordAnswerAttributes) +31
    System.Web.Security.ActiveDirectoryMembershipProvider.GetUser(String
    username, Boolean userIsOnline) +317
    xxx.Common.Security.SecurityUtility.AuthenticationController(HttpResponse
    response, String domain, String username, String password, Boolean
    rememberMe, String[] roleNames, String[] automaticUserRoles, String[]
    automaticFilmTrackRoles, String[] requiredRoles, Boolean redirect, String&
    cleanedUsername, String& errorLabel) +480
    xxx.Common.Security.SecurityUtility.AuthenticationController(HttpResponse
    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)
    +110
    System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String
    eventArgument) +10
    System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler
    sourceControl, String eventArgument) +13
    System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) +36
    System.Web.UI.Page.ProcessRequestMain(Boolean
    includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1565
    Thomas, Mar 18, 2009
    #1
    1. Advertising

  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"
    http://www.directoryprogramming.net
    "Thomas" <> wrote in message
    news:...
    > 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.]
    >
    > System.Web.Security.PropertyManager.GetSearchResultPropertyValue(SearchResult
    > res, String propertyName) +2040711
    >
    > System.Web.Security.ActiveDirectoryMembershipProvider.GetMembershipUserFromSearchResult(SearchResult
    > res) +555
    >
    > System.Web.Security.ActiveDirectoryMembershipProvider.FindUser(DirectoryEntry
    > containerEntry, String filter, SearchScope searchScope, Boolean
    > retrieveSAMAccountName, DirectoryEntry& userEntry, Boolean&
    > resetBadPasswordAnswerAttributes, String& sAMAccountName) +572
    >
    > System.Web.Security.ActiveDirectoryMembershipProvider.FindUser(DirectoryEntry
    > containerEntry, String filter, DirectoryEntry& userEntry, Boolean&
    > resetBadPasswordAnswerAttributes) +31
    > System.Web.Security.ActiveDirectoryMembershipProvider.GetUser(String
    > username, Boolean userIsOnline) +317
    >
    > xxx.Common.Security.SecurityUtility.AuthenticationController(HttpResponse
    > response, String domain, String username, String password, Boolean
    > rememberMe, String[] roleNames, String[] automaticUserRoles, String[]
    > automaticFilmTrackRoles, String[] requiredRoles, Boolean redirect, String&
    > cleanedUsername, String& errorLabel) +480
    >
    > xxx.Common.Security.SecurityUtility.AuthenticationController(HttpResponse
    > 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)
    > +110
    >
    > System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String
    > eventArgument) +10
    > System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler
    > sourceControl, String eventArgument) +13
    > System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) +36
    > System.Web.UI.Page.ProcessRequestMain(Boolean
    > includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1565
    >
    >
    >
    Joe Kaplan, Mar 19, 2009
    #2
    1. Advertising

  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


    "Joe Kaplan" <> wrote in message
    news:OF$T%...
    > 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"
    > http://www.directoryprogramming.net
    > "Thomas" <> wrote in message
    > news:...
    >> 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.]
    >>
    >> System.Web.Security.PropertyManager.GetSearchResultPropertyValue(SearchResult
    >> res, String propertyName) +2040711
    >>
    >> System.Web.Security.ActiveDirectoryMembershipProvider.GetMembershipUserFromSearchResult(SearchResult
    >> res) +555
    >>
    >> System.Web.Security.ActiveDirectoryMembershipProvider.FindUser(DirectoryEntry
    >> containerEntry, String filter, SearchScope searchScope, Boolean
    >> retrieveSAMAccountName, DirectoryEntry& userEntry, Boolean&
    >> resetBadPasswordAnswerAttributes, String& sAMAccountName) +572
    >>
    >> System.Web.Security.ActiveDirectoryMembershipProvider.FindUser(DirectoryEntry
    >> containerEntry, String filter, DirectoryEntry& userEntry, Boolean&
    >> resetBadPasswordAnswerAttributes) +31
    >> System.Web.Security.ActiveDirectoryMembershipProvider.GetUser(String
    >> username, Boolean userIsOnline) +317
    >>
    >> xxx.Common.Security.SecurityUtility.AuthenticationController(HttpResponse
    >> response, String domain, String username, String password, Boolean
    >> rememberMe, String[] roleNames, String[] automaticUserRoles, String[]
    >> automaticFilmTrackRoles, String[] requiredRoles, Boolean redirect,
    >> String&
    >> cleanedUsername, String& errorLabel) +480
    >>
    >> xxx.Common.Security.SecurityUtility.AuthenticationController(HttpResponse
    >> 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)
    >> +110
    >>
    >> System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String
    >> eventArgument) +10
    >> System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler
    >> sourceControl, String eventArgument) +13
    >> System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) +36
    >> System.Web.UI.Page.ProcessRequestMain(Boolean
    >> includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
    >> +1565
    >>
    >>
    >>

    >
    Thomas, Mar 19, 2009
    #3
  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
    directory.

    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"
    http://www.directoryprogramming.net
    "Thomas" <> wrote in message
    news:%...
    > 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
    >
    >
    > "Joe Kaplan" <> wrote in message
    > news:OF$T%...
    >> 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"
    >> http://www.directoryprogramming.net
    >> "Thomas" <> wrote in message
    >> news:...
    >>> 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.]
    >>>
    >>> System.Web.Security.PropertyManager.GetSearchResultPropertyValue(SearchResult
    >>> res, String propertyName) +2040711
    >>>
    >>> System.Web.Security.ActiveDirectoryMembershipProvider.GetMembershipUserFromSearchResult(SearchResult
    >>> res) +555
    >>>
    >>> System.Web.Security.ActiveDirectoryMembershipProvider.FindUser(DirectoryEntry
    >>> containerEntry, String filter, SearchScope searchScope, Boolean
    >>> retrieveSAMAccountName, DirectoryEntry& userEntry, Boolean&
    >>> resetBadPasswordAnswerAttributes, String& sAMAccountName) +572
    >>>
    >>> System.Web.Security.ActiveDirectoryMembershipProvider.FindUser(DirectoryEntry
    >>> containerEntry, String filter, DirectoryEntry& userEntry, Boolean&
    >>> resetBadPasswordAnswerAttributes) +31
    >>> System.Web.Security.ActiveDirectoryMembershipProvider.GetUser(String
    >>> username, Boolean userIsOnline) +317
    >>>
    >>> xxx.Common.Security.SecurityUtility.AuthenticationController(HttpResponse
    >>> response, String domain, String username, String password, Boolean
    >>> rememberMe, String[] roleNames, String[] automaticUserRoles, String[]
    >>> automaticFilmTrackRoles, String[] requiredRoles, Boolean redirect,
    >>> String&
    >>> cleanedUsername, String& errorLabel) +480
    >>>
    >>> xxx.Common.Security.SecurityUtility.AuthenticationController(HttpResponse
    >>> 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)
    >>> +110
    >>>
    >>> System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String
    >>> eventArgument) +10
    >>> System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler
    >>> sourceControl, String eventArgument) +13
    >>> System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData)
    >>> +36
    >>> System.Web.UI.Page.ProcessRequestMain(Boolean
    >>> includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
    >>> +1565
    >>>
    >>>
    >>>

    >>

    >
    Joe Kaplan, Mar 19, 2009
    #4
  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!)


    "Joe Kaplan" <> wrote in message
    news:%...
    > 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 directory.
    >
    > 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"
    > http://www.directoryprogramming.net
    > "Thomas" <> wrote in message
    > news:%...
    >> 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

    <snip>
    Thomas, Mar 20, 2009
    #5
  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-MS MVP Directory Services Programming
    Co-author of "The .NET Developer's Guide to Directory Services Programming"
    http://www.directoryprogramming.net
    "Thomas" <> wrote in message
    news:...
    > 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!)
    >
    >
    > "Joe Kaplan" <> wrote in message
    > news:%...
    >> 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 directory.
    >>
    >> 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"
    >> http://www.directoryprogramming.net
    >> "Thomas" <> wrote in message
    >> news:%...
    >>> 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

    > <snip>
    Joe Kaplan, Mar 20, 2009
    #6
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andy Norman
    Replies:
    1
    Views:
    607
    Oleg Tkachenko
    Nov 23, 2003
  2. William Parker
    Replies:
    1
    Views:
    3,061
    Martin
    Jun 27, 2004
  3. Replies:
    3
    Views:
    524
  4. Trent Mick
    Replies:
    0
    Views:
    459
    Trent Mick
    Apr 3, 2008
  5. Jacob Davis
    Replies:
    0
    Views:
    484
    Jacob Davis
    Apr 15, 2008
Loading...

Share This Page