[Freeipa-users] ipa-server-4.1.0 ipasam performance issue / strange behaviour

[Alexander Bokovoy]

----- Original Message -----
> Hi,
> 
> I’ve started playing around with Samba shared on an IPA server running 4.1.0
> (CentOS 7 latest as of 30-06-2015).
> I’m having an issue with performance - it seems to connect to ldap almost 10
> times for every file operation to try lookup a group - and the lookup fails.
> On another system running IPA 3.0.0 on CentOS 6.6 this runs perfectly, and
> the lookup succeeds.
> 
> Everything is setup:
> yum install ipa-server-trust-ad
> ipa-adtrust-install
> 
> Logging level set to 9999: net conf setparm global ‘log level’ 10
> Samba share setup to share a /data directory:
> 
> [Test]
> 	path = /data
> 	guest ok = no
> 	read only = no
> 	valid users = @projects
> 
> Connecting to the share is great - all works fine - but then copying files is
> somewhat slower than expected.
> Examining log.workstation I can see that the group lookup for the @projects
> group is not functioning:
> 
> [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
> 
> This happens almost 10 times per file I copy into the share.
> Checking dirsrv logs, the query is returning 0 entries - so that confirms
> what ipasam is reporting.
> However, running the query manually as root (which connect as Directory
> Manager as opposed to the cifs service principle) it returns results:
> 
> [root at 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
> 
> If I load the keytab for Samba: kinit -t /etc/samba/samba.keytab
> cifs/ipa02.XXX at XXX
> Then run the query using GSSAPI - I get no results!
> 
> [root at 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 at 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
> 
> Even stranger, if I split the OR filter and only run the group part, but
> still running through GSSAPI - it is successful!
> 
> [root at ipa02 data]# ldapsearch -Y GSSAPI -H
> 'ldapi://%2fvar%2frun%2fslapd-XXX.socket'
> '(&(gidNumber=543800010)(objectClass=ipaNTGroupAttrs))'
> SASL/GSSAPI authentication started
> SASL username: cifs/XXX at 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
> 
> Any ideas what might be happening here?
> I’ve read something about non-existent attributes can mess with OR queries.
> But I can’t understand why it would only affect the GSSAPI authenticated
> user.
This is definitely an issue with ACLs or NACLPlugin. 

Regarding LDAPI+root and GSSAPI -- the first one maps to cn=Directory Manager, the second one maps to a specific DN.
When you are cn=Directory Manager, no ACLs apply to you, so the result is expected.
-- 
/ Alexander Bokovoy