Bug 1238190 - ipasam unable to lookup group in directory yet manual search works
Summary: ipasam unable to lookup group in directory yet manual search works
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.1
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-07-01 11:36 UTC by Jason Woods
Modified: 2016-11-04 05:46 UTC (History)
9 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2016-11-04 05:46:08 UTC


Attachments (Terms of Use)
NSACLPlugin diagnostics in errors file for dirsrv produced by nsslapd-errorlog-level (7.62 KB, text/plain)
2015-07-13 14:34 UTC, Jason Woods
no flags Details
Full ACI output from ldapsearch for aci (110.97 KB, text/plain)
2015-07-13 14:34 UTC, Jason Woods
no flags Details
fallback group caching patch (1.67 KB, patch)
2015-08-25 08:15 UTC, Jason Woods
no flags Details | Diff
gid to sid lookup patch (2.94 KB, patch)
2015-08-25 08:16 UTC, Jason Woods
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2404 normal SHIPPED_LIVE ipa bug fix and enhancement update 2016-11-03 13:56:18 UTC

Description Jason Woods 2015-07-01 11:36:57 UTC
Description of problem:
ipasam reporting a group lookup failure in logs.
Results in a noticeable performance impact - because lookup fails, the gid->SID relationship is not cached, and it attempts to look it up multiple times for every file copy/delete operation. These constant LDAP roundtrips slow the process down.

ipa-server-3.0.0 does not exhibit this problem and successfully looks up the SID.

Version-Release number of selected component (if applicable):
ipa-server-4.1.0-18.el7.centos.3.x86_64
CentOS 7.1.1503

How reproducible:
Always

Steps to Reproduce:
1. Setup and configure IPA
2. yum install ipa-server-trust-ad
3. ipa-adtrust-install
4. net conf setparm global ‘log level’ 10
5. Create a projects group and a user within that group
6. Setup new samba share as follows:
	[Test]
	path = /data
	guest ok = no
	read only = no
	valid users = @projects
8. Open Samba in firewall
9. Connect to samba share Test as a user of projects group
10. Copy in lots of files and then delete them
11. Examine /var/log/samba/log.workstation

