Hide Forgot
Description of problem: Zarafa is producing errors when users are created in LDAP: Fri Jul 29 01:18:42 2011: Unable to find company id for object peter griffin These errors can be caused by various user creation means (php, ldapadd, or even when changing a user's ou in directory server) Version-Release number of selected component (if applicable): 7.0.0-1.el5 How reproducible: Unknown Steps to Reproduce: 1. create a user with a script 2. run zarafa-admin -l Actual results: zarafa attemps to create user store and then produces the error Expected results: zarafa should create the user store and successfully completed Additional info: I have attached various files -- the server configuration, the ldap configuration, and two ldif files of a user that works and a user that does not work.
Created attachment 515808 [details] zarafa schema this schema is being used with centos ds
Created attachment 515809 [details] zarafa server's ldap config file
Created attachment 515810 [details] zarafa server config file
Created attachment 515811 [details] ldif output of a user created with PHP that does not generate a company id error
Created attachment 515812 [details] ldif output of a user created with PHP that does generate a company id error
I'm wondering if there is a problem in the code that checks the company id: /* * Since we already need the company name here, we convert the * OB_PROP_O_COMPANYID to the internal ID too */ sCompany = lpDetails->GetPropObject(OB_PROP_O_COMPANYID); er = GetLocalId(sCompany, &ulCompanyId); if (er != erSuccess) { m_lpLogger->Log(EC_LOGLEVEL_FATAL, "Unable to find company id for object " + lpDetails->GetPropString(OB_PROP_S_FULLNAME)); goto exit; } I don't really understand what it does, but the error is not very verbose. If someone could explain what is being examined here and what the expected input is, it would be great. I can say that with 100% reliability, a user created by using the centos ds / 389 directory console will always work no matter what ou it is placed in. I get unreliable performance creating users with various scripts (php, bash, etc) and cannot pin-point what the differences are, as all of the ldap information appears to be consistent (present/absent,etc).
After some testing we determined what the issue was -- whitespace in the DN of the user. Example company definition (LDIF): dn: ou=empiregameleague.com,dc=empiregameleague, dc=com objectClass: top objectClass: organizationalunit objectClass: zarafa-company ou: empiregameleague.com cn: empiregameleague.com modifyTimestamp: 20110728115021Z Notice that the DN of the company has a space. Example user DN (company id error) uid=peter,ou=foobar,dc=empiregameleague,dc=com Example user DN (successful) uid=peter,ou=foobar,dc=empiregameleague, dc=com This signifies that, when zarafa is parsing ldap entries to find new users, it is whitespace sensitive to the DN of the user. I can't seem to find definitive information about whether or not the RFCs for LDAP specify about whitespace in DNs.
Summary from IRC: [15:09:02] < thoraxe> it's not that zarafa can't find the user [15:09:26] < thoraxe> it's that zarafa finds *a* user, but doesn't think it is the *right* user, because the dn isn't a whitespace-exact match to the dn of the company [15:09:36] < thoraxe> so here's the basic zarafa process for creating a user [15:09:52] < thoraxe> zarafa will look for all the "companies" (in this case, specified by ou=whatever) [15:09:56] < thoraxe> it then looks at all companies for users [15:10:09] < thoraxe> if it finds a user it doesn't know about, it creates a store [15:10:11] < thoraxe> that last part is where zarafa is getting hung up [15:10:37] < thoraxe> if the company is "ou=foobar,dc=example, dc=com" and your user is "uid=john,ou=foobar,dc=example,dc=com" zarafa will say "i can't figure out which company this user belongs to" [15:10:48] < thoraxe> i.e. zarafa is sensitive to the whitespace in the DN of the user [15:10:59] < thoraxe> to me, that is a bug in zarafa [15:11:34] < thoraxe> because if your user is "uid=john,ou=foobar,dc=example, dc=com" then it works [15:11:58] < thoraxe> so that sounds like zarafa is not doing any processing of the dn that it actually ingests
For now, this is upstream Ticket#2011072910000251. I'm not an LDAP expert, but even if this is not a clear bug, just annoying behaviour, it should be fixed.
How can you import the ldif with the whitespace in the 389 directory? I used next to the ldapadd command or different graphical ldap clients, to import the ldif, but everytime all whitespaces will be stripped off. So i'm unable to get test setup where i can reproduce it. Still i'm think it's not really a Zarafa issue as Zarafa is not parsing the DN's.
When you do the initial installation of the directory and use an answers file, if there is a space, it will create the root of the entire directory with the space. Example below, where suffix is specified as "dc=empiregameleague, dc=com" with a space. I doubt that you can alter this after the fact, and all of the corresponding ldap tools and 389/CentOS DS/RHDS itself will ignore the whitespace when you perform actions against it (ldapmodify, ldapsearch, etc). Adding new users without a space versus with a space seems to be non-normalized, which is how I found this problem in the first place. I was able to ldapadd (from command-line) a user that was "dc=empiregameleague,dc=com" as the suffix. Unfortunately, 389/CentOSDS/RHDS does not normalize output, which means that when you do an ldapsearch, it does show the space. This is where Zarafa fails. If your suffix is defined with a space, and you create a user without as space, Zarafa gets confused. Please refer to comment 7 above to see where Zarafa decides the entry with a space and without a space are different. I think this behavior is clearly a bug in the upstream directory server, but, according to RFC, Zarafa should probably normalize the LDAP input and ignore the whitespace of DNs. [General] AdminDomain = www.empiregameleague.com SuiteSpotGroup = ldap ConfigDirectoryLdapURL = ldap://www.empiregameleague.com:389/o=NetscapeRoot ConfigDirectoryAdminID = admin SuiteSpotUserID = ldap ConfigDirectoryAdminPwd = ldapadmin FullMachineName = www.empiregameleague.com [admin] ServerAdminID = admin ServerAdminPwd = ldapadmin SysUser = ldap ServerIpAddress = 0.0.0.0 Port = 9830 [slapd] InstallLdifFile = suggest ServerIdentifier = www ServerPort = 389 AddOrgEntries = Yes RootDN = cn=Directory Manager RootDNPwd = ldap SlapdConfigForMC = yes Suffix = dc=empiregameleague, dc=com UseExistingMC = 0 AddSampleEntries = No
Note that creating a suffix with a space may not be possible in RHDS 8.2, but CentOS is only shipping 8.1. I can test this with upstream 389 at some point, but it would seem to me that Zarafa should still ignore the whitespace.
Upstream isn't treating this as a bug and whitespaces in DN are strange anyway.
It's unfortunate. I'm pretty sure that means Zarafa is not RFC compliant, but as it's difficult to reproduce with most LDAP implementations, I can understand their decision.