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>
Second part of adding support to manage IPA as a user from a trusted
Active Directory forest.
Treat user ID overrides as members of groups and roles.
For example, adding an Active Directory user ID override as a member of
'admins' group would make it equivalent to built-in FreeIPA 'admin'
user.
We already support self-service operations by Active Directory users if
their user ID override does exist. When Active Directory user
authenticates with GSSAPI against the FreeIPA LDAP server, its Kerberos
principal is automatically mapped to the user's ID override in the
Default Trust View. LDAP server's access control plugin uses membership
information of the corresponding LDAP entry to decide how access can be
allowed.
With the change, users from trusted Active Directory forests can
manage FreeIPA resources if the groups are part of appropriate roles or
their ID overrides are members of the roles themselves.
Fixes: https://pagure.io/freeipa/issue/7255
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
When using `ipa -e in_server=True console` on IPA master, the whole IPA
framework is loaded in the same process ('ipa console'). The context
defined for this configuration is 'cli'. Some trust-related operations
need to load Samba bindings and guard itself to 'lite' and 'server'
contexts.
Upon reviewing these cases I came to conclusion that these guards are
unnecessary. It is enough to require that the context is in the server
code.
Allow these operations if we are operating in server mode. This allows
to debug trust-related issued directly in the IPA console on IPA trust
controllers.
Signed-of-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Allow services to be members of the groups, like users and other groups
can already be.
This is required for use cases where such services aren't associated
with a particular host (and thus, the host object cannot be used to
retrieve the keytabs) but represent purely client Kerberos principals to
use in a dynamically generated environment such as Kubernetes.
Fixes: https://pagure.io/freeipa/issue/7513
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
When a user with sufficient permissions creates a group using ipa
group-add and then deletes it again with group-del ipa gives an
Insufficient access error, but still deletes the group.
This is due to a need to remove an associaed password policy for the
group. However, a password policy might be inaccessible to the user
(created by a more powerful admin) and there is no way to check that it
exists with current privileges other than trying to remove it.
Seeing a Python exceptions in the Apache log without explanation is
confusing to many users, so add a warning message that explains what
happens here.
Fixes: https://pagure.io/freeipa/issue/6884
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Turn calls "handle_not_found()" into "raise handle_not_found()" to
indicate control flow chance. It makes the code easier to understand,
the control flow more obvious and helps static analyzers.
It's OK to raise here because handle_not_found() always raises an
exception.
https://pagure.io/freeipa/issue/7344
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
The rename operation on *_mod commands was only allowed when
the primary key of an entry was also its RDN. With these changes,
it should be possible to rename the rest of the entries as well.
An attribute to the base LDAPObject was added to whitelist the
objects we want to allow to be renamed. It replaced an old
attribute rdn_is_primary_key which was used for the very same
purpose but the name was confusing because it was not set
correctly for certain objects.
https://pagure.io/freeipa/issue/2466https://pagure.io/freeipa/issue/6784
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
Reviewed-By: Martin Basti <mbasti@redhat.com>
This commit removes unused variables or rename variables as "expected to
be unused" by using "_" prefix.
This covers only cases where fix was easy or only one unused variable
was in a module
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Reviewed-By: Stanislav Laznicka <slaznick@redhat.com>
Use only object params and params defined in has_output_params as output
params. This removes unnecessary duplication of params defined both in
object plugins and as command arguments.
This requires all command output params to be properly defined in either
the object plugins or the command's has_output_params. Fix the plugins
where this wasn't true.
https://fedorahosted.org/freeipa/ticket/4739
Reviewed-By: David Kupka <dkupka@redhat.com>
Christian Heimes
Alexander Bokovoy
Stanislav Laznicka
Petr Vobornik
Martin Babinsky
Martin Basti
Jan Barta
Jan Cholasta