 |
 |
ActiveDirectory Query with ASP.NET
[reply]
|
07/21/04 07:54 AM EST
posted by alex email |
|
Several weeks ago I posted a message regarding querying the AD server for various information. What I wrote was a console app that worked well as long as it was running under an account that had AD Auth rights, that is pretty straight forward.
So I wrote a class that I could easily use from other applications and just recently created an ASP.NET app to use it. I configured the IIS virtual directory to run under a service domain account that has access to AD and ran the code. I was surprised by the results. It only returned partial AD info, Firstname, Lastname, username, etc. This was good but many of the items I wanted to use were returned as items but listed " System.NotImplementedException: Handling of this ADSVALUE type is not yet implemented (type = 0xb)" as the value.
After speaking with Jerry, another guy I work with, and poking around on a few forum posts (this one provided a pretty thorough writeup, I will spare you the copy and paste in pretending I came up with it), I generated a Strong Name key, added a few lines to my assembly to grant the necessary permissions, and added it to the server's GAC and low and behold, it returns the full and correct value. Once I did it, it all makes perfect sense. While IIS was using a service account with necessary access privileges, since as Jerry pointed out "ASP.NET's impersonation privileges are Shallow", the application must be running in a fully trusted state as defined by an administrator or someone physically running the application on the machine (which is why the console app worked fine even on the server), otherwise access to some information would be limited. So hope this helps someone at some point, and also thanks for your help Jerry. |
|
[reply]
|
11/24/04 07:38 AM EST
posted by yipyip |
|
I suspect, based on other reading, that the permissions have nothing to do with the AD server side, and everything to do with the unfortunate fact that MS decided to implement System.DirectoryServices on top of the misbegotten ADSI, which wants to do stupid things like scribble all over the local machine's registry.
There is simply no reason to require an ASP.NET application to run fully trusted just to be able to issue some LDAP queries, if you've already authenticated yourself to the LDAP server! |
|
|
|
Its funny that yipyip posted on this otherwise dead thread, as I just recently figured something out that has some relevance as well. What you have stated is correct, and is the basis for the problem. As we know, it all basically comes down to permissions.
I ended up able to run this app on one server just fine, but it keeps crapping out on a server that I would believe has the same permissions, configuration, etc. So I say, what gives?
Turns out the answer was rather simple and stupid. By deault, VS.NET and the framework give applications compiled on the local machine (or server in this case) fully trusted rights. I was building the app on a dev server and it worked well. Moving to production did not render the desired results. This is because, even though the application is registered in the GAC, it isn't executing as fully trusted code since it was not built on the local machine.
Now I understand why MS did this, but not making this well known seems sort of short sighted on my end. Also, the fact that you are building in one place and it is working, and then not working in another place, really seems like it is a stupid idea. Oh well, live and learn the MS way.
Alex |
|
|
|
I'm not sure why any of this surprises you.
MS seems to have left many details hidden or silent. |
|
|
|
| The compiled code has TRUST built into it?? WTF???? Are you positive that this is what was happening Alex? Maybe you have different versions of the framework or different hotfixes installed on each machine that cause your two different builds to behave differently... |
|
|
|
| Nope, I'm sure. I had these strange issues and then someone else in the office did. After doing some digging, the machine that the code is built on blindly has full trust... I call it Lame trust. |
|
|
|
If this were true, how would Microsoft deploy their assemblies? How would anyone be able to sell 3rd party assemblies that perform high trust operations??? Can you run a binary comparison of your dev & production assemblies to verify that their manifests, etc. are identical? I think we're dealing with something much more nuanced, either an IIS setting, a compiler option, a framework/hotfix difference, etc.
And if this does turn out to be true, there must be a csc compiler option ("/dontbestupid") that you need to add in order to get around it...
Can you post some links that pointed you in this direction? |
|
Note: Only registered ShinyDonkey.com users
can post images. Only administrators can delete images.
New messages disabled indefinitely due to SPAM.
|
|
|