can't see trusted domain users from member servers

[BretL]

Hi,
A one-way forest trust is created between 2 Domains, whereby Domain B trusted Domain A. Users a/c in Domain A has been populated in the Domain Local Group (DLG) of Domain B.

However member servers from Domain B is not able to see the user names of Domain A in the DLG of Domain B. Instead the member servers can only see the foreign principal names (aka SID) in the DLG of Domain B.

Can the member servers from Domain B able to see the user friendly names of Domain A in the DLG of Domain B? If yes, may I know how to make it happen?

Appreciate your guidance. Thanks in advance.

 

[Neemobeer]

No Domain A needs to trust Domain B in order to authenticate users from Domain B. I believe also that domain local groups cannot contain domain local groups from other domains. Only users, universal or global groups from other domains.

 

[BretL]

Thanks for your reply, Neemobeer.
I'm able to add the users from Domain A to Domain B's DLG as I'm able to see Domain A user names from Domain B.
However when I tried to grant Domain A users (from Domain B's DLG) via the member server of Domain B, I'm not able to see the user friendly name (from the member server). If this is the normal behaviour, may i know how application grant user access in a trusted domain for authentication purpose?

Thanks.

 

[Neemobeer]

Windows uses the SIDs behind the scenes, but this is not normal behavior. Sounds like your AD queries are not completing. Look at the technet it describes your issue pretty well. Troubleshooting SID translation failures from the obvious to the not so obvious

 

[BretL]

Thanks for your reply, Neemobeer.
The article seems related to LDAP. Heard LDAP query will not work under a trusted domain model. I was told to use Kerberos authentication. But I'm not sure if kerberos authentication requires to select the specific user names. May i know how kerberos work if there is no need to select specific user names but yet able to authenticate users?
Thanks.

 

[Neemobeer]

That article doesn't have to do with LDAP it has to do with the SID to name resolution process

 

[BretL]

Hi [U]Neemobeer[/U],
Am I right that the article is about issue with SID translation in the Domain Controller (and not member servers)? I'm able to see the user names from the Domain Controller but not from the member servers.
Thanks.

 

[Neemobeer]

LSAR is used on every server to translate SIDs to names not just on domain controllers.

 

[BretL]

Hi Neemobeer
The member servers connectivity with its domain controllers is not an issue. May I know do I need to enable "Network access: Allow anonymous SID/Name translation" in the member server so that the user names can be seen from the member server?
Thanks.

 

[Neemobeer]

Name resolution and authentication are two different things one can work without the other.

 

[BretL]

Hi,
Without able to see the user name, there is no way to grant access (be it authentication or authorisation) to the application. Hence I'm stuck. Anyway to overcome this? Is there any problem with the set up or is this the behaviour of Microsoft product?
Thanks.

 

[Neemobeer]

Windows doesnt use the names to authenticate they're only for human readability; however, they should normally be resolvable. Without seeing your systems it would be difficult to tell what the issue is. Most common would be misconfiguration in the firewall.

 

[BretL]

Hi,
Administrator has no means to grant access to the application when configuring the access matrix. This limitation has hinder the progress of granting user access. I've checked with various applications how they grant access, and they unanimously cited that they will need minimally able to select/pick the user so as to grant access. May I know is there other way to grant access without seeing the user account?
Thanks.

 

[Neemobeer]

Windows itself uses the SIDs your applications may not rely on the SIDS, so most likely you need to resolve the name resolution issue. DO you have a firewall configured on the servers and domain controllers? You may want to try disabling them for the time being to see if that resolves the issue.

 

[Neemobeer]

LSAT depends on RPC to send/recieve messages using the SMB protocol so if any of that is blocked by a firewall then you won't have name resolution. [MS-LSAT]: Local Security Authority (Translation Methods) Remote Protocol

 

[BretL]

Hi,
SMB (TCP445) & RPC (TCP135) are part of the ports needed to join domain. All the ports needed to join domain are opened between the domain controller and the member servers. And there is no error in the member server's event log that may hint there is any name resolution issue.
Is there a proper way/method to simulate the viewing of user from the member server other than using LDP.exe to view the user name? We tried in vain using LDP.exe and I suspect it's using LDAP protocol (which may be the cause to block the user name translation).
Thanks.

 

[Neemobeer]

LDAP isn't used to resolve the names. I'd suggest reading more on the LSAT spec and do a wireshark capture while trying to resolve a name.