This add replication setup through two new commands: ipa-replica-prepare
and ipa-replica-install. The procedure is to run ipa-replica-prepare
on an existing master. This will collect information about the realm
and the current master and create a file storing all of the information.
After copying that file to the new replica, ipa-replica-install is
run (with -r to create a read-only replica).
This version of the patch also includes fixes for the sasl mappings
on the replicas.
Remaining features:
- ssl for replication.
- automatic configuration of mesh topology for
master (or a simpler way to replicate multiple
masters.
- tool for view / configuring current replication.
This adds 2 new groups: activated and inactivated.
If you, or a group you are a member of, is in inactivated then you are too.
If you, or a group you are a member of, is in the activated group, then you
are too.
In a fight between activated and inactivated, activated wins.
The DNs for doing this matching is case and white space sensitive.
The goal is to never have to actually set nsAccountLock in a user directly
but move them between these groups.
We need to decide where in the CLI this will happen. Right it is split
between ipa-deluser and ipa-usermod. To inactivate groups for now just
add the group to inactivate or active.
- Does not require dirsrv access to stash file
- Finalize password history support
- Fix strict password length default in pwd_extop (fix install sctript too)
- fix plugin configuration
- Introduce 3 kind of password change: normal, admin, and ds manager
- normal require adherence to policies
- admin does not but password is immediately expired
- ds manager can just change the password any way he likes.
Initial code to read the Kerberos Master Key from the Directory
- Does not require dirsrv access to stash file
- Finalize password history support
- Fix strict password length default in pwd_extop (fix install sctript too)
- fix plugin configuration
- Introduce 3 kind of password change: normal, admin, and ds manager
- normal require adherence to policies
- admin does not but password is immediately expired
- ds manager can just change the password any way he likes.
Initial code to read the Kerberos Master Key from the Directory
This includes a default password policy
Custom fields are now read from LDAP. The format is a list of
dicts with keys: label, field, required.
The LDAP-based configuration now specifies:
ipaUserSearchFields: uid,givenName,sn,telephoneNumber,ou,title
ipaGroupSearchFields: cn,description
ipaSearchTimeLimit: 2
ipaSearchRecordsLimit: 0
ipaCustomFields:
ipaHomesRootDir: /home
ipaDefaultLoginShell: /bin/sh
ipaDefaultPrimaryGroup: ipausers
ipaMaxUsernameLength: 8
ipaPwdExpAdvNotify: 4
This could use some optimization.
to edit other users (the Edit link won't appear otherwise). Additional
delegation is need to grant permission to individual attributes.
Update the failed login page to indicate that it is a permission issue.
Don't allow access to policy at all for non-admins.
By default users can only edit themselves.
This patch uses the kerberos schema policy, this is the same policy used by
kadmin.
While this patch allows for krbPwdPolicy objects anywhere the kldap module
will make the kdc fail to provide tickets if the "krbPwdPolicyReference"
points to any object that is not a child of cn=<REALM>,cn=kerberos,dc=....
To let us set policies anywhere in the tree I enabled the code to actually
look at parent entries and the user entry itself and specify policies directly
on these objects by adding the krbPwdPolicy objectclass to them (I know its
structural but DS seem to allow multiple Structural classes on the same
entry).
The only side effect is that kadmin will not understand this, but we don't
want to use kadmin anyway as it does not understand way too many things about the
directory.
I've tested a few scenarios and all seem working as expected, but further
testing is welcome of course.
