Regarding retrieving user group membership using wbinfo.
Hemanth Thummala
hemanth.thummala at gmail.com
Sun Jun 15 12:04:59 MDT 2014
Sorry. I did not notice the other mail threads about resource SID
compression. Please ignore. Will look for the updates in those threads.
Thanks,
Hemanth.
On Sun, Jun 15, 2014 at 11:31 PM, Hemanth Thummala <
hemanth.thummala at gmail.com> wrote:
> I am able to reproduce the issue. Domain local group membership
> information is not shown when the user login using Kerberos. Whereas the
> membership information is shown complete on NTLM authentication. I am yet
> to give a try in trusted domain scenario.
>
> Found Microsoft documentation for this case:
> http://support.microsoft.com/kb/2774190
>
> In our case, customer is reluctant to change any authentication/ group
> policy related changes. So I am planning to work on the changes to fix this
> issue.
>
> Looks like proposed changes in
> https://lists.samba.org/archive/samba-technical/2013-April/091302.html
> can resolve the issue. As Volker mentioned, need to come with a common
> routine which will take care of copying resource group information to info3
> structure in all the(three) places.
>
> But I am not sure if the suggested piece of code can cover the trusted
> domain use case as well. Because I found this from Markus Baier's
> response.
> ...
> This solution works for me, but I think it will fail if the Server with
> the resources the client is authenticating to is not in the same domain as
> the Kerberos KDC that perform the authentication server
> ticket request. In this case the logon domain and the resource domain
> should be different and it is not possible to integrate the rids from
> res_groups.rids in the info3->base.groups.rids array.
> ...
>
> Thanks,
> Hemanth.
>
>
>
> On Sat, Jun 14, 2014 at 8:45 AM, Richard Sharpe <
> realrichardsharpe at gmail.com> wrote:
>
>> On Thu, Jun 12, 2014 at 5:35 PM, Richard Sharpe
>> <realrichardsharpe at gmail.com> wrote:
>> > On Thu, Jun 12, 2014 at 9:43 AM, Richard Sharpe
>> > <realrichardsharpe at gmail.com> wrote:
>> >> 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.
>> >
>> > OK, it looks like I was mistaken WRT master. In master, we have, from
>> > krb5pac.idl:
>> >
>> > typedef struct {
>> > netr_SamInfo3 info3;
>> > dom_sid2 *res_group_dom_sid;
>> > samr_RidWithAttributeArray res_groups;
>> > } PAC_LOGON_INFO;
>> >
>> > and from netlogon.idl:
>> >
>> > typedef [public] struct {
>> > netr_SamBaseInfo base;
>> > uint32 sidcount;
>> > [size_is(sidcount)] netr_SidAttr *sids;
>> > } netr_SamInfo3;
>> >
>> > Which matches what MS-PAC defines down to and including ExtraSIDs as
>> > far as I can see, and then we have the resource SIDs after that.
>> >
>> > So, now to look at the source for Samba 3.6.x.
>>
>> OK, it looks like the problem is in make_session_info_krb5:
>>
>> NTSTATUS make_session_info_krb5(TALLOC_CTX *mem_ctx,
>> char *ntuser,
>> char *ntdomain,
>> char *username,
>> struct passwd *pw,
>> struct PAC_LOGON_INFO *logon_info,
>> bool mapped_to_guest, bool
>> username_was_mapped,
>> DATA_BLOB *session_key,
>> struct auth_session_info **session_info)
>> {
>> NTSTATUS status;
>> struct auth_serversupplied_info *server_info;
>>
>> if (mapped_to_guest) {
>> status = make_server_info_guest(mem_ctx, &server_info);
>> if (!NT_STATUS_IS_OK(status)) {
>> DEBUG(1, ("make_server_info_guest failed: %s!\n",
>> nt_errstr(status)));
>> return status;
>> }
>>
>> } else if (logon_info) {
>> /* pass the unmapped username here since map_username()
>> will be called again in make_server_info_info3() */
>>
>> status = make_server_info_info3(mem_ctx,
>> ntuser, ntdomain,
>> &server_info,
>> &logon_info->info3);
>> if (!NT_STATUS_IS_OK(status)) {
>> DEBUG(1, ("make_server_info_info3 failed: %s!\n",
>> nt_errstr(status)));
>> return status;
>> }
>>
>> If we have the logon_info we don't check if the PAC contains resource
>> SIDs. Of course, we would have to passed the flags from the PAC to
>> figure that out.
>>
>> --
>> Regards,
>> Richard Sharpe
>> (何以解憂？唯有杜康。--曹操)
>>
>
>
More information about the samba-technical
mailing list