none
[MS-LSAT] 3.1.4.9 LsarLookupSids3 (and sisters) about virtual accounts RRS feed

  • Question

  • Hello,

    While doing GPO analysis, I found a SID such as S-1-5-82-1036420768-1044797643-1061213386-2937092688-4282445334 which resolves as IIS APPPOOL\Classic .NET AppPool

    Indeed, there is a bunch a well known accounts used for IIS or others application operations. I'm quoting for example this previous thread about App Container (https://social.msdn.microsoft.com/Forums/en-US/0a90fc48-04a8-4d1e-ba52-6dd31499accf/new-well-known-sid?forum=os_windowsprotocols) or Sql Server configuration to allow the IIS application pool account (https://blogs.msdn.microsoft.com/ericparvin/2015/04/14/how-to-add-the-applicationpoolidentity-to-a-sql-server-login/)

    My question is where the data is stored ?

    Indeed, in MS-LSAT, the specification describes "When a SID is found in the database (...)" and "If a match cannot be found for a SID, but the domain portion of the SID can be matched with a domain SID, the ReferencedDomains parameter MUST be searched for an identical entry with the Name field containing the value from the Domain NetBIOS Name column and the Sid field containing the value from the Domain SID column. If there is no such entry, a new entry with the Name field containing the value of the Domain NetBIOS Name and the Sid field containing the value of the Domain SID MUST be created and added to the ReferencedDomains list"

    => MS-LSAT indicates nothing special about these accounts

    That means that the data related to the virtual account are stored in the "database". My knownledge of the AD indicates to me that the database refers to the LDAP database or a local SAMR database. And some special accounts are hardcoded and called "well known sid".

    I though these virtual accounts where hardcoded like the system account is and called "virtual" for that reason.

    But during my GPO analysis, I found out that App Pool accounts with custom names exists.

    In conclusion, it seems that there is a gap in the specification between MS-LSAT which resolved these SID and the other document.

    My questions are:

    - are there a point in the documentation talking about these virtual accounts ? (MS-ADTS nor MS-SAMR nor MS-LSAT don't seems to talk about it)

    - where is the documentation of the API allowing the creation / edition / removal of these virtual accounts ? Indeed, IIS is definitely using it to create these accounts.

    - a specific note about Domain Controller: once IIS is hosted on a DC, the virtual accounts are resolved by the domain version of MS-LSAT

    I tried to be as clear as possible.

    regards,

    Vincent LE TOUX


    • Edited by vletoux2 Sunday, January 6, 2019 11:14 AM image was dropped
    Sunday, January 6, 2019 11:13 AM

Answers

All replies

  • Found this user documentations:

    https://winterdom.com/2014/05/16/iis-apppool-identity-sids

    https://www.1e.com/news-insights/blogs/2017/11/24/accounts-everywhere-part-1/

    Sunday, January 6, 2019 11:40 AM
  • Hello Vincent,

    Thank you for posting your question. One of our protocols engineers will respond soon. 

    Thanks,


    Jeff McCashland | Microsoft Protocols Open Specifications Team

    Sunday, January 6, 2019 7:03 PM
    Moderator
  • Hi Vincent, 

    I will research you question, and let you know what I find. 

    Thanks,


    Jeff McCashland | Microsoft Protocols Open Specifications Team

    Monday, January 7, 2019 5:28 PM
    Moderator
  • Hi Vincent,

    These virtual accounts are specific to the Windows IIS implementation. As the article you cited points out, they cannot be created, deleted, etc., "they just are." 

    Could you clarify why they should be documented in the Windows Open specifications document library? Do you see them 'on-the-wire'? Does the lack of documentation impact your ability to implement a protocol? 

    If you would like to provide more details offline, you can email us at our dochelp @microsoft .com alias. 

    Thanks,


    Jeff McCashland | Microsoft Protocols Open Specifications Team

    Wednesday, January 9, 2019 10:23 PM
    Moderator
  • Hi Jeff,

    First I can confirm that these virtual accounts are used in a lot of more places that I was expecting and not only IIS.

    They are present in :

    - SQL Server (NT SERVICE\account)

    - IIS (as discussed)

    - Hyper V (NT Virtual Machine\)

    - Windows Manager (WINDOW MANAGER\)

    - Font driver host (Font Driver Host\)

    And as consequence, these accounts can be present in ... GPO as I pointed out. And these GPO are executed in other domain computers.

    I'm working on the server side version of DC protocols and MS-LSAT and specifically resolving SID is part of it. These accounts doesn't follow the rules about Well Known SID (https://docs.microsoft.com/en-us/windows/desktop/secauthz/well-known-sids) 

    More specifically MS-ADTS 6.1.1.6 Well-Known Domain-Relative Security Principals (https://msdn.microsoft.com/en-us/library/cc223708.aspx) refering to MS-SAMR 3.1.4.2 Default Accounts (https://msdn.microsoft.com/en-us/library/cc245702.aspx).

    So I have a gap in the documentation and I want to evaluate how large is the difference between the documentation and the data on the wire. My opinion is that the lack of documentation of virtual accounts may lead to writing code which will be incompatible with the mentioned software.

    Either virual accounts are not part of MS-LSAT and I'd like to have some pointers to the other documentation and the link between LSA-T and these documentations, or virtual accounts are part of MS-LSAT and the documentation should be updated.

    But for the case of GPO, these virtual accounts are present in the privilege section of computers GPO.

    I've specifically checked [MS-GPOD]: Group Policy Protocols Overview which refers in this case to [MS-GPSB]: Group Policy: Security Protocol Extension and in this case to [MS-GPSB] 2.2.6 Privilege Rights. This section refers for the SID resolution to [MS-DTYP] section 2.4.2.1 which just described the binary representation of a SID.

    So yes, this lack of documentation impact my ability to write a server side implementation of MS-LSAT and potentially the implementation of GPO processing.

    By the way, there is no mention in MS-ADTS on how SID how be resolved (search for LSAT). This is MS-LSAT which refers to MS-ADTS.

    Thursday, January 10, 2019 9:36 AM
  • Hi Vincent,

    Could you explain more about what you're trying to do with the virtual account SIDs? Are you resolving the names for a UI display? What steps are you following, and at what point are they not working as expected? 

    Thanks,


    Jeff McCashland | Microsoft Protocols Open Specifications Team

    Thursday, January 17, 2019 9:47 PM
    Moderator
  • Hello,

    I'm working on server side implementation of DC protocols.

    I've already MS-DRSR protocols working.

    I've a MS-LSAT prototype working but when trying to test against real life data, I encountered Virtual SID when parsing GPO.

    My first issue is to be unable to print user friendly error message (in short, yes, translate the name for a UI display). Then I'm unable to know if I should program additional behavior to process them.

    regards,

    Vincent

    Friday, January 18, 2019 11:41 AM
  • Hi Vincent,

    Thank you for your response. Unfortunately, it's still not clear to us what you're doing, and what errors you're encountering. Could you describe the equivalent Windows-to-Windows scenario so we can understand more fully the role your server is filling?

    The virtual accounts are provisioned by the applications that use them, and should be fully provisioned. Are you saying the SIDs are on the Windows DC, but not fully provisioned? Or, are you saying they are included in the GPO, but don't exist on the system? 

    Again, if you would like to discuss these details offline, you can send us email at our DocHelp (@microsoft.com) address.

    Thanks,


    Jeff McCashland | Microsoft Protocols Open Specifications Team

    Wednesday, January 23, 2019 9:49 PM
    Moderator
  • Hi Vincent,

    It's not clear to us what the problem is yet, as virtual accounts should be fully provisioned by the application requiring them. Will you be able to provide more details as requested above? 

    Thanks,


    Jeff McCashland | Microsoft Protocols Open Specifications Team

    Wednesday, January 30, 2019 8:03 PM
    Moderator
  • I'm working on a security product for Domain Controllers. In short: an intelligent & transparent proxy for Domain Controllers.

    As a consequence, I'm dealing with edge cases such as interpreting SID.

    The classic understanding of the documentation for SID is:

    AD Database <=> MS-LSAT

    But with virtual SID, it is much:

    AD Database + Database of virtual accounts <=> MS-LSAT

    I was thinking that this database is hardcoded (exemple of IIS account) but then I discovered that IIS and other services can create their own accounts.

    Can any application do that ? What can this account do? Is that a proxy for other accounts ? ...

    My proxy's goal being to "filter" such weird requests, I need to have an official description of the logic I need to implement to white list them.

    You indicated to me that the accounts are provisioned by the application. I understand that based on this assertion, my request has no need to be answered.

    But you can admit that in that case there is no need for SID resolution, GPO definition, ... These traces indicates that there is definitely an action performed in LSASS .. which impacts LSAT.

    Vincent

    Thursday, January 31, 2019 2:37 PM
  • Hi Vincent,

    When a GPO is defined in AD, it will be configured to apply to accounts that exist in the database. If a GPO is pushed to a device with the account SIDs you mentioned, for the SIDs to be in the GPO, they must have existed in AD. This means the accounts (and their respective SIDs) have been created (provisioned) by the applications that use them. The creation of the accounts should fill all necessary fields. Any client attempting to perform name translation should be able to resolve the name by virtue of their existence in the database.

    In your case, whichever application creates the virtual accounts would have fully provisioned them in AD database. It would detrimental to interoperability if a device in middle is filtering out certain requests. There’s no need for whitelisting because AD does not have any control over what accounts/SIDs application servers might create.

    Thanks,


    Jeff McCashland | Microsoft Protocols Open Specifications Team

    Monday, February 4, 2019 7:02 PM
    Moderator
  • Hi Jeff,

    I'm sorry but your answer is inaccurate.

    First, the account I mentioned is not available in the AD database

    A larger query does not indicates such accounts anywhere in the AD database

    Even if I looked where other system SID are defined, there is no such account

    That's indeed, because the SID first parts do not match the SID of the domain

    (remember: user SID = domain SID + RID of the user and for virtual SID ; SID = S-1-5-82 + hash of the name.

    I definitely confirm that these SID are used in GPO:

    (in the default GPO you have multiple virtual accounts)

    Again, there is an undocumented behavior in LSAT which is not consistent with the AD database.

    Because virtual accounts SID are based on a hash, there is no possibilities to enumerate the virtual accounts, which is a risk (you can find all other accounts in the AD, or enumerate them using the pattern domain SID + i from 500 to end)

    regards,

    Vincent

    Monday, February 4, 2019 7:47 PM
  • If you prefer the UI of the GPO editor ...

    Monday, February 4, 2019 7:54 PM
  • Hi Vincent,

    I do not see the IIS accounts in my Default Domain Controllers Policy GPO, even if IIS is installed on the DC. Could you let me know what deployment steps you followed to set up the domain and install IIS in such a way that the accounts show up in this GPO? 

    Thanks,


    Jeff McCashland | Microsoft Protocols Open Specifications Team

    Friday, February 8, 2019 7:07 PM
    Moderator
  • Hi Jeff,

    You just have to create an application pool account.

    app pool virtual account

    Saturday, February 9, 2019 8:15 AM
  • Hi Vincent,

    Per our investigation, the SIDs you are enquiring about are neither well-known nor domain accounts. They are virtual accounts local to a computer and defined by an application server for its own purpose.

     

    As we observed on Windows, if a client sends such a SID to a DC and attempts to translate it, you should see an error like

    STATUS_SOME_NOT_MAPPED or STATUS_NONE_MAPPED depending or what other SIDs are in the translation request.

     

    Regarding the IIS App Pool example:

     

    Just like an application or administrator can add any SID in a GPO for its own purpose, I observe that IIS App Pool's "virtual accounts" can be added to your default domain controllers policy GPO, assuming IIS is installed on the DC (note that installing IIS on a DC is not a recommended practice).

     

    I was able to add a virtual account manually to the GPO, but only on the machine with IIS installed:

    This caused the GPO template to include the corresponding SID to that virtual account as you saw:

    While logged onto the machine with IIS installed, I’m able to query the virtual account, because it resides on the local machine:

    However, I’m not able to query the virtual account from any other machine in the domain, because the account is not in an AD directory:

    Windows correctly returns an ‘Identity not mapped’ error, since the SID can only be resolved on the machine with IIS installed. We would not expect to be able to resolve a virtual account remotely.

     

    Please consult the following reference for more information regarding IIS App pool:

    Application Pool Identities

    https://docs.microsoft.com/en-us/iis/manage/configuring-security/application-pool-identities

     

    Whenever a new application pool is created, the IIS management process creates a security identifier (SID) that represents the name of the application pool itself. For example, if you create an application pool with the name "MyNewAppPool," a security identifier with the name "MyNewAppPool" is created in the Windows Security system.

    From this point on, resources can be secured by using this identity. However, the identity is not a real user account; it will not show up as a user in the Windows User Management Console.

     

    Thanks,


    Jeff McCashland | Microsoft Protocols Open Specifications Team



    Thursday, February 14, 2019 9:19 PM
    Moderator
  • Sorry to be that guy but the SID is seen on the wire.

    Here is a short powershell code to force the resolution of SID on another computer:

    $source = @"
    using System;
    using System.Collections.Generic;
    using System.ComponentModel;
    using System.Diagnostics;
    using System.Net;
    using System.Runtime.InteropServices;
    using System.Security.Permissions;
    using System.Security.Principal;
    using System.Text;
    
    namespace PingCastle
    {
        public class NativeMethods
        {
    
          
    
            [DllImport("advapi32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
            static extern bool LookupAccountSid(
                string lpSystemName,
                [MarshalAs(UnmanagedType.LPArray)] byte[] Sid,
                System.Text.StringBuilder lpName,
                ref uint cchName,
                System.Text.StringBuilder ReferencedDomainName,
                ref uint cchReferencedDomainName,
                out SID_NAME_USE peUse);
    
            const int NO_ERROR = 0;
            const int ERROR_INSUFFICIENT_BUFFER = 122;
    
            public enum SID_NAME_USE
            {
                SidTypeUser = 1,
                SidTypeGroup,
                SidTypeDomain,
                SidTypeAlias,
                SidTypeWellKnownGroup,
                SidTypeDeletedAccount,
                SidTypeInvalid,
                SidTypeUnknown,
                SidTypeComputer
            }
    
    		public static string ConvertSIDToName(string sidstring, string server)
    		{
    			string referencedDomain = null;
    			return ConvertSIDToName(sidstring, server, out referencedDomain);
    		}
    
            [EnvironmentPermissionAttribute(SecurityAction.Demand, Unrestricted = true)]
            public static string ConvertSIDToName(string sidstring, string server, out string referencedDomain)
            {
            
                StringBuilder name = new StringBuilder();
                uint cchName = (uint)name.Capacity;
                StringBuilder referencedDomainName = new StringBuilder();
                uint cchReferencedDomainName = (uint)referencedDomainName.Capacity;
                SID_NAME_USE sidUse;
    
    			SecurityIdentifier securityidentifier = null;
    			referencedDomain = null;
    			try
    			{
    				securityidentifier = new SecurityIdentifier(sidstring);
    			}
    			catch (Exception ex)
    			{
    				Trace.WriteLine("Got " + ex.Message + " when trying to convert " + sidstring + " as sid");
    				Trace.WriteLine(ex.StackTrace);
    				return sidstring;
    			}
    
                // try to resolve the account using the server
                byte[] Sid = new byte[securityidentifier.BinaryLength];
                securityidentifier.GetBinaryForm(Sid, 0);
    
                int err = NO_ERROR;
                if (!LookupAccountSid(server, Sid, name, ref cchName, referencedDomainName, ref cchReferencedDomainName, out sidUse))
                {
                    err = System.Runtime.InteropServices.Marshal.GetLastWin32Error();
                    if (err == ERROR_INSUFFICIENT_BUFFER)
                    {
                        name.EnsureCapacity((int)cchName);
                        referencedDomainName.EnsureCapacity((int)cchReferencedDomainName);
                        err = NO_ERROR;
                        if (!LookupAccountSid(server, Sid, name, ref cchName, referencedDomainName, ref cchReferencedDomainName, out sidUse))
                            err = System.Runtime.InteropServices.Marshal.GetLastWin32Error();
                    }
                }
    			if (err == 0)
    			{
    				referencedDomain = referencedDomainName.ToString();
    				if (String.IsNullOrEmpty(referencedDomain))
    					return name.ToString();
    				else
    					return referencedDomainName + "\\" + name;
    			}
                Trace.WriteLine(@"Error " + err + " when translating " + sidstring + " on " + server);
                return sidstring;
            }
    
            [StructLayout(LayoutKind.Sequential)]
            public struct UNICODE_STRING : IDisposable
            {
                public ushort Length;
                public ushort MaximumLength;
                private IntPtr buffer;
    
                public void Initialize(string s)
                {
                    Length = (ushort)(s.Length * 2);
                    MaximumLength = (ushort)(Length + 2);
                    buffer = Marshal.StringToHGlobalUni(s);
                }
    
                public void Dispose()
                {
                    Marshal.FreeHGlobal(buffer);
                    buffer = IntPtr.Zero;
                }
                public override string ToString()
                {
    				if (Length == 0)
    					return String.Empty;
    				return Marshal.PtrToStringUni(buffer, Length / 2);
                }
            }
    
    
    
    
        }
    
    }
    "@
    
    Add-Type -TypeDefinition $source
    

    My test lab is a DC where IIS is installed and many application pools have been created.

    Then I'm using another computer joined to the domain where nothing has been installed.

    The commands are:

    PS C:\Users\Administrator\Desktop> [PingCastle.NativeMethods]::ConvertSIDToName("S-1-5-82-1036420768-1044797643-1061213386-2937092688-4282445334", "192.168.0.25")
    IIS APPPOOL\Classic .NET AppPool
    
    
    PS C:\Users\Administrator\Desktop> [PingCastle.NativeMethods]::ConvertSIDToName("S-1-5-80-3139157870-2983391045-3678747466-658725712-1809340420", "192.168.0.25")
    NT SERVICE\WdiServiceHost
    
    
    PS C:\Users\Administrator\Desktop> [PingCastle.NativeMethods]::ConvertSIDToName("S-1-5-82-3211812350-1832821157-3136900975-151528110-3096578129", "192.168.0.25")
    IIS APPPOOL\SmartPolicy
    
    

    You can see the result on the computer and IIS has not been installed.

    How can custom application pool be resolved then ?

    I remind that SecurityIdentifier use internally LsaLookupSid with the default servername.

    As a consequence, Virtual accounts are checked up locally.

    Virtual accounts are indeed available on the wire using MS-LSAT as I just demonstrated

    Friday, February 15, 2019 6:21 PM
  • Best: with a wireshark screenshot

    Friday, February 15, 2019 6:37 PM
  • My research indicates that IIS AppPool SID can be created by modifying the file applicationHost.config located in c:\windows\system32\inetsrv

    Behind the hood, this is the service AppHostSvc which monitors the change.


    It then calls a function named LsaManageSidNameMapping which is documented.

    https://msdn.microsoft.com/en-us/library/windows/desktop/jj902653(v=vs.85).aspx

    However the documentation is inaccurate because it returns an NTSTATUS (instead of a void) and it requires the SeTcbPrivilege which is not mentioned.

    The function LsaManageSidNameMapping then perform a RPC call to lsass.exe

    Interface:

    [

    uuid(12345778-1234-abcd-ef00-0123456789ab),

    version(0.0),

    ]

    OpNum 95

    According to RPCView the prototype of the underlying function LsarManageSidNameMapping is:


    NTSTATUS LsarManageSidNameMapping (

    [in][unique][string] PWSTR servername,

    [in] short OpType,

    [in]LSA_SID_NAME_MAPPING_OPERATION_INPUT* OpInput,

    [out][ref]LSA_SID_NAME_MAPPING_OPERATION_OUTPUT **OpOutput);


    => This function is indicated as being part of MS-LSAD Opnum 95 (MS-LSAD is documented up to Opnum 74)


    Also I'm not able to make this function work using the documented API, even as system.

    The function returns  0xC000000D (invalid parameter) and the Output set to error 4, which means "DomainNotFound"


    => Have you made any progress on this topic ?

    Wednesday, February 27, 2019 3:35 PM
  • Hi Vincent,

    Thanks for the additional information. That will be helpful. I'm still investigating where the virtual accounts are stored.

    Thanks,


    Jeff McCashland | Microsoft Protocols Open Specifications Team

    Wednesday, February 27, 2019 9:27 PM
    Moderator
  • I found another place:

    in ubpm.dll (Windows 10 version), RtlCreateVirtualAccountSid from ntdll is called to initialize the SID.
    Then again a call to LsaLookupManageSidNameMapping to create it into lsass.

    Wednesday, February 27, 2019 9:30 PM
  • Hi Vincent,

    I just happened to see this thread and thought I would reach out to you that Microsoft is hosting another RDP Plugfest, which you use to attend.  Here are the details: https://www.interopevents.com/redmond_rdp_2019


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Tuesday, March 5, 2019 8:06 PM
    Moderator
  • Hi Vincent,

    On further review, it appears virtual accounts are intended only for local use by the applications that add them. We are not aware of any scenario where our client implementation attempts to translate names of virtual accounts. 

    The fact that Windows responds successfully when a virtual account SID is queried from a remote host is a byproduct of the way our security model works; that is, when an application server (e.g.: IIS, SQL) creates a virtual account, it needs to add a mapping of the SID into LSA cache so that the account can be used for the intended purpose.

    As an example, virtual accounts such as "NT SERVICE\SQLSERVERAGENT" cannot be used on a SQL Server Failover Cluster instance, because they would have different SIDs on each node of the cluster, as explained here:

    Configure Windows Service Accounts and Permissions
    https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/configure-windows-service-accounts-and-permissions?view=sql-server-2017

    under the heading Virtual Accounts:
    https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/configure-windows-service-accounts-and-permissions?view=sql-server-2017#VA_Desc

    I hope that helps.

    Thanks,


    Jeff McCashland | Microsoft Protocols Open Specifications Team

    Friday, March 22, 2019 5:43 PM
    Moderator
  • Hi Jeff,

    On the fact that the SID is different on each machine for "NT SERVICE\SQLSERVERAGENT" i don't know but what I've seen so far for all other virtual accounts, is that the virtual sid is the same on all computers given the same account name. The goal being to set the permission once for clustered IIS server.

    What we can check so far :

    - yes, LSA-T allows to query local virtual accounts remotely

    - yes, virtual accounts are used outside of the local machine (domain controller GPO in this example)

    - yes, there is a supported case because the API LsaManageSidNameMapping dealing with virtual sid is supported

    So I conclude:

    Yes, there is a mechanisms in LSA-T allowing to resolve SID not in a domain, not in the local SAM so the documentation is inaccurate.


    In addition to that, I can note that:

    - the documentation for LsaManageSidNameMapping is inaccurate (return code, privilege requirements, ...)

    - "The LsaManageSidNameMapping function adds or removes SID/name mappings from the mapping set registered with the LSA Lookup Service." => this seems to be not limited for virtual account

    - LsaManageSidNameMapping is exposed on the wire (can be confirmed with RpcView)


    So, according to my initial request, can you document the cache consumed by LsarLookupSids3  and impacted by LsaManageSidNameMapping  ?

    regards,

    Vincent

    Friday, March 22, 2019 8:52 PM
  • Hi Vincent,

    Thank you for your patience. We want to fully address your concerns, so we conferred with our AD experts on the points you made. 

    In summary:
    We believe MS-LSAT documentation has what is needed on the way Windows works regarding the SIDs related to local virtual accounts for the following reasons:

    • MS-LSAT 3.1.1.1.2 “Configurable Translation Database” provides direct documentation around the fact that virtual account SIDs can be queried remotely.
    • The fact that LsaManageSidNameMapping can be used (locally only!) to add arbitrary-name SID mappings to the database view in section 3.1.1.1.2 is implicitly covered by the “general purpose database” verbiage. That section says there MUST be one row for the “NT SERVICE” domain because that entry is always present. Nothing prevents applications from adding other domains (e.g. “IIS APPOOL”, “NT VIRTUAL MACHINE”, etc.). Note that details around how this database view is modified are implementation-specific.
    • Although LsarManageSidNameMapping appears in the RPC interface, it is not meant for remote calls, so is therefore not required for documentation. The same is true for opnums in other RPC interfaces when they are not used remotely in any scenario by Microsoft implementations. These non-remote opnums may be discoverable by RPC, but calling them risks impacting interoperability with Microsoft or third-party implementations. 

    Further comments on the points you raised:

    • You attempted to call the LsaManageSidNameMapping function defined on MSDN, and not documented in MS-LSAD/LSAT

    You will notice that the LsaManageSidNameMapping API does not accept a server name parameter. This is an implicit hint that the API is not supported for remote operations. Even if this API uses the opnum for the RPC-method, it never gets used remotely. We also confirmed in the source code that the client must be local. As a result, third-party clients may attempt to make LsarManageSidNameMapping calls to remote Windows machines, but those calls are expected to fail.

    • You observed that the LsaManageSidNameMapping API dealing with virtual account SID mapping is supported. You also observed that this API may not be limited to virtual accounts.

    As mentioned earlier, the Windows API may be supported but the opnum is not usable remotely. This is why it is not needed for over-the-wire protocol documentation.

    • You wrote some code to leverage LSA-T to query the SID of a local virtual account remotely via LsarLookupSids2().

    This call succeeds, but only in the generic sense that LSA-T can be used to query the status of any arbitrary SID over the wire using LsarLookupSids2().   

    • You showed an example of [Default Domain Controllers Policy] GPO that virtual account SIDs can be used outside the local machine.

    This is not specific to virtual account SIDs. Many group policies can be configured with arbitrary SIDs. A third-party application can include their own SID in a GPO. This does not have a protocol impact.

    • You claimed that LsarManageSidNameMapping is exposed on the wire (apparently with opnum 95).

    While the SID can be seen in a network trace, this is not accurate in the protocols context. The fact that the opnum exists in an RPC interface is not an evidence of over-the-wire exposure, at least in the spirit of our documentation set. Not all opnums intended for local use only are locked down from inadvertent remote calls. It would be impractical to rewrite code and redefine related interfaces for the sole purpose of locking down opnums.

    • You asked: Can you document the cache consumed by LsarLookupSids3/2 and impacted by LsaManageSidNameMapping?

    We believe MS-LSAT already has what you are looking for in section 3.1.1.1.2, allowing to resolve a SID which is not in a domain and not in the local SAM. The documentation is accurate, but perhaps in a form different from what you were expecting.    

    More Information:
    The query behaviors defined by LsarLookupSids* require using a set of database “views”, which are documented in section 3.1.1.1 of MS-LSAT:
    https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-lsat/77855eed-d3c7-4538-b527-20a36d4dcb18

    And sub-section 3.1.1.1.2:

    3.1.1.1.2 Configurable Translation Database and Corresponding View
    which describes:

    The Configurable Translation Database is a general purpose database for translation between security principal names and their corresponding SIDs. The Configurable Translation Database columns are the same as the Predefined Translation Database columns, and the view construction is the same. This database SHOULD be constructed using the abstract data model specified in [MS-SCMR] section 3.1.1. There MUST be one row for the “NT SERVICE” domain, as defined in the following table. There MUST be one row per service definition.

    Please let us know if we have missed anything.

    Thanks,


    Jeff McCashland | Microsoft Protocols Open Specifications Team



    Friday, April 5, 2019 6:39 PM
    Moderator
  • Hi Jeff,

    I think this answer is close to the final one.

    My main argument being that "MS-LSAT 3.1.1.1.2 Configurable Translation Database and Corresponding View" describes only the virtual SID starting with S-1-5-80 while IIS APPPool ones starts with S-1-5-82. And that the name is SHA1 in lowercase while in the other case it is SHA1 in UPPERCASE.

    In addition to that, I played with LsaManageSidNameMapping trying to add a mapping to check this, and even with the TCB privilege I'm getting an INVALID PARAMETER error.

    So can virtual SID take any "domain name" or are there any restriction (you quoted NT SERVICE for example) ? And can an application register any SID or are there limited by design to a specific space (such as  S-1-5-80-* or  S-1-5-82-*)

    If I rephrase, can an application register a virtual SID so MYAPPL\TEST can be locally resolved ?

    regards,

    Vincent

    Monday, April 8, 2019 10:19 AM
  • Hi Vincent,

    Applications can add any SID to the Configurable Translation Database. How those SIDs are formed is up to the application. As you’ve noted, different applications format them differently. LsaManageSidNameMapping and the details of its use are implementation-specific. We believe there is no limitation to the ‘Domain Name’ assigned to a SID in the database, or to what SIDs can be added. An application can register any SID, but the details of how to do so are implementation specific. 

    For assistance with working with the database in the Windows implementation, You could try one of the following forums: 

    Windows Desktop SDK
    https://social.msdn.microsoft.com/Forums/en-US/home?forum=windowssdk

    General Windows Desktop Development Issues
    https://social.msdn.microsoft.com/Forums/en-US/home?forum=windowsgeneraldevelopmentissues

    Application Security for Windows Desktop
    https://social.msdn.microsoft.com/Forums/en-US/home?forum=windowssecurity

    Thanks,


    Jeff McCashland | Microsoft Protocols Open Specifications Team


    Wednesday, April 10, 2019 10:09 PM
    Moderator