mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2025-02-25 18:55:28 -06:00
4911a3f055
It was found that if an account was created with a name corresponding to an account local to a system, such as 'root', was created via IPA, such account could access any enrolled machine with that account, and the local system privileges. This also bypass the absence of explicit HBAC rules. root principal alias ------------------- The principal "root@REALM" is now a Kerberos principal alias for "admin". This prevent user with "User Administrator" role or "System: Add User" privilege to create an account with "root" principal name. Modified user permissions ------------------------- Several user permissions no longer apply to admin users and filter on posixaccount object class. This prevents user managers from modifying admin acounts. - System: Manage User Certificates - System: Manage User Principals - System: Manage User SSH Public Keys - System: Modify Users - System: Remove Users - System: Unlock user ``System: Unlock User`` is restricted because the permission also allow a user manager to lock an admin account. ``System: Modify Users`` is restricted to prevent user managers from changing login shell or notification channels (mail, mobile) of admin accounts. New user permission ------------------- - System: Change Admin User password The new permission allows manipulation of admin user password fields. By default only the ``PassSync Service`` privilege is allowed to modify admin user password fields. Modified group permissions -------------------------- Group permissions are now restricted as well. Group admins can no longer modify the admins group and are limited to groups with object class ``ipausergroup``. - System: Modify Groups - System: Remove Groups The permission ``System: Modify Group Membership`` was already limited. Notes ----- Admin users are mostly unaffected by the new restrictions, except for the fact that admins can no longer change krbPrincipalAlias of another admin or manipulate password fields directly. Commands like ``ipa passwd otheradmin`` still work, though. The ACI ``Admin can manage any entry`` allows admins to modify other entries and most attributes. Managed permissions don't install ``obj.permission_filter_objectclasses`` when ``ipapermtargetfilter`` is set. Group and user objects now have a ``permission_filter_objectclasses_string`` attribute that is used by new target filters. Misc changes ------------ Also add new exception AlreadyContainsValueError. BaseLDAPAddAttribute was raising a generic base class for LDAP execution errors. Fixes: https://pagure.io/freeipa/issue/8326 Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1810160 Signed-off-by: Christian Heimes <cheimes@redhat.com> Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com> Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
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.