Bug 1238190

Changing component according to Alexander's suspicion that there is something wrong in ACL implementation.

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!

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,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; failure
SASL/GSSAPI authentication started
SASL username: cifs/ipa01.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,cn=services,cn=accounts,dc=test,dc=local

This is likely that the DS ACL are preventing 'krbprincipalname=cifs/ipa01.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

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

Created attachment 1051440 [details]
NSACLPlugin diagnostics in errors file for dirsrv produced by nsslapd-errorlog-level

Created attachment 1051441 [details]
Full ACI output from ldapsearch for aci

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.

Created attachment 1066773 [details]
fallback group caching patch

First patch - adds the fallback group SID caching.

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)

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.

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.

(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.

Hello Jason,

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

Thanks.

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

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

IIUIC comment 9 suggest that it might be fixed by fixing https://fedorahosted.org/389/ticket/48275 , right?

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)

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.

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.

IIRC (I forgot to update at the time) the attached patches apply cleanly to RHEL 7 RPM, just with offset.

Upstream ticket:
https://fedorahosted.org/freeipa/ticket/5168

This is mainly a tracking BZ. Fix has to be done in directory server - https://fedorahosted.org/389/ticket/48275

Upstream ticket was fixed.

Excellent! Many thanks everyone. Looking forward to 4.4!

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
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
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
krbPrincipalName: user2
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

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