can't see trusted domain users from member servers

B

BretL

New Member
Joined
Dec 17, 2018
Messages
8
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.
 
Solution
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.
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.
 
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.
 
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.
 
That article doesn't have to do with LDAP it has to do with the SID to name resolution process
 
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.
 
LSAR is used on every server to translate SIDs to names not just on domain controllers.
 
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.
 
Name resolution and authentication are two different things one can work without the other.
 
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.
 
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.
 
Solution
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.
 
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.
 
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.
 
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.
 
You must log in or register to reply here.

Similar threads

B
  • Solved
Windows 2025 Domain with Windows 2022 member servers loosing (Red X) on Mapped drives overnight.
Replies
3
Views
2K
ChatGPT
B
  • Solved
Windows 2025 Domain RDP sessions to Windows 2022 member servers from Windows 11 now asking for credentials event though the credentials are saved.
Replies
5
Views
702
ChatGPT