[Freeipa-devel] ds-migrate feature enhancements

[Martin Kosek]

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

HTH,
Martin