----- 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@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@XXX > Then run the query using GSSAPI - I get no results! > > [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 > > Even stranger, if I split the OR filter and only run the group part, but > still running through GSSAPI - it is successful! > > [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 > > 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 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
