[Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page.

[Dmitri Pal]

Rob Crittenden wrote:
> Pavel Zuna wrote:
>> Rob Crittenden wrote:
>>> Pavel Zuna wrote:
>>>> Example output of migration plugin:
>>>>
>>>> I have a DS server setup on a VM at 192.168.122.4 and I made a few
>>>> tweaks to show how errors are reported.
>>>>
>>>> # ipa migrate-ds ldap://192.168.122.4:389
>>>> Password:
>>>> Enter password again to verify:
>>>> -----------
>>>> migrate-ds:
>>>> -----------
>>>> Migrated:
>>>>   users: pzuna, mnagy
>>>>   groups: skupina1, skupina2, skupina3
>>>> Errors:
>>>>   user: mnagy: Kerberos principal mnagy at PZUNA already exists. Use
>>>> 'ipa user-mod' to set it manually.
>>>>   group: accounting managers: This entry already exists
>>>>   group: hr managers: This entry already exists
>>>>   group: qa managers: This entry already exists
>>>>   group: pd managers: This entry already exists
>>>> ----------
>>>> Passwords have been migrated in pre-hashed format. IPA is unable to
>>>> generate Kerberos keys unless provided with clean text passwords.
>>>> All migrated users need to login at
>>>> http://your.domain/ipa/migration/ before they can use their
>>>> Kerberos accounts.
>>>>
>>>> I didn't try it yet, but this might also work for IPAv1->IPAv2
>>>> migration.
>>>>
>>>> Pavel
>>>
>>> I have some concerns with this. Rather than presenting a user
>>> password change page this enables basic-auth like kerberos negotiate
>>> fallback and uses the username/password presented there to do the
>>> password reset. I thought we had discussed actually presenting a
>>> form to the user to prompt for this information.
>>  >
>>  > One of our goals is to promote the usage of single sign-on using
>>  > kerberos. Enabling the password fallback can be practical and
>> needed in
>>  > some cases but I think by default we want to leave it off.
>>  >
>>
>> According to this page, we need to use form base authentication to
>> replay the password:
>> https://wiki.idm.lab.bos.redhat.com/export/idmwiki/Migration_from_DS_server_to_IPA
>>
>>
>> At first, I thought that "form base authentication" is a normal HTML
>> form, but the term is actually pretty ambiguous and there is no way
>> to replay HTML form data.
>>
>> Without the kerberos negotiate fallback on, replaying the password is
>> useless. There's no replaying going on actually.
>>
>> So, either:
>> 1) we set negotiate fallback ON and use password replaying, after
>> migration page, the user is redirected to his kerberos protected
>> self-service page without the need to enter his password twice
>> 2) we only use the password migration page to generate kerberos keys
>> and tell users to use kinit from then on.
>
> #2 is the way to go. We need to put up a simple form that has fields
> for username, old password and 2 new passwords and a submit button. We
> can't redirect them to the UI once we're done, as you point out. This
> is fine IMHO as it is unlikely their browser is set up to use kerberos
> anyway. We could redirect them to the login page, which will fail and
> contain instructions on how to set up their browser and do a kinit. We
> may need to modify the message on that page to contain specific info
> for those migrating.

Why we can't call kinit (or equivalent) on their behalf as soon as we
migrated them right away ourselves and then redirect then to the right
place - self service page?
Why make them fail? 
I assume that things like cfengine or puppet can be used to already
precofigure browsers to know about IPA.
So failing them and forcing them to use kinit manually sounds like a bad
user experience approach to me.
Do browsers support this? I understand that we would need to pass the
ticket back so that the browser can store it in the key store on the
client for future use?
If it is not possible I would suggest filing an RFE so that the browser
can get the ticket from the application and store it on the user's machine.
With kerberos now supporting S4U this might be a very valuable feature
to have.

Am I smoking something?

>
>>> The function get_base_dn() needs some error handling. I'm not sure
>>> how this will blow up if the LDAP server is down but it won't be
>>> pretty, it assumes that a namingcontext is returned, etc.
>>  >
>>> For the migration there is a typo in pwd_migration_msg, "clean text"
>>> instead of "clear text".
>>>
>>
>> Ok, I'm going to fix those asap.
>>
>>> Why are you duplicating the user_add functionality instead of
>>> calling api.Command['user_add']?
>>>
>>> Same with groups, why not user the gropu_add and group_add_member
>>> methods?
>>
>> Because it would be too much overhead.
>>
>> Migrating a single user would mean:
>> - extract data from DS and convert it to the format accepted by IPA
>> commands
>> - user_add (2 ldap operations: RETRIEVE ipaConfig, ADD)
>> - user_mod (2 ldap operations: RETRIEVE, MODIFY)
>>
>> Now that's 4 operations instead of 1 and a lot of needless
>> processing. It's even worst for groups, because we also have to do
>> group_add_member.
>>
>> On the other hand, migration is a one-shot process, so we don't have
>> to be concerned about speed/server load that much and using IPA
>> commands has its advantages.
>
> The risk is maintaining the same code in 2 places. If we end up
> finding some critical bug in user_add it is very likely to get
> overlooked here.
>
> Might be worth knowing how much this will really affect things. I
> think we should generate a ton of LDAP entries (say several thousand,
> if not more) and migrate using both methods to see what overhead is
> involved. Unless it is significantly faster I think I'd rather go with
> code re-use.
>
> I'd guess that the guys in 389 have a script to auto-generate entries.
>
> rob
> ------------------------------------------------------------------------
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/