| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is done by creating a new attribute, memberindirect, to hold this
indirect membership.
The new function get_members() can return all members or just indirect or
direct. We are only using it to retrieve indirect members currently.
This also:
* Moves all member display attributes into baseldap.py to reduce duplication
* Adds netgroup nesting
* Use a unique object name in hbacsvc and hbacsvcgroup
ticket 296
|
| |
|
|
|
|
|
|
|
|
|
|
| |
To do a change right now you have to perform a setattr like:
ipa user-mod --setattr uid=newuser olduser
The RDN change is performed before the rest of the mods. If the RDN
change is the only change done then the EmptyModlist that update_entry()
throws is ignored.
ticket 323
|
| |
|
|
| |
ticket #158
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The attributes displayed is now dependant upon their definition in
a Param. This enhances that, giving some level of control over how
the result is displayed to the user.
This also fixes displaying group membership, including failures of
adding/removing entries.
All tests pass now though there is still one problem. We need to
return the dn as well. Once that is fixed we just need to comment
out all the dn entries in the tests and they should once again
pass.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
| |
Signed-off-by: Jason Gerard DeRose <jderose@redhat.com>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
Role groups will be part of the ACI system. It will let one create broad
categories of permissions. Things like: helpdesk, user admin, group admin,
whatever.
|
