After upgrading my FreeIPA VMs (successfully and without errors) from F19 to F20, I am seeing the following in the dirsrv access log when using the FreeIPA web interface. In this case, I was editing a DNS entry for a host.
dirsrv access log
[03/Mar/2014:14:12:02 -0600] conn=6 op=635 SRCH base="cn=ipa1.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [03/Mar/2014:14:24:54 -0600] conn=6 op=768 SRCH base="cn=ipa1.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [03/Mar/2014:14:24:55 -0600] conn=5 op=645 SRCH base="cn=ipa1.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [03/Mar/2014:14:24:55 -0600] conn=6 op=777 SRCH base="cn=ipa1.example.com8&�,cn=masters,cn=ipa,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [03/Mar/2014:14:24:56 -0600] conn=5 op=653 SRCH base="cn=ipa1.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [03/Mar/2014:14:24:56 -0600] conn=6 op=785 SRCH base="cn=ipa1.example.com8&�,cn=masters,cn=ipa,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [03/Mar/2014:14:25:01 -0600] conn=5 op=661 SRCH base="cn=ipa1.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [03/Mar/2014:14:25:02 -0600] conn=6 op=793 SRCH base="cn=ipa1.example.com8&�,cn=masters,cn=ipa,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [03/Mar/2014:14:25:08 -0600] conn=5 op=670 SRCH base="cn=ipa1.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [03/Mar/2014:14:25:09 -0600] conn=6 op=802 SRCH base="cn=ipa1.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [03/Mar/2014:14:25:13 -0600] conn=5 op=679 SRCH base="cn=ipa1.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [03/Mar/2014:14:25:14 -0600] conn=6 op=811 SRCH base="cn=ipa1.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [03/Mar/2014:14:25:19 -0600] conn=5 op=687 SRCH base="cn=ipa1.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [03/Mar/2014:14:25:20 -0600] conn=5 op=696 SRCH base="cn=ipa1.example.comN7&�,cn=masters,cn=ipa,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [03/Mar/2014:14:25:43 -0600] conn=5 op=704 SRCH base="cn=ipa1.example.com�7&�,cn=masters,cn=ipa,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [03/Mar/2014:14:25:44 -0600] conn=5 op=713 SRCH base="cn=ipa1.example.com objec!,cn=masters,cn=ipa,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL
What had prompted me was that I saw the following in the dirsrv error log earlier
[03/Mar/2014:13:31:11 -0600] entryrdn-index - entryrdn_index_read: Param error: Failed to convert cn=ipa1.example.com7�"�,cn=masters,cn=ipa,cn=etc,dc=example,dc=com to Slapi_RDN [03/Mar/2014:13:31:11 -0600] - dn2entry_ext: Failed to get id for cn=ipa1.example.com7�"�,cn=masters,cn=ipa,cn=etc,dc=example,dc=com from entryrdn index (34)
what exact versions of freeipa and 389-ds are you running ?
are there more details onhow to reproduce, i played a bit with the UI, but didn't see this ?
can you reproduce this with ldapsearch -b "cn=ipa1.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com" -s base
freeipa-server-3.3.4-3.fc20.x86_64, bind-dyndb-ldap-3.5-1.fc20.x86_64 freshly upgraded F20 from F19. I've done a bit more playing with the web UI and find that this tends to occur when I'm adding or changing entries to/for a host in DNS.
I cannot reproduce with ldapsearch -b "cn=ipa1.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com" -s base.
Also, tracing back the "conn" number in the dirsrv access log, the connections seem to be made internally with the "Directory Manager" account.
I did not reproduce the issue myself, but find the most probably root cause in ipadb_fill_info3 function:
data = krb5_princ_component(ipactx->context, princ, 1); strres = malloc(data->length); if (strres == NULL) { krb5_free_principal(ipactx->kcontext, princ); return ENOENT; } memcpy(strres, data->data, data->length); krb5_free_principal(ipactx->kcontext, princ); /* Only add PAC to TGT to services on IPA masters to allow querying * AD LDAP server */ if (!is_master_host(ipactx, strres)) { free(strres); return ENOENT; }
strres was not NULL terminated and may have caused the reported cn=masters queries in is_master_host.
cn=masters
is_master_host
I will send a patch.
Patch ''freeipa-mkosek-459-avoid-passing-non-terminated-string-to-is_master_hos.patch'' sent for review freeipa-mkosek-459-avoid-passing-non-terminated-string-to-is_master_hos.patch
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1075091
master:
ipa-3-3:
Metadata Update from @amessina: - Issue assigned to mkosek - Issue set to the milestone: FreeIPA 3.3.5 (bug fixing)
Login to comment on this ticket.