LDAP Object works on a workstation but not a server

I am trying to access Active Directory via ADSystemInfo and LDAP object in a classic ASP page using VBScript.  It checks the current user accessing the intranet site and pulls information accordingly.  Different pages use different information, and it's not the issue anyways.  I have the following code on my workstation (running IIS5.1 on Windows XP Pro SP2) and on our server (running IIS6.0 and Windows Server 2003 R2).  It works perfect on my workstation with people hitting it from other workstations.  It doesn't work for anyone accessing it on the server.  The code and error is below:

Set ADSysInfo = CreateObject("ADSystemInfo")
Set CurrentUser = GetObject("LDAP://" & AdSysInfo.UserName)
varstrLogon = CurrentUser.userPrincipalName

Microsoft VBScript runtime  error '800a01b6'
Object doesn't support this property or method: 'userPrincipalName'

As far as I can tell, IIS is set up identically on both servers, except for the differences with 6.0 and 5.1.  I am using windows authentication and not allowing anonymous login because it's an intranet site.  We have other pages running and they all work.

These lines don't work also(they break with the same error:
Response.Write("sAMAccountName = " & CurrentUser.sAMAccountName & "<br />")
Response.Write("LDAPDisplayName = " & CurrentUser.LDAPDisplayName & "<br />")
Response.Write("DisplayName = " & CurrentUser.DisplayName & "<br />")
Response.Write("AssocNTAccount = " & CurrentUser.AssocNTAccount & "<br />")

These lines don't break, but they don't return any value:
Response.Write("AssociatedName = " & CurrentUser.AssociatedName & "<br />")
Response.Write("AssociatedDomain = " & CurrentUser.AssociatedDomain & "<br />")

Any ideas on what to look for and why it would not work on the server, but works fine on the workstation?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Does it still work if you put your pc on the DMZ?
CCSOFlagAuthor Commented:
It's all on the same network.  There's no firewall.
CCSOFlagAuthor Commented:
Well, I should clarify there is no firewall within the network.  Outside the network there is.  All these operations are happening within the firewall.
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

Could you check the versions of adsldp.dll on your PC and the server? I think this is the dll for ADSystemInfo.
CCSOFlagAuthor Commented:
PC = v5.1.2600.2180(xpsp_sp2_rtm.040803-2158)
Server = v5.2.3790.1830(srv03_sp1_rtm.050324-1447)
Try this.

You will need to DIM strCurrentUser, objUser

Set ADSysInfo = CreateObject("ADSystemInfo")
strCurrentUser = AdSysInfo.UserName
objUser = GetObject("LDAP://" & strCurrentUser)
varstrLogon = objUser.userPrincipalName

Open in new window

CCSOFlagAuthor Commented:
That doesn't help.  The problem isn't the code.  The problem is for some reason the object isn't recognized on W2003 Server IIS6.0 but it is on Win XP Pro IIS5.1.
Have you allowed Scripts to run in IIS6?  

Do the right Security Principals have proper rights to read and execute and run scripts through IIS?

CCSOFlagAuthor Commented:
yes scripts are allowed rto run.

I'm unfamiliar with Security Principals.  What are those?
Security Principals are the user account objects in this case.

If scripts are allowed to run, do the users or does the account running the script from IIS have the right permissions to do so in IIS and on the NTFS permissions on the folder hosted in IIS.
CCSOFlagAuthor Commented:
yes, the accounts are all set up the same way under permissions.
CCSOFlagAuthor Commented:
the only thing I wasn't sure of was IIS 5.0 isolation mode.  I turned it on though and it still didn't work.  I was actually trying to find some sort of comparison like that, thanks. :)  

This is crazy, I'm really at a loss.  
Are there some sort of automatic permissions granted in XP vs Server 2003 that allow the workstation to access AD but not Server 2003?  Both have Active Directory Admin stuff installed.  Forget what it's called.  In other words I can access Active Directory users and all via GUI from both the Server and my workstation.
CCSOFlagAuthor Commented:
OK, so I have put some code in and it works.  I'm wondering why though because the new code has nothing to do with the code I had before.  Also no where have I read that it requires any sort of login to access AD with ADSystemInfo object.

