Property 'userAccountControl' not found

[Thomas]

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]

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" <replyi...@anywhere.com> wrote in message
news:ODLCBwBq...@TK2MSFTNGP04.phx.gbl...

[Thomas]

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" <joseph....@removethis.accenture.com> wrote in message
news:OF$T%23cCqJ...@TK2MSFTNGP02.phx.gbl...

[Joe Kaplan]

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" <replyi...@anywhere.com> wrote in message

news:%23K4FiwK...@TK2MSFTNGP02.phx.gbl...

[Thomas]

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" <joseph....@removethis.accenture.com> wrote in message

news:%23vfH1bO...@TK2MSFTNGP05.phx.gbl...

<snip>

[Joe Kaplan]

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" <replyi...@anywhere.com> wrote in message

news:2A1D4962-523C-42CF...@microsoft.com...