Now that we have our own database we can properly enforce stricter constraints
on how the db can be changed. Stop shipping our own kpasswd daemon and instead
use the regular kadmin daemon.
Although the proper values for booleans from LDAP should be only uppercase,
389ds does allow wrong cased values without complaining. And we still have some
places where the wrong case is used.
Avoid getting frustrating errors when reading these values out.
Prevent the ipa-pwd-extop plugin from re-generating keys when kadimn is storing
a new set of keys. Only generate the userPassword and sambaXXPassword hashes.
Also avoid checking policies in this case and if history is provided avoid
regenerating the passwordHistory too.
Setting 0 will work as MIT KDCs assume the current master key when that is
found. But it is a legacy compatibility mode and we should instead set the
proper mkvno number on keys so changeing master key becomes possible w/o
having to do a dump reload and stopping the service. This is especially
important in replicated environments.
This can cause problems if a host is enrolled, unenrolled and a password
set. The password will be marked as expired like all new passwords are.
https://fedorahosted.org/freeipa/ticket/1526
We have no visibility into whether an entry has a keytab or not so
krbLastPwdChange is used as a rough guide.
If this value exists during enrollment then it fails because the host
is considered already joined. This was getting set when a OTP was
added to a host that had already been enrolled (e.g. you enroll a host,
unenroll it, set a OTP, then try to re-enroll). The second enrollment
was failing because the enrollment plugin thought it was still
enrolled becaused krbLastPwdChange was set.
https://fedorahosted.org/freeipa/ticket/1357
https://fedorahosted.org/freeipa/ticket/1382
crash in winsync if replaying a MOD and user does not exist in AD
If the AD entry is deleted before the deletion can be synced back to IPA,
and in the meantime an operation is performed on the corresponding
entry in IPA that should be synced to AD, winsync attempts to get the
AD entry and it is empty. This just means the operation will not go
through, and the entry will be deleted when the sync from AD happens.
The IPA winsync plugin needs to handle the case when the ad_entry
is NULL.
https://fedorahosted.org/freeipa/ticket/1379
winsync enables disabled users in AD when the AD entry changes
This was likely broken when ipa switched from using CoS/groups for account
inactivation to using nsAccountLock directly. The code that handled the
account sync in the from AD direction was broken, but was never found before
now because it had not been used. The fix is to correctly set or remove
nsAccountLock.
We need to set uidNumber and gidNumber to the magic values so that DNA can
assign appropriate Ids, otherwise the synchronization of users from AD will
fail with an error about posixAccount requiring a missing (uidNumber)
attribute.
Fixes: https://fedorahosted.org/freeipa/ticket/1020
When the UUID plug-in generates a value that is used in the RDN
of the entry being added, the old DN is free'd and replaced with
the new DN. The problem is that the operation in the pblock holds
a pointer to the old DN address. This can cause other plug-ins to
reference garbage, leading to incorrect results or crashes. This
was causing the attribute uniqueness plug-in to not work correctly,
resulting in duplicate netgroup entries.
The fix is to have the UUID plug-in reset the target DN after
changing the DN of the entry to be added.
ticket 963
Apparently we forgot to check OID consistency between the schema and the
extensions, and we got duplicates.
Technically the schema was done later but it is easier to change the extensions
OIDs than to change the schema of current beta2/rc1 installations.
The only side effect is that older ipa-getkeytab and ipa-join binaries will
fail. So all the admin/client tools must be upgraded at the same time as well
as all the masters (otherwise some will show/accept the new OID while others
won't).
Fixes: https://fedorahosted.org/freeipa/ticket/976
The situation is if during installation /etc/krb5.conf either doesn't
exist or configures no realms then 389-ds won't start up at all, causing
the installation to fail. This will let the server start up in a degraded
mode.
Also need to make the sub_dict in ldapupdate.py handle no realm otherwise
the installation will abort enabling the compat plugin.
ticket 606
The 389-ds replication plugin may not be installed on all platforms
and our replication version plugin will cause 389-ds to not start
if it is loaded and the replication plugin is not. So disable by
default.
When a replica is prepared we check for the replication plugin.
If it exists we will enable the replication version plugin.
Likewise on installation of a replica we check for existence of
the repliation plugin and if it is there then we enable the version
plugin before replication begins.
ticket 918
