mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2025-01-26 16:16:31 -06:00
2ae316d430
When Kerberos principal alias is used to login to a Web UI, we end up with a request that is authenticated by a ticket issued in the alias name but metadata processed for the canonical user name. This confuses RPC layer of Web UI code and causes infinite loop to reload the page. Fix it by doing two things: - force use of canonicalization of an enterprise principal on server side, not just specifying that the principal is an enterprise one; - recognize that a principal in the whoami()-returned object can have aliases and the principal returned by the server in the JSON response may be one of those aliases. Fixes: https://pagure.io/freeipa/issue/9226 Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com> Reviewed-By: Armando Neto <abiagion@redhat.com> |
||
|---|---|---|
| .. | ||
| certmonger | ||
| custodia | ||
| html | ||
| migration | ||
| oddjob | ||
| restart_scripts | ||
| share | ||
| tools | ||
| ui | ||
| updates | ||
| wsgi | ||
| Makefile.am | ||
| README.schema | ||
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.