Regarding retrieving user group membership using wbinfo.

[Richard Sharpe]

On Thu, Jun 12, 2014 at 9:10 AM, Simo <simo at samba.org> wrote:
> On Thu, 2014-06-12 at 16:59 +0200, Volker Lendecke wrote:
>> On Thu, Jun 12, 2014 at 10:55:17AM -0400, Simo wrote:
>> > On Thu, 2014-06-12 at 07:48 -0700, Richard Sharpe wrote:
>> > > No. It is not SID compression. If I am reading the IDL correctly, we
>> > > think  PAC contains a SamInfo3, bit it does not. It contains most of a
>> > > SamInfo4 but defines it own structure.
>> >
>> > There are 3/4 ways to lists SIDs in a PAC structure, one is the classic
>> > way with only sids related to the domain, then a extra sid field with
>> > sull SIDs not related to the domain, then a sid compression feature (to
>> > reduce space, but still list extra sids) and I forgot if the Claim stuff
>> > added a 4th way to lists SIDs or if it reuses one of the above.
>> >
>> > It certainly isn't Sam Info3 and hasn't been for quite a while.
>>
>> So a simple way to get this done is to expand
>> PAC_LOGON_INFO.info3.sids with SIDs that are prefixed by
>> PAC_LOGON_INFO.res_group_dom_sid extended with RIDs from
>> PAC_LOGON_INFO.res_groups, right? Sounds like a pretty
>> simple patch, the problem is -- where should we put it
>> exactly? :-)
>
> That's a good question.
> The least disruptive thing I can think of on the spot would be to change
> the PAC to use the latest documented structure MS references in the docs
> (Info4 ?) and then translate to Info3 by using accessors functions in
> any code that touches the PAC (which should be few).

Right. This is the structure that Microsoft defines

typedef struct _KERB_VALIDATION_INFO {
 FILETIME LogonTime;
 FILETIME LogoffTime;
 FILETIME KickOffTime;
 FILETIME PasswordLastSet;
 FILETIME PasswordCanChange;
 FILETIME PasswordMustChange;
 RPC_UNICODE_STRING EffectiveName;
 RPC_UNICODE_STRING FullName;
 RPC_UNICODE_STRING LogonScript;
 RPC_UNICODE_STRING ProfilePath;
 RPC_UNICODE_STRING HomeDirectory;
 RPC_UNICODE_STRING HomeDirectoryDrive;
 USHORT LogonCount;
 USHORT BadPasswordCount;
 ULONG UserId;
 ULONG PrimaryGroupId;
 ULONG GroupCount;
 [size_is(GroupCount)] PGROUP_MEMBERSHIP GroupIds;
 ULONG UserFlags;
 USER_SESSION_KEY UserSessionKey;
 RPC_UNICODE_STRING LogonServer;
 RPC_UNICODE_STRING LogonDomainName;
 PISID LogonDomainId;
 ULONG Reserved1[2];
 ULONG UserAccountControl;
 ULONG SubAuthStatus;
 FILETIME LastSuccessfulILogon;
 FILETIME LastFailedILogon;
 ULONG FailedILogonCount;
 ULONG Reserved3;

# We get it correct, mostly, to here (we have a UINT32 unknown[7] over
the last five fields, I believe.

 ULONG SidCount;
 [size_is(SidCount)] PKERB_SID_AND_ATTRIBUTES ExtraSids;
 PISID ResourceGroupDomainSid;
 ULONG ResourceGroupCount;
 [size_is(ResourceGroupCount)] PGROUP_MEMBERSHIP ResourceGroupIds;
} KERB_VALIDATION_INFO;

After what we think is a SamInfo3 we assume that resource SIDs follow,
so if there are extra SIDs, we miss them completely.

Hemanth, the way to test this is to set up a forest with multiple
domains, join DOM A, and create a user who has groups in DOM A and DOM
B, and then see if the same problem occurs.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)