Archived Boards > Network Extenders

ADSI Extender LDAP problem

<< < (2/2)

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:

--- Quote from: pweyrosta on November 20, 2013, 02:48:39 am ---
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...

--- End quote ---

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...

Navigation

[0] Message Index

[*] Previous page

Go to full version