[Freeipa-devel] ds-migrate feature enhancements

Thu Dec 4 11:59:58 UTC 2014

On 11/26/2014 11:52 AM, Martin Kosek wrote:
> 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`
> fbar at 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:
> fbar at IDM.LAB.BOS.REDHAT.COM for
> krbtgt/IDM.LAB.BOS.REDHAT.COM at 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

Hello Alan,

Are there any updates in this noble effort? Are you stuck? Can I or the team
help you in any way?

Thanks,
Martin