Actual results:
We see lots and lots of the following messages at intervals:
[2015/06/30 16:23:18.050664,  5, pid=14801, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:1249(smbldap_search_ext)
 smbldap_search_ext: base => [dc=XXX], filter => [(|(&(gidNumber=543800010)(objectClass=ipaNTGroupAttrs))(&(uidNumber=543800010)(objectClass=posixAccount)(objectClass=ipaNTUserAttrs)))], scope => [2]
[2015/06/30 16:23:18.051555,  3, pid=14801, effective(0, 0), real(0, 0)] ipa_sam.c:942(ldapsam_gid_to_sid)
 ERROR: Got 0 entries for gid 543800010, expected at least one

543800010 is the GID for the projects group

Expected results:
Not to get the ERROR. The same query on a RedHat 6.6 IPA server is successful for the group and it returns a SID

Additional info:
Running the same LDAP query as root (Directory Manager access) returns a valid entry:

[root@ipa02 data]# ldapsearch -H 'ldapi://%2fvar%2frun%2fslapd-XXX.socket' '(|(&(gidNumber=543800010)(objectClass=ipaNTGroupAttrs))(&(uidNumber=543800010)(objectClass=posixAccount)))'
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <dc=XXX> (default) with scope subtree
# filter: (|(&(gidNumber=543800010)(objectClass=ipaNTGroupAttrs))(&(uidNumber=543800010)(objectClass=posixAccount)))
# requesting: ALL
#
# projects, groups, accounts, XXX
dn: cn=projects,cn=groups,cn=accounts,dc=XXX
gidNumber: 543800010
ipaUniqueID: XXX
cn: projects
description: Projects access
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup
objectClass: ipausergroup
objectClass: ipaobject
objectClass: posixgroup
objectClass: ipantgroupattrs
ipaNTSecurityIdentifier: XXX
member: cn=projects_rw,cn=groups,cn=accounts,dc=XXX
# search result
search: 3
result: 0 Success
# numResponses: 2
# numEntries: 1

Loading the keytab for Samba and connecting as Samba returns no entries:

[root@ipa02 data]# kinit -t /etc/samba/samba.keytab cifs/ipa02.XXX@XXX
[root@ipa02 data]# ldapsearch -Y GSSAPI -H 'ldapi://%2fvar%2frun%2fslapd-XXX.socket' '(|(&(gidNumber=543800010)(objectClass=ipaNTGroupAttrs))(&(uidNumber=543800010)(objectClass=posixAccount)))'
SASL/GSSAPI authentication started
SASL username: cifs/ipa02.XXX@XXX
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <dc=XXX> (default) with scope subtree
# filter: (|(&(gidNumber=543800010)(objectClass=ipaNTGroupAttrs))(&(uidNumber=543800010)(objectClass=posixAccount)))
# requesting: ALL
#
# search result
search: 4
result: 0 Success
# numResponses: 1

However, connecting as Samba and only querying HALF of the OR query actually returns results. So something is happening that makes the OR fail. Alexander Bokovoy suspects it is a problem with NACLPlugin.

[root@ipa02 data]# ldapsearch -Y GSSAPI -H 'ldapi://%2fvar%2frun%2fslapd-XXX.socket' '(&(gidNumber=543800010)(objectClass=ipaNTGroupAttrs))'
SASL/GSSAPI authentication started
SASL username: cifs/XXX@XXX
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <dc=XXX> (default) with scope subtree
# filter: (&(gidNumber=543800010)(objectClass=ipaNTGroupAttrs))
# requesting: ALL
#
# projects, groups, accounts, XXX
dn: cn=projects,cn=groups,cn=accounts,dc=XXX
gidNumber: 543800010
ipaUniqueID: XXX
cn: projects
description: Projects access
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup
objectClass: ipausergroup
objectClass: ipaobject
objectClass: posixgroup
objectClass: ipantgroupattrs
ipaNTSecurityIdentifier: XXX
member: cn=projects_rw,cn=groups,cn=accounts,dc=XXX
# search result
search: 4
result: 0 Success
# numResponses: 2
# numEntries: 1

Comment 2 Petr Vobornik 2015-07-02 14:14:22 UTC
Changing component according to Alexander's suspicion that there is something wrong in ACL implementation.

Comment 3 Noriko Hosoi 2015-07-02 20:45:47 UTC
Can we have the ACL configured for the entry cn=projects,cn=groups,cn=accounts,dc=XXX?

Also, could you find out who did "BIND" in the access log /var/lib/dirsrv/slapd-SERVERID/access?

Do they match these?
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
               directory manager; success
SASL username: cifs/ipa02.XXX@XXX
               failure
SASL username: cifs/XXX@XXX
               success

Since cifs/XXX@XXX was successful, but cifs/ipa02.XXX@XXX was not, can we have nsSaslMapping entries the configuration?
$ ldapsearch -LLLx -D 'cn=directory manager' -W -b "cn=mapping,cn=sasl,cn=config" "(objectclass=nssaslmapping)"

Do you happen to know the DN of the user cifs/XXX@XXX?

Thanks!

Comment 4 Jason Woods 2015-07-03 09:11:37 UTC
I've setup a test machine to reproduce now.

If I've got this wrong RE ACL - let me know what commands to run to get the right info. I've done ldapsearch for the ACI attribute on projects and it has none. Performed the same for the parent cn=groups,cn=accounts and got the following:

$ ldapsearch -LLL -H ldapi://%2fvar%2frun%2fslapd-TEST-LOCAL.socket '(cn=groups)' aci
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=groups,cn=compat,dc=test,dc=local

dn: cn=groups,cn=accounts,dc=test,dc=local
aci: (targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(
 version 3.0;acl "permission:System: Add Groups";allow (add) groupdn = "ldap:/
 //cn=System: Add Groups,cn=permissions,cn=pbac,dc=test,dc=local";)
aci: (targetattr = "member")(targetfilter = "(&(!(cn=admins))(objectclass=ipau
 sergroup))")(version 3.0;acl "permission:System: Modify Group Membership";all
 ow (write) groupdn = "ldap:///cn=System: Modify Group Membership,cn=permissio
 ns,cn=pbac,dc=test,dc=local";)
aci: (targetattr = "cn || description || gidnumber || ipauniqueid || mepmanage
 dby || objectclass")(targetfilter = "(|(objectclass=ipausergroup)(objectclass
 =posixgroup))")(version 3.0;acl "permission:System: Modify Groups";allow (wri
 te) groupdn = "ldap:///cn=System: Modify Groups,cn=permissions,cn=pbac,dc=tes
 t,dc=local";)
aci: (targetattr = "member || memberhost || memberof || memberuid || memberuse
 r")(targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(v
 ersion 3.0;acl "permission:System: Read Group Membership";allow (compare,read
 ,search) userdn = "ldap:///all";)
aci: (targetattr = "businesscategory || cn || createtimestamp || description |
 | entryusn || gidnumber || ipaexternalmember || ipantsecurityidentifier || ip
 auniqueid || mepmanagedby || modifytimestamp || o || objectclass || ou || own
 er || seealso")(targetfilter = "(|(objectclass=ipausergroup)(objectclass=posi
 xgroup))")(version 3.0;acl "permission:System: Read Groups";allow (compare,re
 ad,search) userdn = "ldap:///anyone";)
aci: (targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(
 version 3.0;acl "permission:System: Remove Groups";allow (delete) groupdn = "
 ldap:///cn=System: Remove Groups,cn=permissions,cn=pbac,dc=test,dc=local";)
aci: (targetattr = "member")(target = "ldap:///cn=ipausers,cn=groups,cn=accoun
 ts,dc=test,dc=local")(version 3.0;acl "permission:System: Add User to default
  group";allow (write) groupdn = "ldap:///cn=System: Add User to default group
 ,cn=permissions,cn=pbac,dc=test,dc=local";)

This is the BIND line from /var/log/dirsrv/slapd-SERVERID/access on a test machine I created to reproduce (I assume you meant /var/log not /var/lib):
[01/Jul/2015:16:24:28 +0100] conn=41 fd=103 slot=103 connection from local to /var/run/slapd-TEST-LOCAL.socket
[01/Jul/2015:16:24:29 +0100] conn=41 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI
[01/Jul/2015:16:24:29 +0100] conn=41 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
[01/Jul/2015:16:24:29 +0100] conn=41 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
[01/Jul/2015:16:24:29 +0100] conn=41 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
[01/Jul/2015:16:24:29 +0100] conn=41 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI
[01/Jul/2015:16:24:29 +0100] conn=41 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=cifs/ipa01.test.local@test.local,cn=services,cn=accounts,dc=test,dc=local"
[...]
[01/Jul/2015:16:24:29 +0100] conn=41 op=9 SRCH base="dc=test,dc=local" scope=2 filter="(|(&(gidNumber=802400004)(objectClass=ipaNTGroupAttrs))(&(uidNumber=802400004)(objectClass=posixAccount)(objectClass=ipaNTUserAttrs)))" attrs="ipaNTSecurityIdentifier objectClass"
[01/Jul/2015:16:24:29 +0100] conn=41 op=9 RESULT err=0 tag=101 nentries=0 etime=0

nentries=0

Following is BIND line from same log when run as directory manager which was successful:

[03/Jul/2015:09:21:38 +0100] conn=6 fd=82 slot=82 connection from local to /var/run/slapd-TEST-LOCAL.socket
[03/Jul/2015:09:21:38 +0100] conn=6 op=0 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedSASLMechanisms"
[03/Jul/2015:09:21:38 +0100] conn=6 op=0 RESULT err=0 tag=101 nentries=1 etime=0
[03/Jul/2015:09:21:38 +0100] conn=6 AUTOBIND dn="cn=Directory Manager"
[03/Jul/2015:09:21:38 +0100] conn=6 op=1 BIND dn="cn=Directory Manager" method=sasl version=3 mech=EXTERNAL
[03/Jul/2015:09:21:38 +0100] conn=6 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=Directory Manager"
[03/Jul/2015:09:21:38 +0100] conn=6 op=2 SRCH base="dc=test,dc=local" scope=2 filter="(|(&(gidNumber=802400004)(objectClass=ipaNTGroupAttrs))(&(uidNumber=802400004)(objectClass=posixAccount)(objectClass=ipaNTUserAttrs)))" attrs=ALL
[03/Jul/2015:09:21:38 +0100] conn=6 op=2 RESULT err=0 tag=101 nentries=1 etime=0

nentries=1

ldapsearch SASL lines for directory manager; success
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0

ldapsearch SASL lines for cifs/ipa01.test.local@TEST.LOCAL; failure
SASL/GSSAPI authentication started
SASL username: cifs/ipa01.test.local@TEST.LOCAL
SASL SSF: 56
SASL data security layer installed.

Apologies for the censoring in original post - cifs/ipa02.XXX@XXX is the same as cifs/XXX@XXX - I just censored the ipa02 part accidentally in the second one but not in first. Now I have test machine I can prevent any censoring from getting in way. Below is the nsSaslMapping entries from your command:

[root@ipa01 ~]# ldapsearch -LLLx -D 'cn=directory manager' -W -b "cn=mapping,cn=sasl,cn=config" "(objectclass=nssaslmapping)"
Enter LDAP Password:
dn: cn=Full Principal,cn=mapping,cn=sasl,cn=config
nsSaslMapPriority: 10
cn: Full Principal
objectClass: top
objectClass: nsSaslMapping
nsSaslMapRegexString: \(.*\)@\(.*\)
nsSaslMapBaseDNTemplate: dc=test,dc=local
nsSaslMapFilterTemplate: (krbPrincipalName=\1@\2)

dn: cn=Name Only,cn=mapping,cn=sasl,cn=config
nsSaslMapPriority: 10
cn: Name Only
objectClass: top
objectClass: nsSaslMapping
nsSaslMapRegexString: ^[^:@]+$
nsSaslMapBaseDNTemplate: dc=test,dc=local
nsSaslMapFilterTemplate: (krbPrincipalName=&@TEST.LOCAL)

As per logs above the DN of the cifs user in use by Samba is:
cifs/ipa01.test.local@test.local,cn=services,cn=accounts,dc=test,dc=local

Comment 5 thierry bordaz 2015-07-06 09:01:29 UTC
This is likely that the DS ACL are preventing 'krbprincipalname=cifs/ipa01.test.local@test.local,cn=services,cn=accounts,dc=test,dc=local' to access the entry matching "(|(&(gidNumber=802400004)(objectClass=ipaNTGroupAttrs))(&(uidNumber=802400004)(objectClass=posixAccount)(objectClass=ipaNTUserAttrs)))"

Could you enable ACL logging (http://www.port389.org/docs/389ds/FAQ/faq.html#Troubleshooting) setting nsslapd-errorlog-level=262272 (128+262144).
Then rerun the two searchs commands one with cifs/ipa01.test.local and the other with 'Directory manager'. Then attach the DS access/errors logs

Could you provide the full ACI definition:
ldapsearch .... -b  "dc=test,dc=local" aci

Comment 6 Jason Woods 2015-07-13 14:33:12 UTC
Enabled the debug and it looks like ACL issue.

Seems when you combine the UID and GID search it hits a Deny for uidNumber on the groups CN - which prevents the entire search.

Attaching two files:
NACLPlugin.txt - errors log file for dirsrv showing the NACLPlugin diagnostics produced by changing nslapd-errorlog-level
aci.txt - Full output of the aci ldapsearch requested

Comment 7 Jason Woods 2015-07-13 14:34:17 UTC
Created attachment 1051440 [details]
NSACLPlugin diagnostics in errors file for dirsrv produced by nsslapd-errorlog-level

Comment 8 Jason Woods 2015-07-13 14:34:38 UTC
Created attachment 1051441 [details]
Full ACI output from ldapsearch for aci

Comment 9 Jason Woods 2015-08-24 14:49:36 UTC
I had a small look at 389-ds source and it looks like it could be how the access check is built. Adding extra debug logs for FILTER, I THINK (not 100% sure) it's happening in vattr_test_filter_list. There's this comment at ldap/servers/slapd/filterentry.c:1010:

/* one false is failure
 * for AND all components need to match 
 * and for AND and OR access to ALL filter attributes is required
 */

So it seems to say that for an LDAP search to work, all attributes in the filter must be accessible for matching items. Which means you can't really run an LDAP search for two kinds of object (like is happening here.) So unless the ACL implementation is wrong I guess the ipa-sam ldapsam_gid_to_sid ldapsearch call just needs splitting into two calls - however undesirable as that sounds. But with the IDMAP cache in use it should be fine. (Though on a separate note - I do notice that the IDMAP cache does NOT get used when it returns the fallback primary group - so maybe a small refactor necessary there.)

Just my two cent.

Comment 10 Jason Woods 2015-08-25 08:15:31 UTC
Created attachment 1066773 [details]
fallback group caching patch

First patch - adds the fallback group SID caching.

Comment 11 Jason Woods 2015-08-25 08:16:30 UTC
Created attachment 1066774 [details]
gid to sid lookup patch

Second patch - fixes the ldap search to run group lookup and user lookup separately. (Depends on first patch for the fallback caching)

Comment 12 Jason Woods 2015-08-25 08:18:49 UTC
Patches are for RHEL 6 and should apply cleanly to the 3.0.0-47.el6 RPM. RHEL 6 inhibits the same issue when connecting to a RHEL 7 IPA server (I installed ipa-server-ad-trust and manually configured Samba.)
I can get a combined patch for RHEL 7 packaging soon if it helps.

Comment 13 Jason Woods 2015-08-25 08:30:42 UTC
Just realised I've got more patches back ported from 3.3 to 3.0 on my RHEL 6 RPM that were needed to get it to talk to the RHEL 7 IPA server. Apologies. Basically I'm running Samba on a RHEL 6 box and using a RHEL 7 IPA environment for authentication.

I'll get some 3.3 patches that apply to RHEL 7 RPM sorted in the coming weeks.

Comment 14 Noriko Hosoi 2015-08-26 23:42:07 UTC
(In reply to Jason Woods from comment #9)
> I had a small look at 389-ds source and it looks like it could be how the
> access check is built. Adding extra debug logs for FILTER, I THINK (not 100%
> sure) it's happening in vattr_test_filter_list. There's this comment at
> ldap/servers/slapd/filterentry.c:1010:
> 
> /* one false is failure
>  * for AND all components need to match 
>  * and for AND and OR access to ALL filter attributes is required
>  */
> 
> So it seems to say that for an LDAP search to work, all attributes in the
> filter must be accessible for matching items. Which means you can't really
> run an LDAP search for two kinds of object (like is happening here.) So
> unless the ACL implementation is wrong I guess the ipa-sam
> ldapsam_gid_to_sid ldapsearch call just needs splitting into two calls -
> however undesirable as that sounds. But with the IDMAP cache in use it
> should be fine. (Though on a separate note - I do notice that the IDMAP
> cache does NOT get used when it returns the fallback primary group - so
> maybe a small refactor necessary there.)
> 
> Just my two cent.

Thanks for the analysis, Jason.  The code around filterentry.c:1010 was added to fix a security issue.
https://access.redhat.com/security/cve/CVE-2013-2219

Now I see you are working on IPA to workaround it.  Can we change the component to IPA?  Thanks.

Comment 15 Noriko Hosoi 2015-09-24 00:41:03 UTC
Hello Jason,

Do you still have an issue in ipasam?  Can we close this bug?

Thanks.

Comment 16 Jason Woods 2015-09-28 11:56:00 UTC
Hi Noriko,

Yes it's still an issue, but on my RHEL 6 machine attached to the RHEL 7 IPA Servers I've worked around it by patching IPASAM in the RHEL 6 packages.

I am in the process of upgrading everything to RHEL 7 and as part of that will port the patches to the RHEL 7 packaging - I will attach that new patch here so it can be considered for upstream submission and inclusion in RHEL 7 packaging.

Thanks!

Jason

Comment 17 Jason Woods 2015-09-28 12:08:47 UTC
For information, the patches do two things for Samba:

1. With log level 10 (possibly at lower levels too), prevent "ERROR: Got 0 entries for gid 543800010, expected at least one" and "returning fallback group" from occurring in logs more than once in a small period of time, regardless of why it failed. This is done by caching the returned fallback group so it need not perform a lookup again until cache expires.

2. Fix permanent failure of "ERROR: Got 0 entries for gid 543800010, expected at least one" on RHEL 7 due to the additional security in NSACLPlugin. This is done by running two queries rather than one. Overhead is insignificant because a successful result is cached. Also, after path 1, failure results are cached too as failure returns a fallback group.

Will attach updated patches that apply to the RHEL 7 RPM soon.

Jason

Comment 18 Petr Vobornik 2015-10-08 14:11:29 UTC
IIUIC comment 9 suggest that it might be fixed by fixing https://fedorahosted.org/389/ticket/48275 , right?

Comment 19 Jason Woods 2015-10-08 14:36:07 UTC
Yes by fixing that, point 2 would be resolved. Only point 1 would remain which is an optimisation opportunity.

Should I continue with the patch for RHEL 7 packages or would you be looking to wait for the ticket to be fixed? Either way I think it would be good to apply the first patch.

On the patches - the RHEL6 ones I attached apply cleanly to RHEL 7 packages albeit with an offset. I can provide ones that apply perfectly if required. I'm still waiting for my server to be ready to fully test the patches for RHEL 7 though (they work perfectly in RHEL 6)

Comment 20 Jason Woods 2015-11-18 09:15:39 UTC
Has anyone managed to look at this?

Will any fix for https://fedorahosted.org/389/ticket/48275 be rolled into RHEL 7?
Also, I would like to hear some feedback on the optimisation opportunity.

Comment 21 Jason Woods 2016-01-11 16:13:00 UTC
Has there been any chance to look at the patches?

I can see https://fedorahosted.org/389/ticket/48275 is yet to be fixed. I was hoping there may be the opportunity to fix some of these as we're very keen on keeping our Samba access as fast as possible as we generally store lots of small files and need to transfer regularly, especially around backups.

Comment 22 Jason Woods 2016-01-11 16:18:40 UTC
IIRC (I forgot to update at the time) the attached patches apply cleanly to RHEL 7 RPM, just with offset.

Comment 23 Petr Vobornik 2016-02-16 16:57:38 UTC
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/5168

Comment 24 Petr Vobornik 2016-02-16 17:11:16 UTC
This is mainly a tracking BZ. Fix has to be done in directory server - https://fedorahosted.org/389/ticket/48275

Comment 25 Petr Vobornik 2016-06-29 11:09:57 UTC
Upstream ticket was fixed.

Comment 27 Jason Woods 2016-07-06 15:50:29 UTC
Excellent! Many thanks everyone. Looking forward to 4.4!

Comment 28 Sudhir Menon 2016-09-20 09:22:31 UTC
Error message as mentioned in Actual Results in original comment is not seen in the log file /var/log/samba/log.wb-TEST-RELM on the test enviornment.

Tested on RHEL73 using 

ipa-server-4.4.0-12.el7.x86_64
ipa-server-trust-ad-4.4.0-12.el7.x86_64
samba-client-4.4.4-9.el7.x86_64
samba-4.4.4-9.el7.x86_64

Steps:-

[root@master ~]# mkdir /srv/testshare
[root@master ~]# chcon -t samba_share_t /srv/testshare
[root@master ~]# setfacl -m g:projects:rwx  /srv/testshare
[root@master ~]# getfacl /srv/testshare
getfacl: Removing leading '/' from absolute path names
# file: srv/testshare
# owner: root
# group: root
user::rwx
group::r-x
group:projects:rwx
mask::rwx
other::r-x

[root@master ~]# net conf addshare testshare /srv/testshare writeable=y guest_ok=N

[root@client ~]# smbclient -k //master.test-relm.test/testshare
Domain=[TEST-RELM] OS=[Windows 6.1] Server=[Samba 4.4.4]
smb: \> ls
  .                                   D        0  Tue Sep 20 14:14:32 2016
  ..                                  D        0  Tue Sep 20 12:12:38 2016
  abc.txt                             N        0  Tue Sep 20 14:14:14 2016
  samba.txt                           N        0  Tue Sep 20 14:14:24 2016
  samba1                              D        0  Tue Sep 20 14:14:29 2016

		8374272 blocks of size 1024. 3987860 blocks available
smb: \> del abc.txt
smb: \> ls
  .                                   D        0  Tue Sep 20 14:15:10 2016
  ..                                  D        0  Tue Sep 20 12:12:38 2016
  xyz.txt                             N        0  Tue Sep 20 14:14:18 2016
  samba.txt                           N        0  Tue Sep 20 14:14:24 2016
  samba1                              D        0  Tue Sep 20 14:14:29 2016
		8374272 blocks of size 1024. 3987692 blocks available
smb: \> 


3. ldapsearch -x -LLL
dn: cn=projects,cn=groups,cn=accounts,dc=test-relm,dc=test
objectClass: ipaobject
objectClass: top
objectClass: ipausergroup
objectClass: posixgroup
objectClass: groupofnames
objectClass: nestedgroup
objectClass: ipantgroupattrs
cn: projects
ipaUniqueID: ca657ba8-7e6d-11e6-a5c1-525400e715b1
gidNumber: 539000019
ipaNTSecurityIdentifier: S-1-5-21-2020752-2967521820-3052267834-1019

4. [root@master samba]# ipa group-find projects
---------------
1 group matched
---------------
  Group name: projects
  GID: 539000019

5. [root@master samba]# ldapsearch -Y GSSAPI -H 'ldapi://%2fvar%2frun%2fslapd-TEST-RELM-TEST.socket' '(|(&(gidNumber=539000013)(objectClass=ipaNTGroupAttrs))(&(uidNumber=539000013)(objectClass=posixAccount)))'
SASL/GSSAPI authentication started
SASL username: admin@TEST-RELM.TEST
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <dc=test-relm,dc=test> (default) with scope subtree
# filter: (|(&(gidNumber=539000013)(objectClass=ipaNTGroupAttrs))(&(uidNumber=539000013)(objectClass=posixAccount)))
# requesting: ALL
#

# user2, users, compat, test-relm.test
dn: uid=user2,cn=users,cn=compat,dc=test-relm,dc=test
cn: user2 s
objectClass: posixAccount
objectClass: ipaOverrideTarget
objectClass: top
gidNumber: 539000013
ipaAnchorUUID:: OklQQTp0ZXN0LXJlbG0udGVzdDpkN2YwNDU0Ni03ZTYzLTExZTYtYmVhOS01Mj
 U0MDBlNzE1YjE=
gecos: user2 s
uidNumber: 539000013
loginShell: /bin/sh
homeDirectory: /home/user2
uid: user2

# user2, users, accounts, test-relm.test
dn: uid=user2,cn=users,cn=accounts,dc=test-relm,dc=test
displayName: user2 s
uid: user2
krbCanonicalName: user2@TEST-RELM.TEST
objectClass: ipaobject
objectClass: person
objectClass: top
objectClass: ipasshuser
objectClass: inetorgperson
objectClass: organizationalperson
objectClass: krbticketpolicyaux
objectClass: krbprincipalaux
objectClass: inetuser
objectClass: posixaccount
objectClass: ipaSshGroupOfPubKeys
objectClass: mepOriginEntry
objectClass: ipantuserattrs
loginShell: /bin/sh
initials: us
gecos: user2 s
sn: s
homeDirectory: /home/user2
mail: user2@test-relm.test
krbPrincipalName: user2@TEST-RELM.TEST
givenName: user2
cn: user2 s
ipaUniqueID: d7f04546-7e63-11e6-bea9-525400e715b1
uidNumber: 539000013
gidNumber: 539000013
mepManagedEntry: cn=user2,cn=groups,cn=accounts,dc=test-relm,dc=test
ipaNTSecurityIdentifier: S-1-5-21-2020752-2967521820-3052267834-1013
memberOf: cn=ipausers,cn=groups,cn=accounts,dc=test-relm,dc=test
memberOf: cn=projects,cn=groups,cn=accounts,dc=test-relm,dc=test

# search result
search: 4
result: 0 Success

# numResponses: 3
# numEntries: 2

Comment 30 errata-xmlrpc 2016-11-04 05:46:08 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2404.html


Note You need to log in before you can comment on or make changes to this bug.