For a newly added host, 'Trusted for delegation' checkbox is disabled in the web UI. Consequently it is impossible to modify this value using the web UI. Using CLI, it works fine.
Steps to reproduce: 1. Add a new host using the web UI (or ipa host-add) 2. Navigate to the details facet of the new host 3. 'Trusted for delegation' checkbox is disabled, making it impossible to modify this value
Expected result: 3. 'Trusted for delegation' checkbox is enabled
Additional information: Using the CLI, it is possible to modify the flag:
$ ipa host-mod web1.example.com --ok-as-delegate=1 -------------------------------- Modified host "web1.example.com" -------------------------------- Host name: web1.example.com Principal name: host/web1.example.com@IDM.LAB.ENG.BRQ.REDHAT.COM Trusted for delegation: True Password: False Keytab: False Managed by: web1.example.com
This may not be a Web UI issue - depends on interpretation.
The checkbox is editable in Web UI when server sends attribute level right for 'krbticketflags'. Currently, the right is send when:
I see three possible resolutions: 1. It's not a bug if presence of keytab should be required in order to set the flag. 2. It's ipalib bug if 'krbticketflags' entry should be always present in host/service 'attributelevelrights' 3. It's Web UI bug if Web UI should handle the case. The questions are: What's the correct behavior? Enable it if user has write right for 'objectclass' attibute (already used for cases when attributelevelrights entry is missing when some object class is not set yet)?
IMO it's no.1 or no.2.
Replying to [comment:1 pvoborni]:
This may not be a Web UI issue - depends on interpretation. The checkbox is editable in Web UI when server sends attribute level right for 'krbticketflags'. Currently, the right is send when: keytab is set 'krbticketflags' attribute was previously modified (ie. by CLI) I see three possible resolutions: 1. It's not a bug if presence of keytab should be required in order to set the flag.
The checkbox is editable in Web UI when server sends attribute level right for 'krbticketflags'. Currently, the right is send when: keytab is set 'krbticketflags' attribute was previously modified (ie. by CLI)
I see three possible resolutions: 1. It's not a bug if presence of keytab should be required in order to set the flag.
IMO in this case it's a bug in the CLI, because it's possible to modify the flag using the CLI even if keytab is not present. At any rate, the behaviour right now is inconsistent between web UI and CLI, so something needs to be fixed.
It's ipalib bug if 'krbticketflags' entry should be always present in host/service 'attributelevelrights' It's Web UI bug if Web UI should handle the case. The questions are: What's the correct behavior? Enable it if user has write right for 'objectclass' attibute (already used for cases when attributelevelrights entry is missing when some object class is not set yet)? IMO it's no.1 or no.2.
My previous statement about the keytab was wrong, sorry.
After enrolling new IPA client (keytab set), the checkbox is still not enabled(editable).
So case no.1 is no longer valid.
Milestone was changed by mistake, reverting.
master:
ipa-3-3:
Metadata Update from @akrivoka: - Issue assigned to pvoborni - Issue set to the milestone: FreeIPA 3.3.x - 2013/09 (bug fixing)
Login to comment on this ticket.