ADSI Extender LDAP problem

[pweyrosta]

Hi,

i've written a very simple script to determine whether a specific Server is responding to LDAP requests.

I'm querying two Domain Controllers running Windows 2003 SP2.

The script works as long as I'm executing it on one of the two Domain Controllers itself.
As soon as I'm executing it from another machine (Windows 7), no matter if it's a Domain member or not, I'm getting "1074 Local error occured" at the DsIsContainer line.


AddExtender("wwads44i.dll")
LDAP_Server1="DC1-ELS1.els1.els-m68.net"
LDAP_Server2="DC2-ELS1.els1.els-m68.net"


#DefineSubroutine SetLDAPCredentials()

   slc_User="CN=xxxxxx,OU=Dienste,OU=LAN Benutzer,OU=People,DC=els1,DC=els-m68,DC=net"
   slc_Password="*********"
   dsSetCredent(slc_User,slc_Password)
   ;dsSetCredentX(slc_User,slc_Password,1 | 2)

   DropWild("slc_*")
   Return
#EndSubroutine

#DefineSubroutine SelectLDAPServer()

sls_Counter=1

While IsDefined(LDAP_Server%sls_Counter%)

   sls_ADSIpath=StrCat("LDAP://",LDAP_Server%sls_Counter%,"/CN=ELS-1 Netzwerk,OU=FW Devices,OU=People,DC=els1,DC=els-m68,DC=net")

   sls_Result=DsIsContainer(sls_ADSIpath)

   If sls_Result Then Message("sls_Result",StrCat("LDAP is OK on Server ",LDAP_Server%sls_Counter%))

   sls_Counter=sls_Counter+1
EndWhile

   DropWild("sls_*")
   Return
#EndSubroutine

SetLDAPCredentials()
SelectLDAPServer()



So everything is explicitly defined. Any idea why this wouldn't work on other machines than the DCs ??
And what does "local error" mean?
Regards
Peter

[td]

Generally, this type of errors are the result of either the not having sufficient permissions to access the targeted object (because you are a Domain Admin does not necessarily mean you have permission) or not being able to  resolve the server/domain name via DNS.  Without knowing more about the topology and configuration of your network, it is difficult to determine if one of these or some other problem is causing the error.

The container interface is one of several ADSI interfaces that produces addition error information.  The extender writes the additional error information into the wwwbatch.ini file.  Since you are on Windows 7 the wwwbatch.ini file can be found in the <system drive>:\Users\<user account name>\AppData\Roaming\WinBatch\Settings directory. Look for the [ADSI extender] section in the file.  The file can have a lot of white space so make sure you keep scrolling until you find the section or reach the bottom of the file.  The [ADSI Extender]  section looks something like this

[ADSI Extender]
ErrorCode=-2146893048
ErrorText=80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, vece
Provider=LDAP Provider

If you find the [ADSI Extender] section post it here and we might be able to figure out what is going on.

[pweyrosta]

Mhhh...

The section Looks exactly as you pasted it.

[ADSI Extender]
ErrorCode=-2146893048
ErrorText=80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, vece
Provider=LDAP Provider

The above is a copy from my wwwbatch.ini file.

What does this mean?

As far as I understood, I'm providing credentials to the extender, thus the extender will use the provided credentials to bind to the LDAP server and it should not play any role whether the local machine and/or user is member of the domain or not.

And why does the exact same script work like a charm when I execute it on the Domain controller itself and does not from a member workstation (Win 7) to which I'm logged in with the same user account as to the domain controller.

And by the way, I have another version of this script making use of LDIFDE.EXE that uses exactly the same credentials for the LDAP bind. And that works from whatever machine I try. even from my personal workstation that has no relationship to the target domain at all.

[td]

I need to offer an apology.  I should have had you clear the [ADSI Extender] section of the wwwbatch.ini file before running your script.  That way we will know that the error is the result of your current problem and not some error lingering from a previous problem.  So first you need to clean our your wwwbatch.ini file, rerun your script and report back the ADSI extender related contents of the file.

If your current problem involves credentials, it is likely either an issue with the authentication method you are using or the format of the credentials themselves, e.g., switching from samaccountname to domain\samaccountname or UPN.  The extender doesn't do a lot of hand holding by defaulting, and requires a modicum of understanding of how the LDAP protocol is implemented on Windows servers and how your servers are configured. 

[pweyrosta]

I cleared the ADSI Extender section and did a fresh run.
Here's the result:

[ADSI Extender]

ErrorCode=-2146893048
ErrorText=80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, vece
Provider=LDAP Provider

But that was a good point on the format of the credentials. If I specify the username as DOMAIN\USERNAME or just USERNAME it seems to work.
But why is this? Why does it work from a Windows 2003 Domain Controller and does not from a Windows 7 Domain member if I specify LDAP style credentials?
What I try to understand is how this extender is implemented. And to me it looks as if the version of the local operating System has some influence on the behaviour.
Since I'm able to detect the local OS Version, I would be able to handle that but since I'm not able to test each and every Version I need to understand what to expect on the different OSes...

[Deana]

It appears the LDAP error message is indicating "525"ââ,¬â€¹ user not found.

http://social.technet.microsoft.com/Forums/windowsserver/en-US/474abb8f-cfc6-4cac-af79-c3e80e80291f/ldap-authentication-error-ldap-error-code-49-80090308-ldaperr-dsid0c090334-comment?forum=winserverDS

http://social.technet.microsoft.com/Forums/windowsserver/en-US/2786da89-3dc7-43d9-8a75-3db54825ff36/solved-ldap-authentication-error-code-49-80090308-comment-acceptsecuritycontext-error-data

Accessing resources across domains: http://technet.microsoft.com/en-us/library/cc787646(v=WS.10).aspx

[td]

But that was a good point on the format of the credentials. If I specify the username as DOMAIN\USERNAME or just USERNAME it seems to work.
But why is this? Why does it work from a Windows 2003 Domain Controller and does not from a Windows 7 Domain member if I specify LDAP style credentials?
What I try to understand is how this extender is implemented. And to me it looks as if the version of the local operating System has some influence on the behaviour.
Since I'm able to detect the local OS Version, I would be able to handle that but since I'm not able to test each and every Version I need to understand what to expect on the different OSes...

It is not the version of Windows but the relationship between the the computer and the domain that is causing you problems.  Obviously, that relationship is different when you are accessing AD from the server hosting the domain as apposed to a client machine. 

The extender does  a fairly straight forward call into the underlying API interface when connecting to the server.  It's real 'magic' comes after the connection is made.  In your case, the problem lies with that first step, however.

I didn't ask and you didn't mention if your DCs are hosting separate domains or part of the same domain.  If they are hosting separate domains you need  to experiment with using the 256 authentication method with 1 and/or 2 authentication methods passed to the dsSetCredentX function.   You may have to try several other different combinations to see if any work for you even if all your DCs are on a single domain.

You also need to make sure that the user account you are using is fully recognize with appropriate privileges across domains, if you are in a multi domain environment.  This can depend on the trust relationships between domains and may vary depending on the access being from the client or server side.

Another thing to consider is that the domain used with the user name you specify will default to the domain of the client computer running the script.  This behavior is build into the ADSI API and explains in part why the use of a domain with the user name can affect connection success.

The ADSI API interfaces have a lot of subtle quirkiness that is not particularly well documented.  Often the best way to resolve problems is to do a little trial and error.  Once you figure out how to get it working it then often begins to make some kind of sense.

[td]

Forgot to mention that authentication method 128 is necessary when Kerberos encryption is enabled on the domain or forest and you are passing data over a network.

Another thing to experiment with...