WinNT ADSI provider - cross domain user lookup

Question

''I am using the WinNT ADSI provider in a bit of authentication code, which looks up the user from Active Directory and checks its group membership.

We have run in to an issue getting this working for cross domain access. We followed the steps outlined here (https://support.microsoft.com/kb/241737?wa=wsignin1.0) to set up a Cross-Reference to an External Domain in Active Directory. This should be all that is required to allow WinNT to find the users.

When the code is run we only ever find one object under the domain (in the loop below) - "Schema". This is not correct - there are MANY child objects.

This problem seems to be intermittent - the same system did not have this issue a month ago. I realise this will be hard to investigate but someone who has a better understanding of ADSI may know better.

The below code illustrates the problem:

Dim objUser
Dim sUserName
Set ns = GetObject("WinNT://DOMAINNAME")
msgbox "Found " & ns.AdsPath & " (" & ns.Class &")" ' Shown
'ns.Filter = Array("User") ' Commented to show ALL objects
For Each UserObj in ns
    Dim UserName
    UserName = UserObj.Name & " " & UserObj.Class ' Returns "Schema Schema" 
    msgbox UserName
Next

Answer 1

This solution works but I'd like to point out why. After hours of trying to determine what the importance of the dns suffix on NetBIOS resolution for the WinNT provider, I found that the client makes a call to the local domain controller first to do an LSA_LookupNames call for the NetBIOS name and it gets back a domain controller in the remote domain/forest to go to which is responsible for that NetBIOS name. Subsequent to that lookup, it attempts to connect to the domain controller that was returned - but the name of the server is the simple host or NetBIOS name! So, it has to look that up and it uses DNS for that, trying suffixes in the order prescribed in the network config of the client. So, the domain is being translated properly by the local AD domain as part of the lookup but the client can't figure out how to get to that DC because LSA_LookupNames doesn't return an FQDN, just a hostname.

Hopefully this will save others the time I burned searching - sometimes it pays to just break down and open wireshark.

Answer 2

The solution was to ensure that the local computer, that the query was being run from, had a DNS suffix for the remote domain