#232 the setkeytab extended operation may allow users to set a password ignoring password policies
Closed: wontfix 3 years ago by pcech. Opened 13 years ago by rcritten.

https://bugzilla.redhat.com/show_bug.cgi?id=459037

Simo things this should be changed to:

tell the server: this is the password (or please generate a random one) and this is the list of keytypes I want to use, please give me back a keytab


This has been effectively fixed with the new getkeytab feature.
We should close this now, although the setkeytab feature is still active for backwards compatibility purposes we should probably open a new ticket about making it possible to disable the use of the setkeytab operation selectively (forbidding user's from using it first and then disabling it completely by default in a future realese).

Moving back to triage to find out when it is a good time to do this.

System: Manage Host Keytab permission still forces user to use the old keytab API:

# ipa permission-show "System: Manage Host Keytab"
  Permission name: System: Manage Host Keytab
  Granted rights: write
  Effective attributes: krblastpwdchange, krbprincipalkey
  Default attributes: krbprincipalkey, krblastpwdchange
  Bind rule type: permission
  Subtree: cn=computers,cn=accounts,dc=rhel72
  Type: host
  Granted to Privilege: Host Enrollment, Host Administrators, fbar
  Indirect Member of roles: fbar, IT Specialist

# ipa user-show fbar --all --raw
  dn: uid=fbar,cn=users,cn=accounts,dc=rhel72
...
  memberof: cn=fbar,cn=roles,cn=accounts,dc=rhel72
  memberof: cn=ipausers,cn=groups,cn=accounts,dc=rhel72
  memberofindirect: cn=fbar,cn=privileges,cn=pbac,dc=rhel72
  memberofindirect: cn=System: Manage Host Keytab,cn=permissions,cn=pbac,dc=rhel72
...
# kinit fbar
# ipa-getkeytab -s `hostname` -k /tmp/fbar.keytab -p host/fbar.example.com
Failed to parse result: Insufficient access rights

Retrying with pre-4.0 keytab retrieval method...
Keytab successfully retrieved and stored in: /tmp/fbar.keytab

More details on freeipa-users thread.

I am now not sure if old permission can be just updated - as then the ipa-getkeytab on older clients or older servers which do not support the new method would not work. We may need to add a separate permission for the new method...

Replying to [comment:6 mkosek]:

I am now not sure if old permission can be just updated - as then the ipa-getkeytab on older clients or older servers which do not support the new method would not work. We may need to add a separate permission for the new method...

The permission can be updated to use both methods, so that old servers will still be able to allow access, but new servers will start using the getkeytab method.
After all the setting to disable setkeytab will also be ineffective on old servers that do not understand the old method, so this is a process I want to start early to get all the components in place to be able to switch off all bits once we declare older servers as not supported anymore. (perhaps in some future domain level change).

Metadata Update from @rcritten:
- Issue assigned to simo
- Issue set to the milestone: FreeIPA 4.5 backlog

7 years ago

There weren't any requests for that functionality, so we are closing this.

Metadata Update from @pcech:
- Issue close_status updated to: wontfix
- Issue set to the milestone: None (was: FreeIPA 4.5 backlog)
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata