A group membership manager is a user or a group that can add members to
a group or remove members from a group or host group.
Fixes: https://pagure.io/freeipa/issue/8114
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
This new extended operation allow to create new keys or retrieve
existing ones. The new set of keys is returned as a ASN.1 structure
similar to the one that is passed in by the 'set keytab' extended
operation.
Access to the operation is regulated through a new special ACI that
allows 'retrieval' only if the user has access to an attribute named
ipaProtectedOperation postfixed by the subtypes 'read_keys' and
'write_keys' to distinguish between creation and retrieval operation.
For example for allowing retrieval by a specific user the following ACI
is set on cn=accounts:
(targetattr="ipaProtectedOperation;read_keys") ...
... userattr=ipaAllowedToPerform;read_keys#USERDN)
This ACI matches only if the service object hosts a new attribute named
ipaAllowedToPerform that holds the DN of the user attempting the
operation.
Resolves:
https://fedorahosted.org/freeipa/ticket/3859
Reviewed-By: Nathaniel McCallum <npmccallum@redhat.com>
This also constitutes a rethinking of the token ACIs after the introduction
of SELFDN support.
Admins, as before, have full access to all token permissions.
Normal users have read/search/compare access to all of the non-secret data
for tokens assigned to them, whether managed by them or not. Users can add
tokens if, and only if, they will also manage this token.
Managers can also read/search/compare tokens they manage. Additionally,
they can write non-secret data to their managed tokens and delete them.
When a normal user self-creates a token (the default behavior), then
managedBy is automatically set. When an admin creates a token for another
user (or no owner is assigned at all), then managed by is not set. In this
second case, the token is effectively read-only for the assigned owner.
This behavior enables two important other behaviors. First, an admin can
create a hardware token and assign it to the user as a read-only token.
Second, when the user is deleted, only his self-managed tokens are deleted.
All other (read-only) tokens are instead orphaned. This permits the same
token object to be reasigned to another user without loss of any counter
data.
https://fedorahosted.org/freeipa/ticket/4228https://fedorahosted.org/freeipa/ticket/4259
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
Also remove
- the deny ACIs that implemented exceptions to it:
- no anonymous access to roles
- no anonymous access to member information
- no anonymous access to hbac
- no anonymous access to sudo (2×)
- its updater plugin
Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
Reviewed-By: Martin Kosek <mkosek@redhat.com>
These attributes are removed from the blacklist, which means
high-level admins can now modify them:
- krbPrincipalAliases
- krbPrincipalType
- krbPwdPolicyReference
- krbTicketPolicyReference
- krbUPEnabled
- serverHostName
The intention is to only blacklist password attributes and attributes
that are managed by DS plugins.
Also, move the admin ACIs from ldif and trusts.update to aci.update.
Reviewed-By: Martin Kosek <mkosek@redhat.com>
Since we're exposing the krbPrincipalExpiration attribute for direct
editing in the CLI, remove it from the list of attributes that
admin cannot edit by default.
Part of: https://fedorahosted.org/freeipa/ticket/3306
These ACI were needed when FreeIPA had a custom ipa_kpasswd daemon,
now that a standard kadmin is used, ACIs are not needed anymore as
kadmin uses the same driver as the KDC.
The ACIs is not removed on upgrades to avoid breaking older
replicas which may still use FreeIPA version with the ipa_kpasswd
daemon.
https://fedorahosted.org/freeipa/ticket/3987
Update anonymous access ACI so that no users besides Trust Admins
users can read AD Trust key attributes (ipaNTTrustAuthOutgoing,
ipaNTTrustAuthIncoming). The change is applied both for updated
IPA servers and new installations.
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
ipaNTHash contains security sensitive information, it should be hidden just
like other password attributes. As a part of preparation for ticket #2511,
the ACI allowing global access is also updated to hide DNS zones.
https://fedorahosted.org/freeipa/ticket/2856
We need an indicator to see if a keytab has been set on host and
service entries. We also need a way to know if a one-time password is
set on a host.
This adds an ACI that grants search on userPassword and
krbPrincipalKey so we can do an existence search on them. This way
we can tell if the attribute is set and create a fake attribute
accordingly.
When a userPassword is set on a host a keytab is generated against
that password so we always set has_keytab to False if a password
exists. This is fine because when keytab gets generated for the
host the password is removed (hence one-time).
This adds has_keytab/has_password to the user, host and service plugins.
ticket https://fedorahosted.org/freeipa/ticket/1538
Adds a plugin, entitle, to register to the entitlement server, consume
entitlements and to count and track them. It is also possible to
import an entitlement certificate (if for example the remote entitlement
server is unaviailable).
This uses the candlepin server from https://fedorahosted.org/candlepin/wiki
for entitlements.
Add a cron job to validate the entitlement status and syslog the results.
tickets 28, 79, 278
This patch adds command ipa user-unlock and some LDAP modifications
which are required by Kerberos for unlocking to work.
Ticket:
https://fedorahosted.org/freeipa/ticket/344
When more than one plugin produce ACIs, they share common namespace
of ACI name. This may lead to name collisions between the ACIs
from different plugins.
This patch introduces a mandatory "prefix" attribute for non-find
ACI operations which allow plugins to use their own prefixes
(i.e. namespaces) which is then used when a name of the ACI is
generated.
Permission, Delegation and Selfservice plugins has been updated
to use their own prefixes thus avoiding name collisions by using
their own namespaces. Default ACIs in LDIFs has been updated to
follow this new policy.
Permission plugin now uses its CN (=primary key) instead of
description in ACI names as Description may not be unique.
This change requires an IPA server reinstall since the default ACI
set has been changed.
https://fedorahosted.org/freeipa/ticket/764
Prevents an unauthenticated user from accessing HBAC and role
information as well as memberof which could disclose roles,
memberships in HBAC, etc.
ticket 811
This has been completely abandoned since ipa v1 and is not built by default.
Instead of carrying dead weight, let's remove it for now.
Fixes: https://fedorahosted.org/freeipa/ticket/761
We keep LDAP attributes lower-case elsewhere in the API we should do the
same with all access controls.
There were two ACIs pointing at the manage_host_keytab permission. This
isn't allowed in general and we have decided separately to not clear out
enrolledBy when a host is unenrolled so dropping it is the obvious thing
to do.
ticket 597
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
Disable any services when its host is disabled.
This also adds displaying the certificate attributes (subject, etc)
a bit more universal and centralized in a single function.
ticket 297
serverHostName because this is tied to the FQDN so should only be changed
on a host rename (which we don't do).
memberOf because the plugin should do this. Directly manging this attribute
would be pretty dangerous and confusing.
Also remove a redundant aci granting the admins group write access to
users and groups. They have it with through the "admins can modify any
entry" aci.
tickets 300, 304
Unenrollment means that the host keytab is disabled on the server making
it possible to re-install on the client. This host principal is how we
distinguish an enrolled vs an unenrolled client machine on the server.
I added a --unroll option to ipa-join that binds using the host credentials
and disables its own keytab.
I fixed a couple of other unrelated problems in ipa-join at the same time.
I also documented all the possible return values of ipa-getkeytab and
ipa-join. There is so much overlap because ipa-join calls ipa-getkeytab
and it returns whatever value ipa-getkeytab returned on failure.
ticket 242
Using the host service principal one should be able to retrieve a keytab
for other services for the host using ipa-getkeytab. This required a number
of changes:
- allow hosts in the service's managedby to write krbPrincipalKey
- automatically add the host to managedby when a service is created
- fix ipa-getkeytab to return the entire prinicpal and not just the
first data element. It was returning "host" from the service tgt
and not host/ipa.example.com
- fix the display of the managedby attribute in the service plugin
This led to a number of changes in the service unit tests. I took the
opportunity to switch to the Declarative scheme and tripled the number
of tests we were doing. This shed some light on a few bugs in the plugin:
- if a service had a bad usercertificate it was impossible to delete the
service. I made it a bit more flexible.
- I added a summary for the mod and find commands
- has_keytab wasn't being set in the find output
ticket 68
We use kadmin.local to bootstrap the creation of the kerberos principals
for the IPA server machine: host, HTTP and ldap. This works fine and has
the side-effect of protecting the services from modification by an
admin (which would likely break the server).
Unfortunately this also means that the services can't be managed by useful
utilities such as certmonger. So we have to create them as "real" services
instead.
Using the client IP address was a rather poor mechanism for controlling
who could request certificates for whom. Instead the client machine will
bind using the host service principal and request the certificate.
In order to do this:
* the service will need to exist
* the machine needs to be in the certadmin rolegroup
* the host needs to be in the managedBy attribute of the service
It might look something like:
admin
ipa host-add client.example.com --password=secret123
ipa service-add HTTP/client.example.com
ipa service-add-host --hosts=client.example.com HTTP/client.example.com
ipa rolegroup-add-member --hosts=client.example.com certadmin
client
ipa-client-install
ipa-join -w secret123
kinit -kt /etc/krb5.keytab host/client.example.com
ipa -d cert-request file://web.csr --principal=HTTP/client.example.com
