#3272 Installer code should not use LDAPS
Opened 11 years ago by pviktori. Modified 4 years ago

LDAP-over-SSL (ldaps://) is deprecated. We should not use it.

To quote Simo:

In order of preference[[BR]]
LDAP/GSSAPI[[BR]]
LDAP/TLS/[[BR]]
LDAPS[[BR]]
[[BR]]
but using ldaps is not the end of the world, so don't tie yourself up
due to this.

EDIT (2013-01-16, mkosek):
We should also use LDAPI in during the installer when possible (see Simo's suggestion). It would help us avoid tickets like #3355.


Can be fixed in patches to other installer tickets (#2660, #2652).

Suggested triage: Pilsner, minor, no clone

Correction: obviously I meant LDAP-OVER-SSL, not SSH

Description fixed. I think, that in we may even want to implement a fallback between the connections, if possible...

Note: this also affects ipa-join.

I was just struggling a bit with split enrollment when {{{ipa-client-install --password}}} was failing with

Joining realm failed: Incorrect password

Only when I did strace, I found failed connection to port 636.

On the other hand, if I block port 389 and run {{{ipa-client-install}}} I immediately get nice message

Failed to verify that cloud-qe-9.testrelm.com is an IPA Server.
This may mean that the remote server is not up or is not reachable due to network or firewall settings.
Please make sure the following ports are opened in the firewall settings:
     TCP: 80, 88, 389
     UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
Also note that following ports are necessary for ipa-client working properly after enrollment:
     TCP: 464
     UDP: 464, 123 (if NTP enabled)

So if ldaps is not going away any time soon, better handling of the 636 connect failure could be added.

Metadata Update from @pviktori:
- Issue assigned to someone
- Issue set to the milestone: Future Releases

7 years ago

Is it possible then to use ipa-client-install or ipa-join if only port 636 is available? My understanding is that SSSD protocol uses 389 during the ipa-client-install to complete the authentication over port 636. Would my only option then be to do a manual join (import certificate with wget, etc) ? Is there a documented process for this? Thanks!

ipa-join is still hardcoded to use port 636.

ipa-getkeytab uses 389.

ipa-client uses port 389 with GSSAPI to retrieve the CA chain. There are other ways to obtain it, I'm pretty sure the man page has details.

I don't believe there is a currently documented manual setup. It very much depends on what nss client is used.

Metadata Update from @rcritten:
- Issue close_status updated to: None

4 years ago

There are following hardcoded logical decisions in the code that is used during deployment:

  • ipa-join hardcodes port 389 and uses GSSAPI for sealing the communication.
  • ipa provider in SSSD hardcodes use of port 389 too as it uses GSSAPI authentication. It is not possible currently to force SSSD with ipa provider to always use LDAPS (port 636).
  • ipa-getkeytab hardcodes use of port 389 when requesting a keytab. Here one can explicitly specify other LDAP url with -H option but it is not possible to change the way how ipa-join calls to ipa-getkeytab.

Could you please explain why you are insisting on use of port 636?

The plan is to get an IPA master talking to a slave or client across an intranet connection that insists on blocking port 389 (cleartext ldap). There are maybe four switches to hop through to get there. I might be able to convince security to make an exception based on our source ip address, but there's a good chance they will insist on blocking all 389 traffic. Port 636 is reachable.

There's other temporary possibilities like using "ipa-nis-manage enable" but they would be insecure and not recommended.

389/TCP is not just cleartext LDAP. It's also LDAP + STARTTLS and LDAP sealed with GSSAPI. If you are concerned about cleartext LDAP, then you can disable BIND over unprotected LDAP in 389-DS.

There are some manual client join processes online, but they look a bit dated:

https://www.redhat.com/archives/freeipa-users/2012-March/msg00094.html

, and even if I succeeded at joining a client, would I be able to get sssd and all ipa's moving parts to work without port 389 ?

Correct, it will not work that way.

If you have hostile switches around, another option is to use VPN acros WAN.

, and even if I succeeded at joining a client, would I be able to get sssd and all ipa's moving parts to work without port 389 ?

No, a lot of things depend on LDAP default port, amongst other LDAP replication.

thanks for confirming that. I think the core switches on campus block all 389 traffic just because they fear clear text. I will have to look into other solutions like VPN or moving some servers into the same LAN.

Login to comment on this ticket.

Metadata