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

Thanks Rowland - appreciated.

I have checked the ldbsearch result and both groups look to be pretty
much exactly the same to me, one of them is shown below (I have
sanitised some of the output, replacing parts with 123/a/b/c, but the
rest of the output is byte for byte as seen)

In the time between posting my original message and checking again
just now, however, I have the following additional observations:

- '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
first group appeared immediately; the second one (created seconds
after the first) definitely didn't. Last night I also checked the
other DCs (using ADUC) and they all had both groups visible.

I've just checked my samba config and I am using "server services -dns
+winbind -winbindd" on this DC, together with sssd for user/group
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.


- 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
sure that I only experienced the error when looking at the new group.
This error comes up in ADUC whenever I look at the 'UNIX Attributes'
tab of a group with a NIS Domain and GID defined. If I look at a group
that does not have a NIS domain set, there is no error shown. I have
restarted the Windows client (no difference) but not the Samba server
this time.


So, I am no longer as sure as I was, where to look next :( As I
previously said, I have had this error before (pretty sure on multiple
client VMs) but it has somehow "gone away" by itself in the past.
I'd
like to get to the bottom of it whilst it's happening though, if I
can.

Fully patched Windows 7 VM client running ADUC; Samba 4.2.2 built from
source and installed on CentOS 6.6 x64.

Group 1 looks like this:

# ldbsearch -H /usr/local/samba/private/sam.ldb -b
'dc=b-bbbbbb,dc=bbbbb,dc=bbb,dc=bb'
'(&(objectclass=group)(samaccountname=123-aaa-aaaaa-a*))'
# record 1
dn: CN=123-aaa-aaaaa-AA,OU=123,DC=b-bbbbbb,DC=bbbbb,DC=bbb,DC=bb
objectClass: top
objectClass: group
instanceType: 4
whenCreated: 20151023220054.0Z
uSNCreated: 38590
objectGUID: cf305e6b-d3cd-4108-bb06-09b7d0479d90
objectSid: S-1-5-21-ccccccccc-cccccccccc-cccccccccc-2642
sAMAccountType: 268435456
groupType: -2147483646
objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=b-bbbbbb,DC=bbbbb,DC=bb
 b,DC=bb
sAMAccountName: 123-aaa-aaaaa-AA
cn: 123-aaa-aaaaa-AA
name: 123-aaa-aaaaa-AA
description: description of group-AA
msSFU30NisDomain: B-BBBBBB
gidNumber: 10055
msSFU30Name: 123-aaa-aaaaa-AA
member: CN=My User,OU=Users,OU=123,DC=b-bbbbbb,DC=bbbbb,DC=bbb,DC=bb
whenChanged: 20151023230917.0Z
uSNChanged: 38619
distinguishedName: CN=123-aaa-aaaaa-AA,OU=123,DC=b-bbbbbb,DC=bbbbb,DC=bbb,DC=b
 b

# record 2
(pretty much the same; some attributes were returned in a different
order, and the GUID/SID are different of course)


On 24 October 2015 at 09:53, Rowland Penny <rowlandpenny241155 at
gmail.com> wrote:
> On 23/10/15 23:51, Jonathan Hunter wrote:
>>
>> Hi,
>>
>> I am sure I have come across this before but have previously either
>> ignored it or somehow worked around it. However it has come up again
>> and this time I will try to find out what's going on, hopefully we
can
>> fix whatever the issue is.
>>
>> I have a Samba 4.2.2 domain that generally works fine; I have rfc2307
>> enabled so that I can keep UIDs/GIDs consistent across machines whilst
>> still being able to log into my DC using a domain account.
>>
>> Just now I created two groups using ADUC from a Windows 7 client. For
>> both of these groups I went to the "UNIX Attributes" tab,
selected my
>> single NIS Domain from the drop-down list, and accepted the
>> auto-incremented GID value suggested.
>>
>> However, the first group works fine and the second one does not. When
>> I re-open the Properties screen of the second group in ADUC and click
>> on the "UNIX Attributes" tab, I get a pop-up dialog box
entitled "UNIX
>> Attributes", with the simple message "Unwilling To
Perform". This
>> second group does not appear in a "$ getent group
newgroupname2" query
>> on my DC, whereas the first group has no errors in ADUC, and does
>> appear in a "$ getent group newgroupname1" command.
>>
>> I have tried the following with no success
>> - Restarting the Windows 7 client VM
>> - Restarting samba4 on this DC (not on all DCs)
>> - Deleting newgroup2 and re-creating it as above
>>
>> Still exactly the same behaviour.
>>
>> There is nothing I can see in any of my samba logs; but then again I
>> don't have anything special turned on in terms of debugging at the
>> moment.
>>
>> What can I check next?
>>
>> I think this could be the same issue as
>> https://lists.samba.org/archive/samba/2013-November/176815.html
>> but it seems there wasn't really a resolution to that one...
>>
>> Thanks :)
>>
>> Jonathan
>>
>
> Is there something strange in the groupname?
>
> Have you tried examining the groups object in AD and comparing it with the
> one that does work, this run on the DC will get the object for you:
>
>  ldbsearch -H /usr/local/samba/private/sam.ldb -b
> 'dc=samdom,dc=example,dc=com'
> '(&(objectclass=group)(samaccountname=groupname))'
>
> Rowland
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba


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

