samba - Oct 2015 - ADUC - "UNIX Attributes" tab - "Unwilling To Perform"

On 24 October 2015 at 18:57, Rowland Penny <rowlandpenny241155 at
gmail.com> wrote:
> On 24/10/15 18:18, Jonathan Hunter wrote:
>> - 'getent group newgroupname2' *does* now work, whereas it
definitely
>> did not last night. I don't know if there is normally a time delay
>> between creating a new group and it becoming visible to UNIX? The
>> [...]
>> resolution on my DC (and bind9 for DNS).. so perhaps any time delay
>> could be explained by something inside sssd (I must try clearing the
>> cache if this happens again) - I'm willing to believe that is the
case
>> there. However, this would not have any affect on ADUC.
>
> Does the group line in /etc/nsswitch look like this: 'group compat
winbind'
> or 'group compat sss' (compat could be files) , if it is the later,
then
> your getent problem isn't a Samba problem.
Agreed, it is 'group files sss' so I agree with you that the getent
problem is likely to not be Samba's fault. Replication worked fine as
the group was shown on all the other DCs very quickly. At least now I
have reminded myself I am using sssd, and can try clearing its cache
next time I have issues like that :)
>> - ADUC now gives me this same 'Unwilling To Perform' error
whenever I
>> open the UNIX attributes of *any* group, now. Last night I'm fairly
> [...]
>
> The ADUC error is fairly common and it usually does work, it just says it
> doesn't
aha!

OK so there /is/ something wrong (I wish I was able to find out
exactly what) - but as you say it could well still be working in spite
of the error. Now I have established that sssd is in the picture in
terms of /etc/nsswitch.conf, I can ensure the cache is flushed if any
changes I make aren't showing up, before jumping to the conclusion
that the error message actually means it hasn't worked.

I might see if I can tcpdump capture the traffic to this client VM,
and load the resulting output into Wireshark (decrypting it using the
private key of the DC, hopefully) to see what's going on.

Thanks :)

J

-- 
"If we knew what it was we were doing, it would not be called
research, would it?"
      - Albert Einstein

On 24 October 2015 at 19:16, Jonathan Hunter <jmhunter1 at gmail.com>
wrote:
> I might see if I can tcpdump capture the traffic to this client VM,
> and load the resulting output into Wireshark (decrypting it using the
> private key of the DC, hopefully) to see what's going on.
Apparently this could be harder than I first thought.. the outer
session is TLS which I can decrypt using the key from
/usr/local/samba/private/tls/key.pem but inside that it seems to be
further encrypted via GSS-API and krb5.. I don't know if I can open
that up in wireshark :(

To check if your issue comes from Samba or SSSD you could replace SSSD by
Winbind in your PAM configuration. Once your system will retrieve users
from Winbind, if your not-working-group is shown correctly, the issue is
from SSSD. If the group is not shown, the issue should rather come from
Samba.

If your issue comes from Samba perhaps it would help if you show us the
whole ldbsearch on that specific group.

Cheers,

mathias

2015-10-24 20:56 GMT+02:00 Jonathan Hunter <jmhunter1 at gmail.com>:
> On 24 October 2015 at 19:16, Jonathan Hunter <jmhunter1 at gmail.com>
wrote:
> > I might see if I can tcpdump capture the traffic to this client VM,
> > and load the resulting output into Wireshark (decrypting it using the
> > private key of the DC, hopefully) to see what's going on.
>
> Apparently this could be harder than I first thought.. the outer
> session is TLS which I can decrypt using the key from
> /usr/local/samba/private/tls/key.pem but inside that it seems to be
> further encrypted via GSS-API and krb5.. I don't know if I can open
> that up in wireshark :(
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>