mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2026-10-25 14:40:16 -05:00
Florence Blanc-Renaud
4a7345e448
ipa-replica-conncheck connects to the master using an SSH command:
ssh -o StrictHostKeychecking=no -o UserKnownHostsFile=<tmpfile> \
-o GSSAPIAuthentication=yes <principal>@<master hostname> \
echo OK
The issue is that the principal name is not fully qualified (for instance
'admin' is used, even if ipa-replica-conncheck was called with
--principal admin@EXAMPLE.COM).
When the FreeIPA server is running with a /etc/sssd/sssd.conf containing
[sssd]
default_domain_suffix = ad.domain.com
this leads to the SSH connection failure because admin is not defined in
the default domain.
The fix uses the fully qualified principal name, and calls ssh with
ssh -o StrictHostKeychecking=no -o UserKnownHostsFile=<tmpfile> \
-o GSSAPIAuthentication=yes -o User=<principal> \
<master hostname> echo OK
to avoid syntax issues with admin@DOMAIN@master
https://fedorahosted.org/freeipa/ticket/5812
Reviewed-By: Martin Basti <mbasti@redhat.com>
Ground rules on adding new schema Brand new schema, particularly when written specifically for IPA, should be added in share/*.ldif. Any new files need to be explicitly loaded in ipaserver/install/dsinstance.py. These simply get copied directly into the new instance schema directory. Existing schema (e.g. in an LDAP draft) may either be added as a separate ldif in share or as an update in the updates directory. The advantage of adding the schema as an update is if 389-ds ever adds the schema then the installation won't fail due to existing schema failing to load during bootstrap. If the new schema requires a new container then this should be added to install/bootstrap-template.ldif.