adtrust upgrade: fix wrong primary principal name

Upgrade code had Kerberos principal names mixed up: instead of creating
krbtgt/LOCAL-FLAT@REMOTE and marking LOCAL-FLAT$@REMOTE as an alias to
it, it created LOCAL-FLAT$@REMOTE Kerberos principal and marked
krbtgt/LOCAL-FLAT@REMOTE as an alias.

This differs from what Active Directory expects and what is created by
ipasam plugin when trust is established. When upgrading such deployment,
an upgrade code then unexpectedly failed.

Resolves: https://pagure.io/freeipa/issue/7992
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
This commit is contained in:
Alexander Bokovoy
2019-06-25 15:22:57 +03:00
committed by Christian Heimes
parent 0294ad2133
commit 34bfffd1be
3 changed files with 18 additions and 14 deletions

View File

@@ -2039,11 +2039,13 @@ static bool handle_cross_realm_princs(struct ipasam_private *ipasam_state,
pwd_outgoing, trusted_dn,
KRB_PRINC_CREATE_DEFAULT);
/* Second: <OUR FLATNAME$>@<REMOTE REALM> is only used
* for SSSD to be able to talk to AD DCs but it has to
* have canonical name set to <OUR FLATNAME>$ because
* this is the salt used by AD DCs when using this
* principal, otherwise authentication will fail.
/* Second: krbtgt/<OUR FLATNAME>@<REMOTE REALM>
* is only used for SSSD to be able to talk to
* AD DCs but it has to have canonical name set
* to krbtgt/<OUR FLATNAME> and alias it to
* <OUR FLATNAME$> because it is the salt used
* by AD DCs when using this principal,
* otherwise authentication will fail.
*
* *disable* use of this principal on our side as it is
* only used to retrieve trusted domain credentials by