New Code:
     Set oRootDSE = GetObject("LDAP://RootDSE")      sDomainADsPath = "LDAP://" & oRootDSE.Get("defaultNamingContext")      Set oRootDSE = Nothing      Set oCon = Server.CreateObject("ADODB.Connection")      sUser = "<login>"      sPassword = "<password>"      oCon.Provider = "ADsDSOObject"      oCon.Open "ADProvider", sUser, sPassword      Set oCmd = Server.CreateObject("ADODB.Command")      Set oCmd.ActiveConnection = oCon      sProperties = "name,ADsPath,description,member"      sGroup = "*"      oCmd.CommandText = "<" & sDomainADsPath & ">;(&(objectCategory=group)(name=" & sGroup & "));" & sProperties & ";subtree"      Set oRecordSet = oCmd.Execute
Old Code:
Set ADSysInfo = CreateObject("ADSystemInfo")
Set CurrentUser = GetObject("LDAP://" & AdSysInfo.UserName)
varstrLogon = CurrentUser.userPrincipalName
My old code doesn't even use a recordset.  So any ideas on why this recordset connection is making this code work?   Is there a login I can use with my code rather than having to use this recordset mumbo jumbo?  It just seems like a bit of excessive code for such a little bit of code I'm trying to use.  

The other thing is I was goofing off in IIS trying to fix this problem, and went into the permissions wizard on my workstation and I'm not even sure what I did, but it changed the permissions and now it's not working on my workstation either unless I have this code.  Any ideas on what permission this would fall under?
I'm not as strong with IIS as you appear to be, but I'll keep helping by using what I know about server in general - so forgive any weird questions I may ask. :o)

In ADUC, on the properties of the server object is the box checked for Trust for Delegation - I think it probably should be.

Also, if you're using Anonymous web access then you must configure the directory to allow Anonymous queries.  I think the reason it worked on your workstation might have been due to Digest Authentication - which would pass your own credentials to the Directory when you hit the site.

See:  http://support.microsoft.com/kb/320528
Looks like a permissions issue.
CCSOFlagAuthor Commented:
Netman66, hey I appreciate any help you give.  It's also about getting other ideas and getting pointed in other directions.

I came in to work this morning and discovered something that just throws a wrench into everything.  It didn't work on the server again.  Even WITH the code.  I'm thinking that it may be some sort of connection that gets established and stays connected for a certain amount of time which allows any LDAP queries to go through.  

