On 11/24/2014 11:24 PM, Alan Evans wrote: > I am in the midst of preparing for a migration from OpenLDAP to FreeIPA. > ds-migrate wasn't going to fill all of my needs so I thought I would use it > for most and then make up some LDIF's and massage them to do the last bit > of migration. > > I have instead decided to extend ds-migrate and I think that my features > might be of use to others so I would like to contribute them.
Great idea! :-) IMO, enhancing FreeIPA migration capability and making it more even more pleasant experience for user users is a good goal. > Before I get > too for I wanted to get some input from the community. > > Here are MY original goals: > * Migrate ssh public keys > The openssh-lpk schema is used in my tree so objectClass: ldapPublicKey > attribute: sshPublicKey > * Migrate disabled accounts as disabled > We 'disable' usere by setting their shadowExpire to a date in the past > and setting their shell to /bin/false > > I realized that the ssh-public key problem is more generally an attribute > mapping problem and dealing with disabled users could be more generalized > too. > > Here are instead the new features I would provide. > > * Attribute mapping > Feature should check the new syntax exists and is the same as the old > syntax (perhaps further check for compatible syntax) > --user-attribute-map=oldAttribute=newAttribute > --group-attribute-map=foo=bar > Should I drop user/group and just make it --attribute-map and apply it to > both? > Should certain attributes be mapped by default, i.e. > sshPublicKey=ipaSSHPubKey (this means we also need to ignore the > objectClass ldapPublicKey by default) Maybe make a separate switch > --with-ssh-keys that automatically adds a map and an ignore? If the mapping sshPublicKey -> ipaSSHPubKey is clear, I would do it by default and maybe add a switch to skip these advanced migrations. Just make sure the expected format matches (ipa requires all 3 pieces of the public key, not just the blob) I think it would be very useful to combine user attribute mapping with the ideas from https://fedorahosted.org/freeipa/ticket/3709 i.e. filling attribute with values from original entry or a default. This may lead to following syntax: --user-attribute-default "sn=notdefined" --user-attribute-default "description=User with cn $cn" which would only use the pattern if attribute is not defined in original entry and --user-attribute-map "sn=$cn" which would fill overwrite the attribute even if it was defined in the original entry. > > * Handling disabled users > 1. How to identify disabled users? > a. shadowExpire < now() > --use-disable-shadow-expire How would you like to disable users then? With nsAccountLock attribute? Wouldn't it be better to instead map shadowExpire to krbPrincipalExpiration attribute which should have sematically the same meaning? > b. loginShell is one of configurable shells > --use-disable-login-shell > --disabled-shell=/bin/false --disabled-shell=/sbin/nologin (these Is this really a general mechanism? I think Kerberos principal expiration is the way to go: # ipa user-mod fbar --principal-expiration 20140101000000Z # ssh fbar@`hostname` f...@vm-067.idm.lab.bos.redhat.com's password: Permission denied, please try again. # tail /var/log/krb5kdc.log ... Nov 26 04:56:51 vm-067.idm.lab.bos.redhat.com krb5kdc[19615](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.16.78.67: CLIENT EXPIRED: f...@idm.lab.bos.redhat.com for krbtgt/idm.lab.bos.redhat....@idm.lab.bos.redhat.com, Client's entry in database has expired It is respected by Kerberos authentication and SSSD logins, at minimum. > two would be the defaults) > c. nsAccountLocked (though that would be straight copied by the > migrator anyway +1 for copying. > d. From Open DJ the attribute ds-pwp-account-disabled can be used to > identify disabled users > (are there others?) > 2. What do do with disabled users (in my case migrate and disable) > a. Migrate them and don't touch nsAccountLocked > b. Migrate them and set nsAccountLocked = true > --disable-users > c. Do not migrate them > --skip-disabled-users > d. Which is the default? Migrate and disable? If so which are the > default methods for identifying them? All methods? I may be missing something, but to me following would make sense: - properly migrate and fill krbPrincipalExpiration and nsACcountLock attributes - optionally implement --skip-disabled-users. Though it may be challenging to implement the "is_user_disabled" function right so that it works on all sort of DS schemes. > So is there anything I'm missing? Any suggestions on the switches? I'm not > entirely sure I like them the way they are. > > I have code to cover about 60% of the above already. The user-attr-map > feature is working and the --disabled-users and disabled-shells options are > working. > > Regards, > -Alan HTH, Martin _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel