<html><head><style data-externalstyle="true"><!--
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst, p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle, p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
--></style></head><body><div data-externalstyle="false" dir="ltr" style="font-family:Calibri,'Segoe UI',Meiryo,'Microsoft YaHei UI','Microsoft JhengHei UI','Malgun Gothic','Khmer UI','Nirmala UI',Tunga,'Lao UI',Ebrima,sans-serif;font-size:12pt;"><div>Sorry, I didn’t include much in the way of specifics did I?! Before yum updated my IPA server from 2.2 to 3, FreeIPA provided (or appeared to provide) an instance of an LDAP server that was accessible locally on port 389. The web applications I am concerned with is Atlassian Crowd, which I use to authenticate to Jira, Confluence, Bamboo and Fisheye on the local network and also Google Apps. Crowd is on the same server as FreeIPA so as to allow me to keep port 389 behind the server’s firewall. Crowd was configured to treat the LDAP server as a read only 389 DS server as experimentation showed that that worked, but I did not install or configure any LDAP software myself. The LDAP server had been installed as part of the FreeIPA installation.</div><div> </div><div>Crowd is failing since the update as there is no server listening on port 389. It gets a ‘connection refused’ message. Netstat confirms that there is no server listening on port 389 and also shows that there is nothing listening on port 636. Prior to the upgrade, FreeIPA had been running with default settings, I had done nothing to reduce security.</div><div> </div><div>Regards</div><div> </div><div>Simon</div><div> </div><div style="padding-top: 5px; border-top-color: rgb(229, 229, 229); border-top-width: 1px; border-top-style: solid;"><div><font face="Calibri, 'Segoe UI', Meiryo, 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', 'Khmer UI', 'Nirmala UI', Tunga, 'Lao UI', Ebrima, sans-serif" style='line-height: 15pt; letter-spacing: 0.02em; font-family: Calibri, "Segoe UI", Meiryo, "Microsoft YaHei UI", "Microsoft JhengHei UI", "Malgun Gothic", "Khmer UI", "Nirmala UI", Tunga, "Lao UI", Ebrima, sans-serif; font-size: 11pt;'><b>From:</b> Dmitri Pal<br><b>Sent:</b> Sunday, 7 April 2013 20:20<br><b>To:</b> freeipa-users@redhat.com</font></div></div><div> </div>
On 04/07/2013 05:44 AM, Simon Williams wrote:
<blockquote style="margin-top: 0px; margin-bottom: 0px;" cite="mid:CAJWeEdS0RtQQFyEeR0Ce5RhVxeq72VJ=HtKQ-LaQJpxJqQmj9w@mail.gmail.com">
<p dir="ltr">Hi</p>
<p dir="ltr">I ran a yum update on my CentOS 6 server that runs
FreeIPA a couple of days ago and it upgraded FreeIPA to version
3. I use a couple of web applications that cannot use Kerberos,
but can use LDAP to authenticate. These stopped working. When I
investigated the issue, I discovered that the LDAP server wasn't
there any more. Google searches have proved fruitless and I
can't find any documentation for v3. Can anyone tell me how to
get my LDAP server back?</p>
<p dir="ltr">Regards</p>
<p dir="ltr">Simon</p>
<br>
</blockquote>
<br>
Hello Simon,<br>
<br>
Can you please clarify:<br>
Did you have an earlier version of the apps that used IPA via LDAP
or you had a different LDAP instance and FreeIPA now took over the
whole machine and you do not have access to those instances?<br>
I assume you had 389 DS, right? Or OpenLDAP?<br>
<br>
What is the general goal? Do you want to have the apps be able to
access IPA data via LDAP or you want to be able to use different
LDAP databases on the same machine?<br>
<br>
If the apps you mention used to work against IPA and now they do not
I would suggest checking the logs from those applications to see
what is failing. It might be that they have been using an insecure
way to authenticate and the upgraded bits enforce a higher security
standard. If this is the case you either need to lower the
authentication requirements on the server (not recommended) or
provide a more secure way to authenticate from those apps
(recommended).<br>
<br>
<br>
<blockquote style="margin-top: 0px; margin-bottom: 0px;" cite="mid:CAJWeEdS0RtQQFyEeR0Ce5RhVxeq72VJ=HtKQ-LaQJpxJqQmj9w@mail.gmail.com">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
Freeipa-users mailing list
<a title="mailto:Freeipa-users@redhat.com" class="moz-txt-link-abbreviated" href="mailto:Freeipa-users@redhat.com" target="_parent">Freeipa-users@redhat.com</a>
<a title="https://www.redhat.com/mailman/listinfo/freeipa-users" class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_parent">https://www.redhat.com/mailman/listinfo/freeipa-users</a></pre>
</blockquote>
<br>
<br>
<pre class="moz-signature">--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
<a title="http://www.redhat.com/carveoutcosts/" class="moz-txt-link-abbreviated" href="http://www.redhat.com/carveoutcosts/" target="_parent">www.redhat.com/carveoutcosts/</a>
</pre>
</div></body></html>