Can you please collect debug logs from httpd's error_log and access_log? Please create /etc/ipa/server.conf with

[global]
debug = True

and restart httpd before retry.

As for behavior, login with an alias should be supported but indeed it should not lead to the infinite redirect.

error_log
access_log

Thanks. The batch processing of the commands completes successfully without any trouble.

Login starts at 13:55:13:

[Mon Aug 22 13:55:13.427642 2022] [wsgi:error] [pid 14876:tid 15249] [remote 10.40.195.37:63398] ipa: DEBUG: WSGI login_password.__call__:

ends a 400ms later:

[Mon Aug 22 13:55:13.828157 2022] [wsgi:error] [pid 14877:tid 15243] [remote 10.40.195.37:63398] ipa: INFO: [jsonserver_session] root@IPA.TEST: batch(config_show(), whoami(), env(None), dns_is_enabled(), trustconfig_show(), domainlevel_get(), ca_is_enabled(), vaultconfig_show()): SUCCESS

so this is good. Next step is to show a view for the admin, we get user_show(admin) request and then the batch repeats again. I suspect it is an issue with Web UI javascript code that does not realize we are using an alias to login.

There is one place that might be affected: it is success_handler function in rpc.js:rpc.command(). It has the following fragment:

        function success_handler(data, text_status, xhr) {
...
            } else if (IPA.principal && data.principal &&
                IPA.principal.toLowerCase() !== data.principal.toLowerCase()) {
                window.location.reload();
...
            } else if (data.error) {
...

If my hunch is correct, it does force a reload of the page if the principal it thought we are using not the same as we got back in the JSON response.

Can you do a browser-side debug to see what is the content of the returned JSON object? Alternatively, you can try to do on IPA master the following:

# /usr/bin/kinit -n -c ./armor_14876 -X X509_anchors=FILE:/var/kerberos/krb5kdc/kdc.crt -X X509_anchors=FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
# /usr/bin/kinit  root -c ./kinit_14876 -T ./armor_14876 -E
# klist -efC -c ./kinit_14876
# KRB5CCNAME=./kinit_14876 ipa -vvv vaultconfig-show

the last command should show the response JSON output

Probably even better the last command would be

KRB5CCNAME=./kinit_14876 ipa -vvv console
(Custom IPA interactive Python console)
    api: IPA API object
    pp: pretty printer
>>> api.Command.whoami()
...

We will see the principal and the user name used.

The crux of the problem is that we don't ask KDC to canonicalize the principal when asking for a ticket internally (kinit -E just asks to process aliases but doesn't ask to return it canonicalized). A fix could be to add -C to ask KDC to canonicalize it.

diff --git a/ipaserver/rpcserver.py b/ipaserver/rpcserver.py
index 1f85e9898..4e8a08b66 100644
--- a/ipaserver/rpcserver.py
+++ b/ipaserver/rpcserver.py
@@ -1109,6 +1109,7 @@ class login_password(Backend, KerberosSession):
                 ccache_name,
                 armor_ccache_name=armor_path,
                 enterprise=True,
+                canonicalize=True,
                 lifetime=self.api.env.kinit_lifetime)
             if armor_path:

@abbra, Setting a debugger breaking-point where you asked:

> IPA.whoami.data.krbprincipalname
< (2) ['admin@IPA.DEMO', 'root@IPA.DEMO']
> IPA.principal
< 'admin@IPA.DEMO'
> data.principal
< 'root@IPA.DEMO'

Thank you. Can you apply the fix?

I tried, but no success.

It's attributed to IPA.principal the first item in whoami.data.krbprincipalname (install/ui/src/freeipa/ipa.js#_274):

on_success: function (data, text_status, xhr) {
    that.whoami.data = data.result.result;
    var entity = that.whoami.metadata.object;
    if (entity === 'user') {
        var cn = that.whoami.data.krbcanonicalname;
        if (cn) that.principal = cn[0];
        if (!that.principal) {
            that.principal = that.whoami.data.krbprincipalname[0];
            debugger;
        }
    } else if (entity === 'idoverrideuser') {
        that.principal = that.whoami.data.ipaoriginaluid[0];
    }
}

