http://bugs.winehq.org/show_bug.cgi?id=16418
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #8 from Anastasius Focht focht@gmx.net 2008-12-09 16:19:21 --- Hello,
yes, you will need some 'flesh' in local security authority subsystem for this to work.
The .NET common language runtime (CLR) expects data in out params and status 'success' for LsaLookupSids(). You can't get away by simply returning nothing.
1) PLSA_REFERENCED_DOMAIN_LIST *ReferencedDomains
Out param (LSA_REFERENCED_DOMAIN_LIST) needs to have a least one list entry (necessary because LSA_TRANSLATED_NAME entry domain index will reference this array). For that single LSA_TRUST_INFORMATION entry, local domain data (maybe from ADVAPI_GetDomainName) will be sufficient. 'Name' member must not be NULL, 'Sid' seems not evaluated by caller/CLR (causing no exception).
2) OUT PLSA_TRANSLATED_NAME *Names
The runtime expects an array of 'Count' LSA_TRANSLATED_NAME entries returned (populated by caller, fewer entries will lead to null pointer exception). For 'Use' member, 'SidTypeUser' value seems a safe bet, some other enum values will give IdentityNotMappedException. 'Name' must not be null (you get zero name length exception). 'DomainIndex' should be 0 (referring to first list entry).
This seems to be the minimal requirements to keep .NET CLR happy for this API. It will later bump into next LSA stub/problem, which should be a targeted by different bug.
Note: Take care of possible memory leaks for array list members/embedded lsa strings when the caller cleans up using LsaFreeMemory() (passing opaque ptr).
Regards