Re: Property 'userAccountControl' not found

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" <replyingroup@xxxxxxxxxxxx> wrote in message news:%23K4FiwKqJHA.4516@xxxxxxxxxxxxxxxxxxxxxxx
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.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:OF$T%23cCqJHA.5280@xxxxxxxxxxxxxxxxxxxxxxx
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" <replyingroup@xxxxxxxxxxxx> wrote in message news:ODLCBwBqJHA.1184@xxxxxxxxxxxxxxxxxxxxxxx
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






.