The purpose of --ip-address is not to bind servers to a specific address to to select the identity of the machine.

IPA strongly discourages running other services on an IPA master.

That said, nsslapd-listenhost can restrict what interfaces 389-ds listens on: https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/configuration_command_and_file_reference/core_server_configuration_reference#cnconfig-nsslapd_listenhost_Listen_to_IP_Address

Given the number of services IPA needs to configure some fundamental assumptions are made, one of which is that IPA is the only service on a given machine. This is also a practical consideration to reduce the threat surface.

While it may be possible to configure the various IPA services to listen on a specific interface (it wasn't possible in some in the past) no effort to date has been done in this regard and it would require quite a lot of effort with little payback considering we don't recommend installing other services anyway.

I understand the reasoning behind reserving one machine exclusively for FreeIPA, but I still believe this bug report to be a valid issue.

A common scenario is a machine with multiple physical or virtual ethernet adapters, one of which is connected to the LAN which FreeIPA serves while the others are used for remote management/monitoring (SSH, syslog/logstash, backups, SNMP...) on separate networks which should not come into contact with FreeIPA services, and vice versa. I am facing precisely this scenario on a VPS connected to both a WAN (for remote access) and a VLAN (which FreeIPA shall serve).

Firewall rules go a long way in mitigating undesired access, but I would like to argue in favour of implementing an option to limit the IPs/ethernet adapters that FreeIPA binds to in order to allow full separation of services on the host machine. (Not least because in my experience FreeIPA is incredibly fragile with regards to adressing and name resolution, but that is a separate issue.)