This code is what I first was goofing off with a long time ago to learn about AD.  Whenever I run this code it works.  It seems once I run this code, it doesn't matter what queries I run they all work.  How long this "connection" lasts I'm not sure.  Here is the code (this is where I got that added code from before:

Dim oRootDSE, oCon, oCmd, oRecordSet
Dim sDomainADsPath, sUser, sPassword, sGroup, sProperties
Dim aDescription, aMember, iCount

Set oRootDSE = GetObject("LDAP://RootDSE")
sDomainADsPath = "LDAP://" & oRootDSE.Get("defaultNamingContext")
Set oRootDSE = Nothing

Set oCon = Server.CreateObject("ADODB.Connection")
sUser = "summitlan\arobert"
sPassword = "9!!nimdA"

oCon.Provider = "ADsDSOObject"

oCon.Open "ADProvider", sUser, sPassword
Set oCmd = Server.CreateObject("ADODB.Command")
Set oCmd.ActiveConnection = oCon
sProperties = "name,ADsPath,description,member"
sGroup = "*"

oCmd.CommandText = "<" & sDomainADsPath & ">;(&(objectCategory=group)(name=" & sGroup & "));" & sProperties & ";subtree"
oCmd.Properties("Page Size") = 100

Set oRecordSet = oCmd.Execute

Response.Write("<strong> Global Groups for the domain: " & Replace(Mid(sDomainADsPath,11), ",DC=", ".") & "</strong>")

Response.Write("<table border='1'>")
Response.Write("<font size=-2>")
While Not oRecordSet.EOF
    Response.Write("<tr><td>" & oRecordSet.Fields("name") & "</td>")
    Response.Write("<td>" & oRecordSet.Fields("ADsPath") & "</td>")
    aDescription = oRecordSet.Fields("description")
    Response.Write("<td> ")
    If Not IsNull(aDescription) Then Response.Write aDescription(0)
    aMember = oRecordSet.Fields("member")
    Response.Write("<td><select size = '5'> ")
    If Not IsNull(aMember) Then
        For icount = 0 to UBound(aMember)
            Response.Write("<option>" & aMember(iCount))
    End If


Set oRecordSet = Nothing
Set oCon = Nothing

I'm guessing this opens some sort of connection to the AD from this server, and then anything can use it afterwards?  Does this make sense at all?  I'm just throwing an idea out.  I really have no clue what's going on.  Any thoughts?  Ideas?

As far as the Trust for Delegation check box.  I do not have permissions to change it.  I will have to ask my boss about that.   Thanks for that info.  I'll see if we can try that and see what it does.  I am not allowing anonymous access, so that's not an issue.

I'll read through that article you linked and see if I can find anything useful.
CCSOFlagAuthor Commented:
"Looks like a permissions issue."

Figured as much, how do you fix it efficiently?
Your on the right path there - I'll dig up some code and show ye I have to find a script I have that does something simlilar.

Bottom line is that now your explictily using a username/password in the LDAP query.  Also note, your calling a recordset in the first example as well, its just being done with different context.  Lemme find my old LDAP script I used that let users edit their AD profile online and I'll post that up here.

CCSOFlagAuthor Commented:
My big question about this code is why, after opening a recordset and closing it, does my end code work using a ADSystemInfo object work correctly when it's not using the recordset?

That'll be great to see your code.  Maybe I Can finally make some sense of this.  
Once you authenticate in a session the authentication stays.  
Yes, exactly.  I think the article a linked to shows how to enable Anonymous connections so this should fix it however, if there are other ways to do it without modifying the Directory then those would be the best options.

Other than that, you'll need to use credentials or use Digest Authentication alongside Anonymous to allow internal users a flow-through.

CCSOFlagAuthor Commented:
So is there an easier way to open a session between this server and the AD?  Rather than having 40 lines of code that I don't use?
Perhaps mwhitworth can explain Digest Authentication to you better than I can - and even if that's the way to go with this.

Hopefully, he comes back to us.
CCSOFlagAuthor Commented:
I have digest authentication on both my workstation and the server already.  So I'm guessing what needs to be done is have a session created before my code, but I'm hoping there is an easier way to do that.
Is this server a domain member?

On the Web Sites folder (if you want Global coverage) Directory security>Edit (under Anonymous access and authentication control) - is the Realm box populated?

CCSOFlagAuthor Commented:
Yes, it's on the correct domain.
I'm sort of out of ideas with the exception of the ADSIEdit thing - which should be an absolute last resort anyway.

If you run part of that code as yourself from the server console does it work?
CCSOFlagAuthor Commented:
don't know what server console is. :(  That a program to run scripts?
From the server - when logged on locally as Administrator.

CCSOFlagAuthor Commented:
not sure how to run VBScript just from the server.  I have logged on the server and run it through the webpage, but gets the same problem.
CCSOFlagAuthor Commented:
FYI, I'm heading out of town in a few minutes.  Won't be back until Wednesday.  So don't think I'm ignoring everyone.   I appreciate all the help so far.  
CCSOFlagAuthor Commented:
Alright, I'm back.  Anyone have any luck on finding a simpler way to have a session open to AD?
CCSOFlagAuthor Commented:
I guess I'll close this.  There was no real solution determined unfortunately.  I'll post if I ever figure this out.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.