Partager via

Troubleshooting SID translation failures from the obvious to the not so obvious

  • Article

Hi guys, Joji Oshima here with my first post. A common problem we see is SID translation failure. The problem usually occurs when you add users or groups from a trusted domain into your domain local groups.

What you hope to see is the friendly names of the users, and their domain:

image

Unfortunately, you only see the Security Identifiers (SIDs): A security identifier (SID) is a unique value used to identify a security principal or group in a Windows operating system

image

So what goes on in the background that allows SID translation to occur? Some people assume this translation process takes place using LDAP queries, but in Windows there are APIs that will translate the SID to the friendly name. Let’s take a quick look at the sequence of events that take place during SID translation with the commonly used LsarLookupSids3 function.

SID/Name Translation:

  • System will bind to EPM* (port 135) of the target domain controller
  • System will poll EPM for a dynamic port to connect into LSARpc(LDAT/LSAD)
  • System will call LSAT* LsarLookupSids3 for each SID, and receive the name associated with it

The End Point Mapper (EPM) points clients to a dynamic RPC port that a service is listening on. LSAT is a protocol that allows clients to translate security identifiers (SIDs) into human readable names and vice-versa.

Troubleshooting

Something along the process is blocking the request from completing. Before going too deep into the troubleshooting process, check to see if the necessary ports are open between your system and the domain controller. PortQryUI is a great tool to check if ports are open between two systems.

PortQryUI
https://www.microsoft.com/download/en/details.aspx?displaylang=en&id=24009

Assuming the ports are open, there is some other piece blocking the translation. Most commonly, we will see this when there is a one way trust involved and anonymous translations are blocked. You can easily allow anonymous SID/Name translation in Group Policy. This policy is only applied to Domain controllers since they are the servers that will actually process the translation request. You will find this policy in Computer Configuration->Windows Settings->Security Settings->Local Policies->Security Options. It should be noted that by enabling this policy, domain controllers will allow translations to occur even if the user is anonymous or sends bad credentials. It is possible that this can be exploited by a malicious user to gain usernames for administrative accounts. No supported version of Windows needs this setting enabled, so it would only be a troubleshooting step for applications not included with the OS.

image

Network access: Allow anonymous SID/Name translation
https://technet.microsoft.com/en-us/library/cc728431(WS.10).aspx

Once this policy is enabled, be sure to allow time for SYSVOL replication to occur and group policy to refresh. You can check to see if the policy is enabled on your target DC by running GPRESULT /h gpresult.html . There are some instances where translation is still not occurring. At this point, the best way to troubleshoot is with a network capture from both sides. You can take a network trace using Microsoft Network Monitor 3.4.

Microsoft Network Monitor 3.4
https://www.microsoft.com/download/en/details.aspx?displaylang=en&id=4865

image

I’ve pulled some select lines out of a trace from a case that I was troubleshooting that went beyond the policy setting:

2723 1:05:12 PM 6/13/2011 49.1983596 1.1.1.1 2.2.2.2 MSRPC MSRPC:c/o Bind: EPT(EPMP) UUID{E1AF8308-5D1F-11C9-91A4-08002B14A0FA} Call=0x3 Assoc Grp=0xE5B51 Xmit=0x16D0 Recv=0x16D0 {MSRPC:393, TCP:391, ESP:44, IPv4:39}

2724 1:05:12 PM 6/13/2011 49.2383211 2.2.2.2 1.1.1.1 MSRPC MSRPC:c/o Bind Nack: Call=0x3 Reject Reason: REASON_NOT_SPECIFIED {MSRPC:393, TCP:391, ESP:44, IPv4:39}

Notice that the bind attempt to the EPM (end point mapper) is getting a Bind Nack for REASON_NOT_SPECIFIED. In this case the customer had an end point protection software suite that was blocking the connection. One thing to note is simply disabling most security software is not enough to fully stop its inspection behaviors. The filter drivers are still loaded and will continue to manipulate these connections. A full uninstall is the only way to ensure it is nullified. After removing the software package on both sides, I took another trace to see if it gets past this part.

434 9:44:01 AM 6/14/2011 10.8427423 1.1.1.1 2.2.2.2 MSRPC MSRPC:c/o Bind: EPT(EPMP) UUID{E1AF8308-5D1F-11C9-91A4-08002B14A0FA} Call=0x2 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0 {MSRPC:62, TCP:61, ESP:52, IPv4:51}

435 9:44:01 AM 6/14/2011 10.8811941 2.2.2.2 1.1.1.1 MSRPC MSRPC:c/o Bind Ack: Call=0x2 Assoc Grp=0xA179 Xmit=0x16D0 Recv=0x16D0 {MSRPC:62, TCP:61, ESP:52, IPv4:51}

436 9:44:01 AM 6/14/2011 10.8813273 1.1.1.1 2.2.2.2 MSRPC MSRPC:c/o Auth3: Call=0x2 {MSRPC:62, TCP:61, ESP:52, IPv4:51}

