Ticket was cloned from Red Hat Bugzilla (product Fedora): Bug 2056508
Description of problem: We have an infrastructure composed of ubuntu 18 and ubuntu 20 machines, with free ipa providing centralized authentication. On the client machines, we use plain kerberos to request the tickets. Due to AFS constraints, I need to issue kerberos tickets with long lifetimes (e.g. 15days). The settings on the server side were set to allow for those lifetimes (via the Kerberos Ticket Policy tab), and are explicitly set to more than 15d for all auth types. Ubuntu 18 has kerberos 1.16 installed and works as expected, when issued the command "kinit -l 15d" it can get a ticket with 15days lifetime. However, when doing the same in ubuntu 20, with kerberos 1.17, the ticket only has ~24h lifetime (the life varies, I suppose due to the jitter feature of ipa). I inspected the exchanged network packets and the only difference is that krb 1.17 uses SPAKE by default, so I ensured that hardened auth is enabled for all users (selecting both password and hardened in the web UI). However the erratic behavior persists. I can confirm that in krb 1.17 the request is correctly made, with the lifetime parameter set to the 15days. Version-Release number of selected component (if applicable): ipa server: 4.9.8 krb: 1.16 (working) and 1.17 (not working) How reproducible: Have a ipa realm and client machines with kerberos 1.17 (and 1.16 to test correct behavior). Steps to Reproduce: 1. Create a ipa domain, set the maximum ticket lifetimes to more than 1day. 2. Set the user auth methods to both password and hardened password. 3. Try to authenticate using kerberos 1.16 on the client (e.g. kinit -l 15d), and verify the ticket has the correct lifetime. 4. Try to authenticate using kerberos 1.17 on the client (e.g. kinit -l 15d), and verify the ticket has only ~24h of lifetime. Actual results: Using krb 1.17 (that has SPAKE) the ticket only has ~24h lifetime. Expected results: The ticket should have as lifetime the biggest value between what is requested via kinit and the policy setting on ipa server. Additional info: ipa user-show output: [root@idm01 ~]# ipa user-show testuser User login: testuser First name: Test Last name: Tester Home directory: /afs/example.com/home/testuser Login shell: /bin/bash Principal name: testuser@EXAMPLE.COM Principal alias: testuser@EXAMPLE.COM Email address: testuser@EXAMPLE.COM UID: 50034 GID: 100 User authentication types: hardened, password Account disabled: False Password: True Member of groups: users Kerberos keys available: True ipa krbtpolicy-show output: [root@idm01 ~]# ipa krbtpolicy-show Max life: 2678400 Max renew: 2678400 Hardened max life: 2678401 Hardened max renew: 2678401 I don't know what logs can be useful but I'm available to provide any if needed.
Metadata Update from @rcritten: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=2056508
Issue linked to bug 2056508
Created new ticket https://pagure.io/freeipa/issue/9132 to handle better centralization of Kerberos ticket policy. Currently there is hard max configured in the KDC configuration file that krbtpolicy cannot override.
https://github.com/freeipa/freeipa/pull/6223
I think this is going to require some refactoring either within the KDC itself or our backend.
The pre-auth pulls the principal and we go through ipadb_parse_ldap_entry() to get all the ticket policy information. At this point though we don't know what the auth indicators are so we can't really make a determinate of what max life/renew should be. This is called via krb5_db_get_principal in do_as_req() in the KDC code.
When we get to ipa_kdcpolicy_check_as() we have the indicator but only access to the indicator requested, so no way to fall back to the ticket default if there is no special policy set for that indicator.
Ideally we do the LDAP retrieval in ipa_kdcpolicy_check_as() to determine what the best policy is, but does it matter what we do in krb5_db_get_principal()? I don't know the KDC code at all to know whether simply returning 0 is valid and we'll clean it up later if the request continues.
master:
ipa-4-9:
Login to comment on this ticket.