@abbra, I'm still stuck in the loop after applying your fix. However, api.Command.whoami() response prints the principal from root key principal (data.principal). UI is setting principal from data.result.result.krbprincipalname[0]

Considering the breakpoint from previous comment:

> that.whoami.data.krbprincipalname[0]
< 'admin@IPA.DEMO'
> data.principal
< 'root@IPA.DEMO'

I don't know why your fix didn't work for me, but the diff below did:

diff --git a/install/ui/src/freeipa/ipa.js b/install/ui/src/freeipa/ipa.js
index 758db1b00..ed16d7f7a 100644
--- a/install/ui/src/freeipa/ipa.js
+++ b/install/ui/src/freeipa/ipa.js
@@ -271,7 +271,7 @@ var IPA = function () {
                             var cn = that.whoami.data.krbcanonicalname;
                             if (cn) that.principal = cn[0];
                             if (!that.principal) {
-                                that.principal = that.whoami.data.krbprincipalname[0];
+                                that.principal = data.principal;
                             }
                         } else if (entity === 'idoverrideuser') {
                             that.principal = that.whoami.data.ipaoriginaluid[0];

if you'd added 'canonicalize=True' to the rpcserver.py code, then you should see -C flag in calls to kinit in the debug logs. This is what should turn root@IPA.DEMO into admin@IPA.DEMO. I suspect what you see is a result of reusing previous cookie with a previous ccache content.

Did you try to flush the cookies first?

@abbra, I've tried your fix, but I still see redirects.
In the logs I see that -C is added:

[Tue Aug 23 03:23:44.241273 2022] [wsgi:error] [pid 13062:tid 13413] [remote 10.40.192.193:64500] ipa: DEBUG: args=['/usr/bin/kinit', 'root', '-c', '/run/ipa/ccaches/kinit_13062', '-T', '/run/ipa/ccaches/armor_13062', '-C', '-E']

I'm doing this in an incognito mode, so no previous cookies are present.

Did you try to flush the cookies first?

Using incognito mode too, server installed in a fresh vm and I also see the -c in the logs.

@abbra, If you remove the fix, does your UI return to the infinite loop state?

I wonder if the order of the items in result.result.krbprincipalname from whoami command is deterministic or not.

I don't think we sort the attribute values and in LDAP the order of values returned for a multivalued attribute is not defined. So, yes, this might be the reason. I have some idea how to fix that in the whoami command instead -- we can actually put the canonical name first and aliases after it. But we definitely should use -C option as well.

Great, I agree.

@abiagion please try this patch

@abbra, error persists, var principal = data.result.principal; is always undefined. .principal is a sibling of data.result, if I change that your fix seems good to me.

@abiagion thank you, I fixed this part and submitted a PR: https://github.com/freeipa/freeipa/pull/6425

master:

• 2ae316d4308d05fcac118212299fdd33d135179c fix canonicalization issue in Web UI

ipa-4-9:

• 109cd579e3b089b7fad4c92bf25594eba1af8a21 fix canonicalization issue in Web UI

ipa-4-10:

• a0928fe164712303a7c24ee61500ac7326bd9e4a fix canonicalization issue in Web UI

ipa-4-6:

• 6536162634289509078700174b6f12962eadc4b5 fix canonicalization issue in Web UI

Issue linked to bug 2124547

Issue linked to RHEL 8 bug 2127035

master:

• 815f18396cadbe03c1f4a24c241e6c02e121554e ipatests: test for root using admin password in webUI

ipa-4-10:

• 0085757806e32c63bc1e1a2a2d762d4df2036f73 ipatests: test for root using admin password in webUI

ipa-4-9:

• 80b18b08e8cf3aaa9f75769e703c2aab569b599e ipatests: test for root using admin password in webUI

master:

• ba845b237fa4fd7a7d6d7f268f9ac890cac5ad65 ipatest: loginscreen: do not use hardcoded password

ipa-4-9:

• 2eca13e9660b3394fdd0a793142428dfe9d9ffa6 ipatest: loginscreen: do not use hardcoded password

ipa-4-10:

• 1f10aebcc5b3568a9992111e377c5caecc1e035f ipatest: loginscreen: do not use hardcoded password