437 9:44:01 AM 6/14/2011 10.8813768 1.1.1.1 2.2.2.2 EPM EPM:Request: ept_map: NDR, LSARpc(LSAT/LSAD) {12345778-1234-ABCD-EF00-0123456789AB} v0.0, RPC v5, 0.0.0.0:135 (0x87) [DCE endpoint resolution(135)] {MSRPC:62, TCP:61, ESP:52, IPv4:51}

439 9:44:01 AM 6/14/2011 10.9205440 2.2.2.2 1.1.1.1 MSRPC MSRPC:c/o Fault: Call=0x2 Context=0x0 Status=0x5 Cancels=0x0 {MSRPC:62, TCP:61, ESP:52, IPv4:51}

Notice that the bind attempt to the EPM (end point mapper) is now successful with the Bind Ack. After this, the system makes an EPM request for LSARpc(LSAT/LSAD), but the system gets a MSRPC c/o fault with a status of 0x5. 0x5 typically stands for ERROR_ACCESS_DENIED.

At this point it looks like something is still blocking this request from completing. We already removed the end point protection and tried enabling anonymous SID/Name translation.

Gathering a GPRESULT /H from both sides, there appeared to be several potential blockages. I also had the user export the following registry keys to review:

  • HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer
  • HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation
  • HKLM\SYSTEM\CurrentControlSet\Control\LSA
  • HKLM\SYSTEM\CurrentControlSet\Services\Netlogon

Ultimately, there were several pieces that blocked the translation from occurring, which I have listed below. If you have a similar case, review some of these settings and see if RPC is being blocked in one of these ways. Keep in mind that there are legitimate reasons to have these security settings configured to block anonymous connections. I would suggest evaluating the benefits of allowing anonymous connections vs. blocking them.

This configuration item restricts anonymous access to the RPC interfaces. Keep in mind this can block incoming and outgoing anonymous RPC connections.

This configuration item controls which named pipes can be accessed anonymously

Similar to the Null Session Shares, this configuration item can control which named pipes can be accessed anonymously

This configuration item configures if anonymous clients can connect to translate SIDs into names

This configuration item can block anonymous users from connecting to a computer remotely and can effect SID to name translation

Matched LM Compatibility Levels (set to 2 on both sides)
https://technet.microsoft.com/en-us/library/cc960646.aspx

Since we have an external domain trust, NTLM authentication is used. It is possible that this configuration mismatch will block SID to name translation.

When resolved, the trace should look similar to this:

image

6 5:20:34 PM 6/17/2011 8.9047907 1.1.1.1 2.2.2.2 MSRPC MSRPC:c/o Bind: EPT(EPMP) UUID{E1AF8308-5D1F-11C9-91A4-08002B14A0FA} Call=0x1 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0 {MSRPC:3, TCP:2, IPv4:1}

7 5:20:34 PM 6/17/2011 8.9047907 2.2.2.2 1.1.1.1 MSRPC MSRPC:c/o Bind Ack: Call=0x1 Assoc Grp=0x53B3 Xmit=0x16D0 Recv=0x16D0 {MSRPC:3, TCP:2, IPv4:1}

8 5:20:34 PM 6/17/2011 8.9047907 1.1.1.1 2.2.2.2 EPM EPM:Request: ept_map: NDR, LSARpc(LSAT/LSAD) {12345778-1234-ABCD-EF00-0123456789AB} v0.0, RPC v5, 0.0.0.0:135 (0x87) [DCE endpoint resolution(135)] {MSRPC:3, TCP:2, IPv4:1}

9 5:20:34 PM 6/17/2011 8.9047907 2.2.2.2 1.1.1.1 EPM EPM:Response: ept_map: NDR, LSARpc(LSAT/LSAD) {12345778-1234-ABCD-EF00-0123456789AB} v0.0, RPC v5, 2.2.2.2:49155 (0xC003) [49155] {MSRPC:3, TCP:2, IPv4:1}

13 5:20:34 PM 6/17/2011 8.9047907 1.1.1.1 2.2.2.2 MSRPC MSRPC:c/o Bind: LSARpc(LSAT/LSAD) UUID{12345778-1234-ABCD-EF00-0123456789AB} Call=0x1 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0 {MSRPC:5, TCP:4, IPv4:1}

15 5:20:34 PM 6/17/2011 9.0610407 2.2.2.2 1.1.1.1 MSRPC MSRPC:c/o Bind Ack: Call=0x1 Assoc Grp=0x424B Xmit=0x16D0 Recv=0x16D0 {MSRPC:5, TCP:4, IPv4:1}

16 5:20:34 PM 6/17/2011 9.0610407 1.1.1.1 2.2.2.2 LSAT LSAT:LsarLookupSids3 Request, *Encrypted* {MSRPC:5, TCP:4, IPv4:1}

17 5:20:34 PM 6/17/2011 9.0766657 2.2.2.2 1.1.1.1 LSAT LSAT:LsarLookupSids3 Response, *Encrypted* {MSRPC:5, TCP:4, IPv4:1}

Conclusion

I hope this makes things clearer and you have some places to look if you are not translating. If you are having this issue, remember the sequence of events, look at a network trace of the failure, and find where it is failing.

Have a great week.

- Joji “SID Caesar” Oshima

Comments

  • Anonymous
    August 02, 2011
    Nice blog and great explanation on LsarLookupSids3 function.