Regarding retrieving user group membership using wbinfo.
Hemanth Thummala
hemanth.thummala at gmail.com
Sun Jun 15 12:01:14 MDT 2014
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