The 'Host Administrators' privilege was missing two permissions
('Retrieve Certificates from the CA' and 'Revoke Certificate'), causing
the inability to remove a host with a certificate.
https://fedorahosted.org/freeipa/ticket/3585
Sudo commands created in the past have the sudocmd in their RDN, while
the new case-sensitive ones have ipaUniqueID. In order for permissions
to apply to both of these, use a targetfilter for objectclass=ipasudocmd
instead of sudocmd=* in the target.
Certificate renewal can be done only one one CA as the certificates need
to be shared amongst them. certmonger has been trained to communicate
directly with dogtag to perform the renewals. The initial CA installation
is the defacto certificate renewal master.
A copy of the certificate is stored in the IPA LDAP tree in
cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX, the rdn being the nickname of the
certificate, when a certificate is renewed. Only the most current
certificate is stored. It is valid to have no certificates there, it means
that no renewals have taken place.
The clones are configured with a new certmonger CA type that polls this
location in the IPA tree looking for an updated certificate. If one is
not found then certmonger is put into the CA_WORKING state and will poll
every 8 hours until an updated certificate is available.
The RA agent certificate, ipaCert in /etc/httpd/alias, is a special case.
When this certificate is updated we also need to update its entry in
the dogtag tree, adding the updated certificate and telling dogtag which
certificate to use. This is the certificate that lets IPA issue
certificates.
On upgrades we check to see if the certificate tracking is already in
place. If not then we need to determine if this is the master that will
do the renewals or not. This decision is made based on whether it was
the first master installed. It is concievable that this master is no
longer available meaning that none are actually tracking renewal. We
will need to document this.
https://fedorahosted.org/freeipa/ticket/2803
Add missing permissions that can be used to delegate write access
to existing automount maps or keys.
Since automount key RDN has been changed in the past from "automountkey"
to "description" and there can be LDAP entries with both RDNs,
structure of relevant ACI need to be changed to different scheme. Now,
it rather targets a DN of parent automount map object and uses
targetfilter to limit the target to automount key objects only.
https://fedorahosted.org/freeipa/ticket/2687
The permission "Modify Group membership" is used to delegate group
management responsibilities. We don't want that to include managing
the admins group.
https://fedorahosted.org/freeipa/ticket/2416
This will allow one to define what SELinux context a given user gets
on a given machine. A rule can contain a set of users and hosts or it
can point to an existing HBAC rule that defines them.
https://fedorahosted.org/freeipa/ticket/755
This resolves two issues:
1. The DNS acis lacked a prefix so weren't tied to permissions
2. The permissions were added before the privileges so the member
values weren't calculated properly
For updates we need to add in the members and recalculate memberof via
a DS task.
https://fedorahosted.org/freeipa/ticket/1898
This fixes a regression.
We don't need to allow enrolledBy to be modified because it gets
written in the ipa_enrollment plugin which does internal operations
so bypasses acis.
https://fedorahosted.org/freeipa/ticket/302
If the host has a one-time password but krbPrincipalName wasn't set yet
then the enrollment would fail because writing the principal is not
allowed. This creates an ACI that only lets it be written if it is not
already set.
ticket 1075
Created some default roles as examples. In doing so I realized that
we were completely missing default rules for HBAC, SUDO and password
policy so I added those as well.
I ran into a problem when the updater has a default record and an add
at the same time, it should handle it better now.
ticket 585
The new model is based on permssions, privileges and roles.
Most importantly it corrects the reverse membership that caused problems
in the previous implementation. You add permission to privileges and
privileges to roles, not the other way around (even though it works that
way behind the scenes).
A permission object is a combination of a simple group and an aci.
The linkage between the aci and the permission is the description of
the permission. This shows as the name/description of the aci.
ldap:///self and groups granting groups (v1-style) are not supported by
this model (it will be provided separately).
This makes the aci plugin internal only.
ticket 445
The list of attributes that a host bound as itself could write was
overly broad.
A host can now only update its description, information about itself
such as OS release, etc, its certificate, password and keytab.
ticket 416
To do this we need to break the link manually on both sides, the user and
the group.
We also have to verify in advance that the user performing this is allowed
to do both. Otherwise the user could be decoupled but not the group
leaving it in a quasi broken state that only ldapmodify could fix.
ticket 75
The entitlement entries themselves will be rather simple, consisting
of the objectClasses ipaObject and pkiUser. We will just store
userCertificate in it. The DN will contain the UUID of the entitlement.
ticket #27
This creates a new role, replicaadmin, so a non-DM user can do
limited management of replication agreements.
Note that with cn=config if an unauthorized user performs a search
an error is not returned, no entries are returned. This makes it
difficult to determine if there are simply no replication agreements or
we aren't allowed to see them. Once the ipaldap.py module gets
replaced by ldap2 we can use Get Effective Rights to easily tell the
difference.
We want to only allow a machine to request a certificate for itself, not for
other machines. I've added a new taksgroup which will allow this.
The requesting IP is resolved and compared to the subject of the CSR to
determine if they are the same host. The same is done with the service
principal. Subject alt names are not queried yet.
This does not yet grant machines actual permission to request certificates
yet, that is still limited to the taskgroup request_certs.
This will create a host service principal and may create a host entry (for
admins). A keytab will be generated, by default in /etc/krb5.keytab
If no kerberos credentails are available then enrollment over LDAPS is used
if a password is provided.
This change requires that openldap be used as our C LDAP client. It is much
easier to do SSL using openldap than mozldap (no certdb required). Otherwise
we'd have to write a slew of extra code to create a temporary cert database,
import the CA cert, ...
There are some operations, like those for the certificate system, that
don't need to write to the directory server. So instead we have an entry
that we test against to determine whether the operation is allowed or not.
This is done by attempting a write on the entry. If it would succeed then
permission is granted. If not then denied. The write we attempt is actually
invalid so the write itself will fail but the attempt will fail first if
access is not permitted, so we can distinguish between the two without
polluting the entry.
Also moves delagation layout installation in dsinstance.
This is needed to allow us to set default membership in
other modules like bindinstance.
Signed-off-by: Martin Nagy <mnagy@redhat.com>
This adds:
group administration
host administration
host group administration
delegation administration
service administration
automount administration
netgroup administration