On 24/10/15 19:18, Jonathan Hunter wrote:
> dn: CN=123-aaa-aaaaa-AA,OU=123,DC=b-bbbbbb,DC=bbbbb,DC=bbb,DC=bb
Do objects outside the OU work?

On 24 October 2015 at 18:46, buhorojo <buhorojo.lcb at gmail.com>
wrote:
> On 24/10/15 19:18, Jonathan Hunter wrote:
>>
>> dn: CN=123-aaa-aaaaa-AA,OU=123,DC=b-bbbbbb,DC=bbbbb,DC=bbb,DC=bb
>
> Do objects outside the OU work?
No - I tried e.g. BUILTIN\Administrators and that returns the same
error in ADUC.

On 24/10/15 18:18, Jonathan Hunter wrote:
> Thanks Rowland - appreciated.
>
> I have checked the ldbsearch result and both groups look to be pretty
> much exactly the same to me, one of them is shown below (I have
> sanitised some of the output, replacing parts with 123/a/b/c, but the
> rest of the output is byte for byte as seen)
>
> In the time between posting my original message and checking again
> just now, however, I have the following additional observations:
>
> - '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
> first group appeared immediately; the second one (created seconds
> after the first) definitely didn't. Last night I also checked the
> other DCs (using ADUC) and they all had both groups visible.
It might be an idea to check if replication is working, it should be 
fairly quick, seconds not minutes.
>
> I've just checked my samba config and I am using "server services
> -dns +winbind -winbindd" on this DC, together with sssd for user/group
> 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.
>
>
> - 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
> sure that I only experienced the error when looking at the new group.
> This error comes up in ADUC whenever I look at the 'UNIX
Attributes'
> tab of a group with a NIS Domain and GID defined. If I look at a group
> that does not have a NIS domain set, there is no error shown. I have
> restarted the Windows client (no difference) but not the Samba server
> this time.
The ADUC error is fairly common and it usually does work, it just says 
it doesn't
>
>
> So, I am no longer as sure as I was, where to look next :( As I
> previously said, I have had this error before (pretty sure on multiple
> client VMs) but it has somehow "gone away" by itself in the past.
I'd
> like to get to the bottom of it whilst it's happening though, if I
> can.
>
> Fully patched Windows 7 VM client running ADUC; Samba 4.2.2 built from
> source and installed on CentOS 6.6 x64.
>
> Group 1 looks like this:
>
> # ldbsearch -H /usr/local/samba/private/sam.ldb -b
> 'dc=b-bbbbbb,dc=bbbbb,dc=bbb,dc=bb'
> '(&(objectclass=group)(samaccountname=123-aaa-aaaaa-a*))'
> # record 1
> dn: CN=123-aaa-aaaaa-AA,OU=123,DC=b-bbbbbb,DC=bbbbb,DC=bbb,DC=bb
> objectClass: top
> objectClass: group
> instanceType: 4
> whenCreated: 20151023220054.0Z
> uSNCreated: 38590
> objectGUID: cf305e6b-d3cd-4108-bb06-09b7d0479d90
> objectSid: S-1-5-21-ccccccccc-cccccccccc-cccccccccc-2642
> sAMAccountType: 268435456
> groupType: -2147483646
> objectCategory:
CN=Group,CN=Schema,CN=Configuration,DC=b-bbbbbb,DC=bbbbb,DC=bb
>   b,DC=bb
> sAMAccountName: 123-aaa-aaaaa-AA
> cn: 123-aaa-aaaaa-AA
> name: 123-aaa-aaaaa-AA
> description: description of group-AA
> msSFU30NisDomain: B-BBBBBB
> gidNumber: 10055
> msSFU30Name: 123-aaa-aaaaa-AA
> member: CN=My User,OU=Users,OU=123,DC=b-bbbbbb,DC=bbbbb,DC=bbb,DC=bb
> whenChanged: 20151023230917.0Z
> uSNChanged: 38619
> distinguishedName:
CN=123-aaa-aaaaa-AA,OU=123,DC=b-bbbbbb,DC=bbbbb,DC=bbb,DC=b
>   b
>
> # record 2
> (pretty much the same; some attributes were returned in a different
> order, and the GUID/SID are different of course)
>
>
>
There doesn't seem to be anything wrong with ldif.

Rowland

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