Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > ASP .Net Security > Property 'userAccountControl' not found

Reply
Thread Tools

Property 'userAccountControl' not found

 
 
Thomas
Guest
Posts: n/a
 
      03-18-2009
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.GetSearchResul tPropertyValue(SearchResult
res, String propertyName) +2040711
System.Web.Security.ActiveDirectoryMembershipProvi der.GetMembershipUserFromSearchResult(SearchResult
res) +555
System.Web.Security.ActiveDirectoryMembershipProvi der.FindUser(DirectoryEntry
containerEntry, String filter, SearchScope searchScope, Boolean
retrieveSAMAccountName, DirectoryEntry& userEntry, Boolean&
resetBadPasswordAnswerAttributes, String& sAMAccountName) +572
System.Web.Security.ActiveDirectoryMembershipProvi der.FindUser(DirectoryEntry
containerEntry, String filter, DirectoryEntry& userEntry, Boolean&
resetBadPasswordAnswerAttributes) +31
System.Web.Security.ActiveDirectoryMembershipProvi der.GetUser(String
username, Boolean userIsOnline) +317
xxx.Common.Security.SecurityUtility.Authentication Controller(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.Authentication Controller(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.RaisePostBackEven t(String eventArgument)
+110
System.Web.UI.WebControls.Button.System.Web.UI.IPo stBackEventHandler.RaisePostBackEvent(String
eventArgument) +10
System.Web.UI.Page.RaisePostBackEvent(IPostBackEve ntHandler
sourceControl, String eventArgument) +13
System.Web.UI.Page.RaisePostBackEvent(NameValueCol lection postData) +36
System.Web.UI.Page.ProcessRequestMain(Boolean
includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1565



 
Reply With Quote
 
 
 
 
Joe Kaplan
Guest
Posts: n/a
 
      03-19-2009
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.GetSearchResul tPropertyValue(SearchResult
> res, String propertyName) +2040711
>
> System.Web.Security.ActiveDirectoryMembershipProvi der.GetMembershipUserFromSearchResult(SearchResult
> res) +555
>
> System.Web.Security.ActiveDirectoryMembershipProvi der.FindUser(DirectoryEntry
> containerEntry, String filter, SearchScope searchScope, Boolean
> retrieveSAMAccountName, DirectoryEntry& userEntry, Boolean&
> resetBadPasswordAnswerAttributes, String& sAMAccountName) +572
>
> System.Web.Security.ActiveDirectoryMembershipProvi der.FindUser(DirectoryEntry
> containerEntry, String filter, DirectoryEntry& userEntry, Boolean&
> resetBadPasswordAnswerAttributes) +31
> System.Web.Security.ActiveDirectoryMembershipProvi der.GetUser(String
> username, Boolean userIsOnline) +317
>
> xxx.Common.Security.SecurityUtility.Authentication Controller(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.Authentication Controller(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.RaisePostBackEven t(String
> eventArgument)
> +110
>
> System.Web.UI.WebControls.Button.System.Web.UI.IPo stBackEventHandler.RaisePostBackEvent(String
> eventArgument) +10
> System.Web.UI.Page.RaisePostBackEvent(IPostBackEve ntHandler
> sourceControl, String eventArgument) +13
> System.Web.UI.Page.RaisePostBackEvent(NameValueCol lection postData) +36
> System.Web.UI.Page.ProcessRequestMain(Boolean
> includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1565
>
>
>


 
Reply With Quote
 
 
 
 
Thomas
Guest
Posts: n/a
 
      03-19-2009
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" <(E-Mail Removed)> wrote in message
news:OF$T%(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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.GetSearchResul tPropertyValue(SearchResult
>> res, String propertyName) +2040711
>>
>> System.Web.Security.ActiveDirectoryMembershipProvi der.GetMembershipUserFromSearchResult(SearchResult
>> res) +555
>>
>> System.Web.Security.ActiveDirectoryMembershipProvi der.FindUser(DirectoryEntry
>> containerEntry, String filter, SearchScope searchScope, Boolean
>> retrieveSAMAccountName, DirectoryEntry& userEntry, Boolean&
>> resetBadPasswordAnswerAttributes, String& sAMAccountName) +572
>>
>> System.Web.Security.ActiveDirectoryMembershipProvi der.FindUser(DirectoryEntry
>> containerEntry, String filter, DirectoryEntry& userEntry, Boolean&
>> resetBadPasswordAnswerAttributes) +31
>> System.Web.Security.ActiveDirectoryMembershipProvi der.GetUser(String
>> username, Boolean userIsOnline) +317
>>
>> xxx.Common.Security.SecurityUtility.Authentication Controller(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.Authentication Controller(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.RaisePostBackEven t(String
>> eventArgument)
>> +110
>>
>> System.Web.UI.WebControls.Button.System.Web.UI.IPo stBackEventHandler.RaisePostBackEvent(String
>> eventArgument) +10
>> System.Web.UI.Page.RaisePostBackEvent(IPostBackEve ntHandler
>> sourceControl, String eventArgument) +13
>> System.Web.UI.Page.RaisePostBackEvent(NameValueCol lection postData) +36
>> System.Web.UI.Page.ProcessRequestMain(Boolean
>> includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
>> +1565
>>
>>
>>

>


 
Reply With Quote
 
Joe Kaplan
Guest
Posts: n/a
 
      03-19-2009
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" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:OF$T%(E-Mail Removed)...
>> 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" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> 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.GetSearchResul tPropertyValue(SearchResult
>>> res, String propertyName) +2040711
>>>
>>> System.Web.Security.ActiveDirectoryMembershipProvi der.GetMembershipUserFromSearchResult(SearchResult
>>> res) +555
>>>
>>> System.Web.Security.ActiveDirectoryMembershipProvi der.FindUser(DirectoryEntry
>>> containerEntry, String filter, SearchScope searchScope, Boolean
>>> retrieveSAMAccountName, DirectoryEntry& userEntry, Boolean&
>>> resetBadPasswordAnswerAttributes, String& sAMAccountName) +572
>>>
>>> System.Web.Security.ActiveDirectoryMembershipProvi der.FindUser(DirectoryEntry
>>> containerEntry, String filter, DirectoryEntry& userEntry, Boolean&
>>> resetBadPasswordAnswerAttributes) +31
>>> System.Web.Security.ActiveDirectoryMembershipProvi der.GetUser(String
>>> username, Boolean userIsOnline) +317
>>>
>>> xxx.Common.Security.SecurityUtility.Authentication Controller(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.Authentication Controller(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.RaisePostBackEven t(String
>>> eventArgument)
>>> +110
>>>
>>> System.Web.UI.WebControls.Button.System.Web.UI.IPo stBackEventHandler.RaisePostBackEvent(String
>>> eventArgument) +10
>>> System.Web.UI.Page.RaisePostBackEvent(IPostBackEve ntHandler
>>> sourceControl, String eventArgument) +13
>>> System.Web.UI.Page.RaisePostBackEvent(NameValueCol lection postData)
>>> +36
>>> System.Web.UI.Page.ProcessRequestMain(Boolean
>>> includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
>>> +1565
>>>
>>>
>>>

>>

>


 
Reply With Quote
 
Thomas
Guest
Posts: n/a
 
      03-20-2009
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" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
>> 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>

 
Reply With Quote
 
Joe Kaplan
Guest
Posts: n/a
 
      03-20-2009
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
>> 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" <(E-Mail Removed)> wrote in message
>> news:%(E-Mail Removed)...
>>> 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>


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Found and Not Found Don Phillipson Wireless Networking 1 10-02-2009 12:24 AM
Re: Module not found in script that was found in command-lineinterpreter. Possible Path issue? Jacob Davis Python 0 04-15-2008 07:28 PM
Re: Module not found in script that was found incommand-line interpreter. Possible Path issue? Trent Mick Python 0 04-03-2008 05:54 PM
One File Found, the other Not Found ?!?!?! mcampo84@gmail.com Java 3 08-07-2006 09:49 PM
Namespace not found in aspx but IS found in code behind William Parker ASP .Net 1 06-27-2004 06:13 AM



Advertisments