I saw this with a host where I joined a host, obtained a host
principal, kinited to that principal, then deleted the host from the
IPA server. The ticket was still valid so Apache let it through but
it failed to bind to LDAP.
Because ipa-join calls ipa-getkeytab I'd like to keep the return values in
sync. ipa-join returns the value returned by ipa-getkeytab so in order to
tell what failed the return values need to mean the same things and not
overlap.
Installing a CA that is signed by another CA is a 2-step process. The first
step is to generate a CSR for the CA and the second step is to install
the certificate issued by the external CA. To avoid asking questions
over and over (and potentially getting different answers) the answers
are cached.
If an exception is not handled here then the context isn't destroyed
leaving at least an LDAP connection dangling. This means the next time
this thread/process tries to handle a connection it will fail because
a context already exists.
This introduces 2 new params: --setattr and --addattr
Both take a name/value pair, ala:
ipa user-mod --setattr=postalcode=20601 jsmith
--setattr replaces or sets the current attribute to the value
--addattr adds the value to an attribute (or sets a new attribute)
OptionsParser allows multiple versions of this, so you can have multiple
setattr and addattr, either for the same attribute or for different
attributes.
ipa user-mod --addattr=postalcode=20601 --addattr=postalcode=30330 jsmith
Values are silent dropped if either of these on an existing param:
ipa user-mod --setattr=givenname=Jerry jsmith
Is a no-op.
This also removes the Index option of /ipa-assets as well as the
deprecated IPADebug option.
No need to build or install ipa_webgui anymore. Leaving in the code
for reference purposes for now.
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
There was much back and forth and gnashing of teeth about what the
version should actually be in these pre-releases. We decided it isn't
2.0-ish enough so went with 1.9.0, 1.9.1, etc until we're ready to
declare 2.0.0.
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.
We were seeing a rare deadlock of DS when creating the memberOf task because
one thread was adding memberOf in a postop while another was trying to
create an index and this was causing a PRLock deadlock.
We have to replace 05rfc2247.ldif because it contains some conflicting
attributes with DNS in some older versions of 389-DS/RHDS. This fails on
some newer versions of 389-DS/RHDS so this lets it continue installing
if the new file is not needed.
