Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Andrzejek on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ADO Permission Failure when querying against remote domain

Status
Not open for further replies.

djhawthorn

Technical User
Mar 4, 2002
641
AU
Does anyone know how to get serverless binding to work for remote domain authentication/ADO queries?

I have tried the example[sup]1[/sup] per the MS Scripting Guy page, however I always get ‘Provider: Permission denied’ whenever I try and execute the query. I have turned on auditing on the remote DC (in my test lab) and it shows a successful authentication request, so it’s passing the credentials correctly. It doesn’t seem to matter what access the remote user has either.

If I change the query in the example to bind to a specific server though, the example works.

i.e. Where they have
[tt]objCommand.CommandText = "SELECT Name FROM 'LDAP://DC=fabrikam,DC=com' WHERE objectCategory='user'"[/tt]

I replace that with
[tt]objCommand.CommandText = "SELECT Name FROM 'LDAP://SERVER.fabrikam.com/DC=fabrikam,DC=com' WHERE objectCategory='user'"[/tt]

(and changing the searchscope to 2 – subtree search) and I successfully get a list of users in the domain.

Basically I want to be able to query a remote domain without having to specify the DC to query against if possible. Any ideas?

Thanks.

[sup]1[/sup]

[ponder][laughtears] The dumber they think you are, the more surprised they'll be when you kill them! [machinegun][rofl2]
 
Sorry, I should mention that both domains are separate forests with no trusts between them. There is simply network connectivity and name resolution.

[ponder][laughtears] The dumber they think you are, the more surprised they'll be when you kill them! [machinegun][rofl2]
 
Your lack of a trust between the domains is the reason for the failure. Scripts execute with the credentials of the caller (entity executing the task). If the user you are logged on as is not an authenticated user in the target domain, Your LDAP query will fail because it has no security context in which to query. The reason your query works when you specify a server name is likely due to you having a username/password combination that is the same in both domains (like admin@domain1.fabrikam.com and admin@domain2.fabrikam.com). NETBIOS (unless specifically disabled in the domains) resolution would get you connectivity to shared folders, etc. allowing your credential updated as an authenticated user which is allowing your query where you specified the server name to work. To get this to work you would either need to create a trust between the domains or have the script execute with different credentials (one that has permissions to query the domain controller, a domain user/created service account will work just fine) and specify the remote domain controller name. There are many ways/examples to have a script execute with different credentials, a quick google would get loads of them.
 
Thanks for the reply...

The two domains have different usernames and passwords - I explicitly made sure of this so I didn't get any authentication using my logged on credentials.

Also, I am specifying alternative credentials per the example / code below (using the remote domain username and password):

[tt]objConnection.Properties("User ID") = "fabrikam\kenmyer"
objConnection.Properties("Password") = "A2sXrco1Fq1#om!"
objConnection.Properties("Encrypt Password") = TRUE[/tt]

Regardless of which way I do it (serverless or server-based), I get a "successful" audit event showing the authentication request on the remote DC using the specified username and domain name (and not the username or domain I am executing under) - so I know its passing the credentials specified.

The only thing I can possibly point to as a possible indicator (though why it doesnt work serverless but does server-based I dont know) is the error message 'Permission denied' - rather than 'access denied' or 'authentication error' - or perhaps I'm reading too much into it :).

[ponder][laughtears] The dumber they think you are, the more surprised they'll be when you kill them! [machinegun][rofl2]
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top